Database & Items

When a feature needs to remember things — owned vehicles, player-owned shops, balances — it needs database tables. myRP.build handles this for you, with one requirement.

SQL is applied for you

When a generated resource includes a schema (e.g. sql/install.sql), myRP.build runs it against your server's database as part of generation. FiveM and oxmysql do not execute install.sql automatically, so the app does it — the tables exist by the time the resource loads. No manual import step.

Requirement: a connection string in server.cfg

To apply SQL, the app reads your database connection from server.cfg:

set mysql_connection_string "mysql://user:password@localhost/yourdb"

This is the same oxmysql connection string your server already uses. If it's present, schema application is automatic.

If the app can't find a connection string or the import fails, it falls back to telling you to import the schema file manually — that's the signal to check your server.cfg.

oxmysql only. Generated resources never use mysql-async.

ox resources have their own SQL too

myRP.build installs the ox stack for you, but some ox resources (for example ox_inventory) include their own install.sql for their tables. That SQL needs to be in the same database — separate from the per-resource schemas myRP.build applies for your generated features. If an ox resource's tables are missing, import its install.sql into your database.

Items are not auto-registered

If a feature uses a custom inventory item — a lockpick, a repair kit, a burger — the generated code will reference that item, but myRP.build does not add it to ox_inventory's item data for you. You register custom items yourself, in ox_inventory's items file, the way you would for any ox resource.

When you write a prompt that relies on an item, name the item explicitly so the generated code references the right one — then make sure that item exists in ox_inventory.

If a resource errors on a missing item or table, see Troubleshooting.