If Restaurant cannot connect to or update the database, you cannot use it in game. Read the first reported error. Keep existing data and migration1 history while you investigate.
Start with the first error#
Check oxmysql startup, the actual database connection and the installed oxmysql version. Restaurant requires 2.12.0 or newer with MySQL.startTransaction support. Confirm the configured database is the one you intend to use and that another Restaurant copy is not running over the same tables.
For a new installation, Restaurant creates its tables after the database connects. You do not need to import SQL by hand. For an existing installation, follow the update instructions supplied with your version.
Inspect migration history#
Use the server console, not player chat:
restaurant_migrations status
Save the status output and resource version for support. Look for the failed version and its error message. A checksum error means a migration file differs from the recorded version; check that you installed the complete matching package.
Recover a recorded failed migration#
Before running a recovery command, back up the database, stop other Restaurant copies that use it and wait for pending database work to finish. Fix the reported cause first. Leave this Restaurant resource loaded so you can use its server-console commands while gameplay remains unavailable.
After a recorded failed row is inspected and repaired:
restaurant_migrations retry <version>
restart 0r-restaurant
Replace with the failed version shown by status. Use retry after fixing the cause. This command allows another attempt; it does not repair tables or undo database changes.
Recover an interrupted running row#
A process interruption may leave running instead of failed. After proving the old writer is stopped and inspecting partial effects, use its exact token:
restaurant_migrations recover <version> <token>
restart 0r-restaurant
Check which database changes completed before using recover. If you cannot establish that result, send the status output and error to support before continuing.
Additional update instructions#
Use the following command only when the instructions supplied with your update ask for it, after completing the SQL changes in those instructions:
restaurant_migrations accept-baseline
restart 0r-restaurant
This command updates the recorded migration information. It does not change tables, fill in missing data or update saved recipes.
Normal recipe edits, Save draft and Publish do not require migration maintenance commands.
When a command is denied#
Run these commands from the server console while gameplay is unavailable and no migration is running. Administrator permission in game does not allow them.
For support, collect the first database error, status output, resource version and details of any other Restaurant copy using the database. Keep Restaurant unavailable until you resolve the error. Use Safe Updates for backup planning.
Read the status line#
The command prints each recorded migration in this format:
migration <version padded to 3 digits> <name>: <status>, steps=<completed step count>, token=<run token or ->, error=<last error or ->
Illustrative placeholders only, not a captured server log:
migration <NNN> <migration_name>: failed, steps=<completed_steps>, token=<exact_run_token>, error=<reported_error>
The number after migration is the version accepted by retry/recover. The value after token= is the exact interrupted run token required by recover. steps= counts completed steps, not a percentage. History is stored in 0resmon_restaurant_migrations; inspect it through the supported command instead of editing it.
For successful initialization, all registered migrations must be recorded applied, with their completed-step counts matching their definitions. An applied row has no active run token or last error, shown as -. Also confirm Restaurant finishes startup without a database error; a status listing alone does not prove gameplay is ready.
Choose the maintenance command by the evidence#
| Symptom | First check | Supported action | Expected result |
|---|---|---|---|
| oxmysql connection or required API fails | Connection, database selection, oxmysql >= 2.12.0 and MySQL.startTransaction | Correct the dependency/connection; restart in the documented order | Database becomes reachable and Restaurant can initialize |
| A recorded migration is failed | Its error and any completed steps | Back up, stop other writers, fix the cause, then retry that version and restart | Required steps verify and the migration becomes applied |
| A previous run remains running after interruption | Prove the old writer is stopped; inspect partial effects and exact token | Recover that version with its exact token, then restart | An explicit new attempt can continue; the command does not undo old SQL |
| Update instructions require a baseline acknowledgement | The release's specific SQL and acknowledgement instructions | Use accept-baseline only when those instructions require it, after their SQL | History acknowledges the approved baseline; tables are not modified by the command |
These commands are not general database repair or rollback tools. Keep an unresolved installation closed and send the first error plus status output to support.
Footnotes
-
A database update that Restaurant runs during startup. Read the definition. ↩