Fixing ox_lib and oxmysql not loading in FiveM

ox_lib and oxmysql are the foundation of almost every modern GTA roleplay server. When they fail to load, half your scripts break at once, and the console fills with "no such export" and dependency errors. Nine times out of ten the cause is the same: wrong load order, or you downloaded the source code instead of the built release. Both are quick fixes once you know what to look for.

This guide covers the correct ox stack load order, what "no such export" really means, the built-versus-source download trap, and how to fix the oxmysql connection string when the database will not connect.

Get the load order right (this fixes most cases)

FiveM starts resources in the exact order they appear in server.cfg, top to bottom. The ox stack has a strict dependency chain, so it must be ensured in this order: oxmysql first (the database driver), then ox_lib (the shared library), then your framework, then ox_target and ox_inventory, then all your custom scripts.

If oxmysql is ensured after a script that calls its database functions, that script runs before oxmysql exists and throws "no such export 'oxmysql'". The same applies to ox_lib. Move the foundation to the top of your cfg and most of these errors disappear in one restart.

• ensure oxmysql
• ensure ox_lib
• ensure es_extended (or qb-core)
• ensure ox_target
• ensure ox_inventory
• ensure (all your custom scripts, last)

Understand the "no such export" error

"no such export 'X' in resource 'Y'" means script A called exports['Y']:X(), but resource Y was not running yet when A tried, so the export did not exist. This is almost always a timing and ordering problem, not a broken export.

The fix is twofold: ensure Y before A in server.cfg, and declare Y as a dependency in A's fxmanifest.lua so FiveM enforces the order. The dependency line makes FiveM refuse to start A until Y is up, turning a confusing runtime crash into a clear, early failure you can read.

If the export still does not exist after fixing order, confirm the resource name is right. exports['oxmysql'] only works if the folder is actually named oxmysql. A renamed folder (oxmysql-master from a GitHub zip, for example) breaks every export call that expects the original name.

Download the built release, not the source code

A huge share of ox_lib and ox_inventory failures come from downloading the wrong files. The green "Code -> Download ZIP" button on GitHub gives you the source, which is not the runnable build. You must download the built release from the project's Releases page (the file usually named like ox_lib.zip, not the repo zip).

Symptoms of using source instead of the build: the resource errors on start, references missing compiled files, or behaves as if half of it is absent. If you grabbed it from the Code button, delete it and re-download the latest release asset instead.

Also strip any -main or -master suffix from the extracted folder name so it matches what other resources expect (ox_lib, not ox_lib-main). Folder names are part of how exports and dependencies resolve.

Fix the oxmysql database connection string

If oxmysql starts but every query fails, the problem is usually the connection string. oxmysql reads a convar in server.cfg, typically set mysql_connection_string "...". A wrong host, port, user, password, or database name means it loads but cannot connect, and dependent scripts then crash when they try to query.

Use the URI form and double-check each field: mysql://user:password@host:3306/databasename. Confirm the database actually exists and that the user has access. If your password contains special characters, they may need URL-encoding. A quick test query in the console after boot confirms the connection is live.

Database and dependency wiring is fiddly the first time. PlayDeck's AI workflow walks you through the ox stack setup, generates a correct server.cfg order and connection string from your details, and explains each piece so you can debug it yourself next time. Join the waitlist to get started.