Delete all the tables in database in one shot - laravel-5

Question

How to delete all the tables in a database in one shot in laravel.
For Migration we use-
Artisan::call('migrate', ['--force' => true]);
but for deleting all the tables is there any-
Thank You

Answer 1

php artisan db:wipe
It is a quick way to drop all the tables, their types and views if you’re using Laravel 6.x
Full description:
$ php artisan db:wipe {--database=} {--drop-views} {--drop-types} {--force}
database - The database connection to use
drop-views - Drop all tables and views
drop-types - Drop all tables and types (Postgres only)
force - Force the operation to run when in production
It was implemented on Aug 20, 2019
This change has also affected the db:fresh command’s functionality internally. Now it just calls db:wipe and then migrate.

Answer 2

Why not use this:
Artisan::call('migrate:reset', ['--force' => true]);
You can also use migrate:fresh in newer Laravel versions.
The migrate:fresh command will drop all tables from the database and then execute the migrate command
https://laravel.com/docs/7.x/migrations

Answer 3

In Laravel 5.6 documentation they have specified the following,
The migrate:reset command will roll back all of your application's migrations:
php artisan migrate:reset

Answer 4

You can do it with Controller Method
public function drop_tables(){
DB::statement("SET FOREIGN_KEY_CHECKS = 0");
$tables = DB::select('SHOW TABLES');
foreach($tables as $table){
Schema::drop($table->Tables_in_DbName); /// replace <DbName> according to your Databse Name
echo 'Table '.$table->Tables_in_DbName.' Droped. <br>'; // here too
}
DB::statement("SET FOREIGN_KEY_CHECKS = 1");
}
invoke it as per your requirement.
This will Drop all the tables that are present/existed in the Current Database

Answer 5

Here's an improvement on dipenparmat12's answer. It avoids the issues of the database name, and also foreign key constraints.
\DB::statement('SET FOREIGN_KEY_CHECKS = 0;');
$tables = \DB::select('SHOW TABLES');
foreach($tables as $table){
$table = implode(json_decode(json_encode($table), true));
\Schema::drop($table);
echo 'Dropped `'.$table . '`. ';
}
\DB::statement('SET FOREIGN_KEY_CHECKS = 1;');
The accepted answer doesn't work in the case where you've misnamed a table in a migration. I myself did this during development; which is why I landed on this stack exchange question. I put a typo in the table in the op() method, but named it properly in the down() method. Here's an example.
/**
* Run the migrations.
*
* #return void
*/
public function up()
{
Schema::create('misnamed', function (Blueprint $table) {
$table->increments('id');
$table->string('name')->uniq();
$table->timestamps();
});
}
/**
* Reverse the migrations.
*
* #return void
*/
public function down()
{
Schema::drop('properly_named');
}
This will cause rollbacks, resets, and refreshes to fail, because the migrator tries to drop a table that doesn't exist:
$ artisan migrate:refresh
In Connection.php line 664:
SQLSTATE[42S02]: Base table or view not found: 1051 Unknown table 'app.properly_named' (SQL: drop table `properly_named`)
In Connection.php line 458:
SQLSTATE[42S02]: Base table or view not found: 1051 Unknown table 'app.properly_named'
$ artisan migrate:rollback
In Connection.php line 664:
SQLSTATE[42S02]: Base table or view not found: 1051 Unknown table 'app.properly_named' (SQL: drop table `properly_named`)
In Connection.php line 458:
SQLSTATE[42S02]: Base table or view not found: 1051 Unknown table 'app.properly_named'
$ artisan migrate:reset --force
In Connection.php line 664:
SQLSTATE[42S02]: Base table or view not found: 1051 Unknown table 'app.properly_named' (SQL: drop table `properly_named`)
In Connection.php line 458:
SQLSTATE[42S02]: Base table or view not found: 1051 Unknown table 'app.properly_named'
I suspected the only way to un-break the migrations would be to drop the tables manually, in SQL, but I didn't want to go through the hassle of typing out those statements. If I make a mistake once, I'm pretty sure I'll make it again, so I wanted a way to perform an SQL DROP of all the tables, and avoid all the logic of migrations and rollbacks.
dipenparmar12's answer was a first step in the right direction; the only problem for me was that I had foreign keys, and MySQL won't drop tables with foreign key relationships without those relationships being specifically dropped first.
However, you can tell MySQL to ignore foreign key checks when dropping tables, so that's what my answer does.
If you mess up your migration to the point where these commands break, and want to just drop all the tables and start fresh, this answer will get the job done.