First Deployment Throwing Exception

Make sure the connection is using the correct instance.

Does your db have that table? "tblFooter"

@jehrhart Did you run the initial migration for the DB?

@deansatch @edjelmonico So I gave it a retry. I ran

php artisan migrate

in the root folder and it returned "nothing to migrate."

In mysql, I see that it is not showing the tables:

mysql> show tables;
+-----------------+
| Tables_in_forge |
+-----------------+
| migrations      |
| password_resets |
| tblSubscribers  |
| users           |
+-----------------+
4 rows in set (0.00 sec)

@jlrdw where am I supposed to create this? The env folder on the server has the correct information, and the laravel project states to reference the env, for example:

'host'      => env('DB_HOST'),

Thank you all for your help!

Still lost, John

In migrations, there are three migrations present. It appears these are all getting migrated. However, in the database directory there are three .sql files that contain the bulk of the site information, but they are not represented on the server.

I didn't build the site, just trying to spool it up, hence a lot of the confusion.

sounds like they didn't continue building the site using migrations and have just done a few sql dumps before handing it over - they probably contain not just the data but the missing tables.

Maybe those are the last 3 backups of the sql? Go to your mysql tool of choice (phpmyadmin, sequel pro etc..) and import those sql files and I expect it will all run fairly smoothly from there.

You might want to undo what you did first of course and start with an empty db

@deansatch It appears that's exactly what they did.

Should I import the tables into the forge DB, or should I initialize a new a new database that matches the dump and then change the env to match?

Should I remove the migrations from the code so that it doesn't affect the DB on github deployments?

should be fine to import into your forge db. You can leave migrations where they are, just never run any artisan migrates on it.

It's a shame because that is a huge benefit lost moving forward...unless you have the time to deconstruct the whole database and create all the migrations to bring it up to date, run migrate, then populate it with the data.