Database & SQL

Every framework and most scripts need MySQL or MariaDB. This page covers connecting the server, importing the SQL a script ships with, and diagnosing the failures that follow from getting either wrong.

The database layer

oxmysql is the current standard on RedM, and what almost all recent scripts expect.

Older servers may still run ghmattimysql or mysql-async. These are not interchangeable — a script written for oxmysql calls exports.oxmysql and will fail immediately on a server that only has the older resource. If you are running an old framework build and installing new scripts, standardise on oxmysql.

Connecting

Set the connection string in server.cfg, above every ensure line:

set mysql_connection_string "mysql://user:password@localhost/dbname?charset=utf8mb4"

Then ensure oxmysql first:

ensure oxmysql
ensure vorp_core

Use utf8mb4

?charset=utf8mb4 is not optional in practice. Without it, player names with accents or non-Latin characters corrupt on write, and that damage is not recoverable after the fact.

A successful connection prints a confirmation from oxmysql at boot. If you do not see one, nothing that touches the database will work, and every downstream error is a symptom rather than a cause.

Importing a script's SQL

If a download contains a .sql file, import it before the first start.

phpMyAdmin

1. Select your database in the left sidebar.
2. Open the Import tab.
3. Choose the .sql file and click Go.

HeidiSQL

1. Select the database.
2. File → Run SQL file, pick the file.

Command line

mysql -u youruser -p yourdatabase < script.sql

Select the database first

The single most common import mistake is running the file with no database selected, or with the wrong one selected. The import reports success and the tables land somewhere you are not looking.

Verifying the import

Check the tables actually exist:

SHOW TABLES;

Or look for a specific one:

SHOW TABLES LIKE 'redm_%';

If the script's tables are not listed, the import did not land in this database.

Backups

Take one before importing anything, before updating a resource, and before replacing a core module:

mysqldump -u youruser -p yourdatabase > backup.sql

Restore with:

mysql -u youruser -p yourdatabase < backup.sql

Back up before core module changes

Replacing an inventory or identity module rewrites how player data is stored. Without a backup, a failed swap means losing character data with no way back.

Common failures

Access denied for user — wrong username or password in the connection string, or the user lacks rights on that database.

Unknown database — the database name in the string does not exist. Create it, or fix the name.

Can't connect to MySQL server — MySQL is not running, or is not reachable at that host and port. On a remote database, check the firewall and that the user is permitted to connect from the server's IP.

Table already exists — harmless. That part was already imported.

Unknown column — the resource was updated and expects a column the table does not have. Re-import the current .sql, or add the column by hand.

Duplicate column name — you imported the same migration twice. Also harmless.

Script starts fine, then errors when used — the classic signature of a missing SQL import. The resource loads because nothing queried yet; the first interaction hits a table that is not there.

Multiple scripts, one database

Normal and expected. Scripts prefix their tables to avoid collisions. Import each script's SQL into the same database as the framework — separate databases per script means separate connection strings and no way to join on player identifiers.