Install, update, disable, and remove any script

The mental model: install bottom-up

A script almost never stands alone. It calls into other resources. Those resources must already be running, and must have registered their exports (the functions a resource hands out for other resources to call), before your script asks for them. So you do not install top-down, the script you want first. You install bottom-up: the things at the base of the stack first, the script that sits on top of them last.

Here is the order, drawn as a stack. Read it from the bottom.

 ┌─────────────────────────────┐
 install LAST │ qs_lockpick │ the script you actually want
 │ needs: oxmysql, ox_lib, │
 │ a framework │
 ├─────────────────────────────┤
 │ es_extended / qb-core │ framework (player data, jobs)
 │ needs: oxmysql, ox_lib │
 ├─────────────────────────────┤
 │ ox_lib │ shared library (UI, callbacks)
 ├─────────────────────────────┤
 install FIRST │ oxmysql │ database layer -> MariaDB
 └─────────────────────────────┘
 loads top-down in server.cfg,
 so write deps ABOVE the script

In server.cfg the load order is the top-to-bottom order of your ensure lines. An ensure line tells the server to start that resource. So the resource that everyone depends on, oxmysql, gets ensured first. Your script gets ensured last. If you flip that, your script boots before oxmysql exists and you get attempt to call a nil value the instant it starts. That one rule prevents most install failures.

Note the names. oxmysql, ox_lib, ox_target, and ox_inventory are Overextended community resources, not Cfx.re built-ins. Your database engine is MariaDB. A framework is the big base resource that owns player data, money, and jobs. The three you will meet are ESX (es_extended), QBCore (qb-core), and Qbox (qbx_core, the modern ox-based fork). They have separate official repositories. Install the framework and exact dependencies named by the script's current documentation.