Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
Hello,
I've been scratching my head for maybe the last error trying to figure out what's going on.
I deleted my database.sql file since I wanted a new one from scratch. I've done this dozens of times, but upon running php artisan migrate:fresh it returned the following error:
Database file at path [{..}/database/database.sqlite] does not exist. Ensure this is an absolute path to the database. (Connection: sqlite, SQL: PRAGMA foreign_keys = ON;)
at vendor/laravel/framework/src/Illuminate/Database/Connection.php:829
825▕ $this->getName(), $query, $this->prepareBindings($bindings), $e
826▕ );
827▕ }
828▕
➜ 829▕ throw new QueryException(
830▕ $this->getName(), $query, $this->prepareBindings($bindings), $e
831▕ );
832▕ }
833▕ }
1 [internal]:0
Illuminate\Foundation\Application::Illuminate\Foundation\{closure}(Object(App\Providers\AppServiceProvider))
+17 vendor frames
19 app/Providers/AppServiceProvider.php:24
Illuminate\Support\Facades\Facade::__callStatic("table")
This has always created the database itself, why is it not now?
As an additional note, I created the database.sqlite in the original directory manually, and it came out with this error instead:
SQLSTATE[HY000]: General error: 1 no such table: kingdoms (Connection: sqlite, SQL: select count(*) as aggregate from "kingdoms")
at vendor/laravel/framework/src/Illuminate/Database/Connection.php:829
825▕ $this->getName(), $query, $this->prepareBindings($bindings), $e
826▕ );
827▕ }
828▕
➜ 829▕ throw new QueryException(
830▕ $this->getName(), $query, $this->prepareBindings($bindings), $e
831▕ );
832▕ }
833▕ }
I thought this might be an issue with the create_kingdoms_table.php migration, so I removed it to see, and somehow, the error is still the same even with the migration gone, even after clearing cache.
So now I am really confused. Can anyone help?
@the_titan The error is saying that you don't have a database file for SQLite.
Database file at path [{..}/database/database.sqlite] does not exist. Ensure this is an absolute path to the database. (Connection: sqlite, SQL: PRAGMA foreign_keys = ON;)
So, go to database directory and create a new file called database.sqlite
And then run the migration again.
@tisuchi Thats what i did and where I got the second error. I then deleted the file again, created a fresh database.sqlite file (in the database dorectory) and deleted the kingdoms migration file… but somehow… still got an error with the kingdoms table despite it not existing and no reference to it in my migrations
you are referencing this table somewhere in the framework boot process but it does not exist yet
@Snapey where would I find that? And why doesn’t running a fresh migration fix that? And why is it having this issue now but it’s been fine for hundreds of other commits and deploys?
Sorry for the loaded question, I’m just quite confused
@The_titan when you run artisan, eg for migration, it has to boot the whole framework. In something like appServiceProvider you are trying to access data in the kingdoms table but it does not yet exist.
doing a simple search of your codebase should jog your memory
@Snapey haha, now I feel stupid! Thank you!
For anyone that may find this later, we had bootstrapped a service in AppServiceProvider.php that would get some basic server stats and share it with all the views so we could display it in a sidebar. As the comment above said, this file is loaded when php artisan is run, and it has a direct reference to a table that does not exist, so artisan fails:
namespace App\Providers;
use Illuminate\Support\ServiceProvider;
use Illuminate\Support\Facades\View;
use Illuminate\Support\Facades\DB;
class AppServiceProvider extends ServiceProvider
{
/**
* Register any application services.
*/
public function register(): void
{
//
}
/**
* Bootstrap any application services.
*/
public function boot(): void
{
$kingdom_count = DB::table('kingdoms')->count();
View::share('kingdom_count', $kingdom_count);
View::share('server_time', date("m:i A"));
}
}
We removed this, ran the migrations, and then added it back, and that resolved the issue.
Thanks to those who tried to help :-)
You can wrap this code inside a check that sees if you are in API context (ie, running artisan) and skip it if so since doing view share stuff is pointless.
@Snapey would you explain, maybe, how we would do this?
Please or to participate in this conversation.