SQLSTATE[HY000] [1045] Access denied for user 'user_name'#'localhost' (using password: YES) (SQL: select * from `users` where `email` = admin#gmail.com limit 1)
I have added all the required attributes in .env file but I am getting this error.
How can I solve it?
the error:
Illuminate\Database\QueryException : SQLSTATE[HY000] [2002] No such
file or directory (SQL: select * from information_schema.tables where
table_schema = eurofleet and table_name = migrations and table_type =
'BASE TABLE')
Does anyone have any idea?
I am getting following exception while migrating tables.
Uncommented pdo_mysql from php.ini file
Illuminate\Database\QueryException : could not find driver (SQL: select * from information_schema.tables where table_schema = blog and table_name = migrations)
I've just moved from a Vagrant-based localhost setup to a Docker setup running :
PHP 7.2.8
PHP-FPM 7.2.8
Mariadb 10.2.15 (webhippie/mariadb)
I exec'ed into the Docker machine running FPM and did php artisan migrate, but was greeted with the following error :
SQLSTATE[HY000]: General error: 1005 Can't create table `data`.`migrations` (errno: 140 "Wrong create options") (SQL: create table `migrations` (`id` int unsigned not null auto_increment primary key, `migration` varchar(191) not null, `batch` int not null) default character set utf8mb4 collate utf8mb4_unicode_ci engine = InnoDB ROW_FORMAT=DYNAMIC)
I have another Laravel install running with the same Docker machines and no problem doing migrations.
From the erorr message, it seems there is an error during Laravel's creation of the migrations table. I've no idea what to do next. Help?
UPDATE :
Tried running the creation query :
create table `migrations` (`id` int unsigned not null auto_increment primary key, `migration` varchar(191) not null, `batch` int not null) default character set utf8mb4 collate utf8mb4_unicode_ci engine = InnoDB ROW_FORMAT=DYNAMIC
Removing option ROW_FORMAT=DYNAMIC successfully creates the migrations table. Will removing it impact Laravel's operation?
I think I got the answer.
I set engine = 'innodb ROW_FORMAT=DYNAMIC' at config/database.php. I did this a long time ago when trying to fix Laravel's key too long error. There is a simple fix (in the link) which limits string length to 191. so to fix the problem, just set engine = 'innodb' or engine = 'null' at config/databse.php.
check this out
https://laracasts.com/discuss/channels/eloquent/migrations-and-table-options-row-format?page=0
and let me know if it doesn't work
change config/database.php
'connections' => [
...
'mysql' => [
...
'engine' => 'InnoDB ROW_FORMAT=DYNAMIC',
]
...
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
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.
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
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
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
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.