I am working with a team on a project in laravel and have to migrate the database with vagrant ssh using scotchbox. Using the php artisan migrate method in /var/www I can migrate the set up migrations. These will get migrated successfully.
When I log in using Sequel Pro or MySQLWorkbench, these tables appear in the database. But then they disappear, being invisible most of the time even whilst keeping the connection. Resetting, refreshing or tinkering with the migrations does not seem to fix the problem. I tried to add some records but upon loging in with my user it does not work, receiving this error:
QueryException in Connection.php line 651:
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'scotchbox.users' doesn't exist (SQL: select * from users where email = jos#jos.com limit 1)"
My tables can not be found even though they are migrated. Oddly, and I am not sure if it has anything to do with it, I sometimes get a "FORBIDDEN: you don't have permission to acces /page on this server" when being on any page. But nevertheless, I have a migration problem. Thanks in advance for helping me.
The issue was multiple VM's on the same IP. Resulting in the signal flaking and the database not always being found. The connection was there but not always the right one.
Related
when i run this code "php artisan migrate --seed" qppeaer one error like
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'naryn.modules' doesn't exist (SQL: select * from modules where module = admin/backup_v2 limit 1)
Without seeing your database, stacktrace, and code this will be hard to answer.
But is this the first time that you ran the migration? If not, it's possible that you dropped the tables (the modules table specifically), but you did not drop the migration table. If the modules migration record still exists it will not run the migration and will not cause an error, hence going to the seeder even when there's no table migrated.
I would suggest if your still on the development phase and you can still drop the tables, just drop the schema and create it again to make sure it's a clean migration.
I already asked a question about this 2 days ago, here are the links
Got "password authentication failed for user" but in pgAdmin 3 its working
But I still didn't get an answer to solve the problem.
So I tried to create a new laravel project, then edit the .env file, check if php artisan migrate can run.
After I run php artisan migrate it's running, so it means that my credentials to PostgreSQL database are correct right? if not it will tell you password authentication failed for user "postgres", but I don't get any error at all, so I go to the next step. Now after I make sure everything is OK i run php artisan make:auth, it's a success without error at all, so I go to the web browser then run the site, I clicked the register / login button, fill the fields, submit then, it's happened again the nightmare
I got this message from the website
SQLSTATE[08006] [7] FATAL: password authentication failed for user "postgres" FATAL: password authentication failed for user "postgres" (SQL: select count(*) as aggregate from "users" where "email" = test#test.com)
Even though php artisan migrate run really well, so I've no idea why it's happening. Is there somebody that ever run into this problem before? or maybe why it's happening?
I already search all keywords that possible to fix this problem, but I can't found the answer, it's really stressed me out.
for the info I'm using:
PostgreSQL 9.6.8
Laravel 5.6
Ubuntu 17.10
Edited: Here is my pg_hba.conf
Check your database.php file in config directory, and check the pgsql array. If accessing DB credential values from .env not worked there, test it by directly putting credentials there. hope it will help. Artisan commands work by accessing the credentials from .env files directly,not from database.php that's why migration worked.
I had a similar problem, my generated password contained the character: '#'. This made it a comment line, ignoring the rest of the password. I just changed my password.
I tried building a database where I forgot to place the index of the table. Now I'm trying to rollback the migration but its not working out. It is throwing some error
[ErrorException] Undefined index: 2017_01_06_195028_create_users_themes_table
Now I tried deleting it manually so I deleted the migration file from the database folder and then did composer dump-autoload, and then did rollback it is still showing same error. Also when this didn't happened I tried placing index in the table through phpmyAdmin, it ain't helped! Still i deleted the table manually and tried doing composer dump-autoload and rollback it still has same error.
Help me out with this.
You can backup DB data (if any), drop DB and create it again and run php artisan migrate command. It's the easiest way to fix this I guess.
Another thing you could try is to delete last batch from migrations table and drop tables from last batch and run php artisan migrate
When you do php artisan migrate, migration table is created and it records the order of the migration you run. And when you rollback the list get cleared in the order of rollbacks..
In your case since you got an error the record corresponding to your migration probably still in the migration table.
Now if you wish to update your migration file and migrate again, you needs to manually clear the corresponding record from the migration table. Most probably it would be the last record in the migration table.
Clear out that record, fix your migration file and run your migration. You should be good to go.
I forgot to mention that I'm having my migration files in different folder so everytime I'm doing a php artisan migrate rollback I need to specify the path of those migration file that is why it is showing undefined Index error.
For some reason whenever I run any php artisan command I get an error saying one of my tables doesn't exist. This is true, I'm starting on a new database. What I can't figure out is why on earth artisan needs to use this table? The error that shows up is:
[Illuminate\Database\QueryException]
SQLSTATE[42S02]: Base table or view not found: 1146 Table
'happylister.categories' doesn't exist (SQL: select *
from `categories` order by `name` asc)
[PDOException]
SQLSTATE[42S02]: Base table or view not found: 1146 Table
'happylister.categories' doesn't exist
I just can't figure out for the life of me where that query is coming from - even just using php artisan generates this error. I first noticed this when I tried to run php artisan migrate to set up the tables, which of course failed. Then I noticed ALL php artisan commands fail.
So my question is: why would php artisan need a table specific to my app, given that normally you should be able to use php artisan on a clean database to set it up?
A Laracasts user very kindly helped me out with this answer:
If you're referencing a model from a service provider and the
migrations have not been run, then you'll get that error. For some
reason Artisan commands like to load all the providers, even ones it
doesn't need.
Thank you to FetchTheDev over at the Laracasts forums.
To make a long story short, I have completely messed up my Laravel migrations on my local machine. They are 100% unusable.
I'm working with Laravel 5 for the first time, so I'm just messing with stuff and testing the waters, so to speak. Between manually tinkering with the database, rewriting my migrations, accidentally deleting a table or two (then the 'migrations' table itself [doh!]), I'm in this mixed-up state, and I just want to start all of the migration stuff over from scratch. However, I can't seem to figure out how to do that.
I'm currently stuck in a state where I can't do anything.
For example, if any remnants of old tables are still in the database when I perform php artisan migrate:refresh, I get a Base table or view already exists error message. However, if I delete all the tables, I get this error:
Next exception 'Illuminate\Database\QueryException' with message
'SQLSTATE[42S02]: Base table or view not found: 1146 Table
'bsd_status.projects' doesn't exist (SQL: select * from `projects`)' in
path/to/src/Illuminate/Database/Connection.php:620
I've run the following commands:
$ php artisan clear-compiled
$ php artisan cache:clear
$ php composer dump-autoload
$ php artisan migrate:install
I'm not even sure I'm doing this stuff in the right order. Anyway, other than completely reinstalling Laravel, how does one get all his/her migrations back to "out-of-the-box?" Any help would be greatly appreciated. Thanks!
What I liked to do is manually delete all the tables with what ever tool you use on your device. For me I just use phpmyadmin. After that I do.
php artisan migrate:install
php artisan migrate:refresh
Don't know if this is the official way, but it works every time.
If you don't want to use phpmyadmin you can just
login to mysql via command line
mysql -u root -p
DROP DATABASE laraveldb;
CREATE DATABASE laraveldb;
Although #Goddard's answer and #nozzleman's comment were both really helpful (I've used both suggestions several other times, so thank you), the solution had nothing to do with migrations. Well, … other than the fact that I screwed them up to begin with.
Anyway, nothing I did fixed the issue, so I put on my "think really f'ing hard" hat. After cursing for several minutes, I realized something. It appeared that — even when simply running artisan from the command line — any routes or providers I had set up were attempting to be "resolved" (or whatever the proper terminology is). Thus, I must have had a call somewhere attempting to get data from the missing table when the app started the bootstrap/init/start/run phase.
I decided to make sure I didn't have any weird things going on in my actual code, so I checked in my routes file (app/Http/routes.php) and all my Service Provider files (app/Providers/*) to see if I was trying to retrieve model data in any of them. Lo and behold, I opened app/Providers/AppServiceProvider.php and found this:
AppServiceProvider.php
public function boot()
{
$layout = 'default';
if ( Request::has('layout') ) {
$layout = Request::input('layout');
}
view()->share('sharedAppData', [
'layout' => $layout,
'projects' => App\Project::all() // <- WTF, mate?
]);
}
If you recall, the table being complained about in the error messages was named "projects." Thus, I was attempting to get all projects at boot, so no matter what I did (at the command line or otherwise), nothing was going to work because my Eloquent-extended model (App\Project) was looking for a table that simply didn't exist anymore.
The moral of the story: Laravel is super complex, I suck at it, and no matter how many times I try to follow the teachings of the great Jeffery Way, I'll forever be a Laran00b.
try this:
composer dump-autoload
composer clear-cache