Database
The tables each resource creates, and when a column name has to be written down.
Every table a resource owns is created on the first start. There is no SQL file for those in the download.
items/esx_qb.sql in ktx_cases and ktx_fishing is a different thing. It fills the items table of ESX or QB-Core, not one of the tables below, and it does have to be imported. See Install.
The tables
| Resource | Tables |
|---|---|
| ktx_garages | ktx_garages, ktx_garages_builder, ktx_garages_impound, ktx_garages_logs, ktx_garages_coowners |
| ktx_fishing | ktx_fishing_experience, ktx_fishing_sessions, ktx_fishing_catches |
| ktx_dispatch | ktx_dispatch_history |
| ktx_cases | ktx_case_openings |
Config.Database holds their names. Renaming one there is enough, the resource creates and reads the table under the name it finds. A config file kept from an older version that does not list one of them falls back to the stock name.
In ktx_fishing, ktx_dispatch and ktx_cases the block also carries a switch. Turned off, ktx_fishing keeps experience in memory until the next restart, ktx_dispatch keeps no history, and ktx_cases writes no openings.
Tables your framework owns
ktx_garages works with two of them. The vehicle table is the one it reads and writes all day. The player table is read in one place: entering a garage as a co-owner resolves the owner behind each co-ownership, and an owner who is not on the server has their character name read out of it. See Ownership.
A player who disconnects inside a garage keeps whatever position their framework saved. The resource closes the instance and writes nothing to the player table, so a position the framework stored while that player was inside brings them back into the interior instead of to the garage door.
The names and the columns come from a preset picked by Config.Framework.name, so a stock ESX, QB-Core, QBox or ox_core install needs no database config at all.
| Framework | Vehicles | Players |
|---|---|---|
esx | owned_vehicles: owner, vehicle, garage, plate, stored | users: identifier |
qb-core and qbox | player_vehicles: citizenid, mods, garage, plate, state | players: citizenid |
ox | vehicles: owner, data, stored, plate | characters: charId |
On ox_core stored holds the garage name and is NULL while the vehicle is out, so it stands in for the garage column and there is no separate flag.
Config.Database is there for the difference. One renamed column is one line, the rest of the preset stays:
Config.Database = {
ownedVehicles = { vehicle = "vehicle_props" },
}A wrong column name shows up as vehicles that vanish on storing, or a garage that stays empty although the rows are in the table. Nothing prints the query, so hold the row above against your own table.
The character name of an offline owner is the one read the preset does not cover in full. The table and the identifier column come from the row above, so renaming either of those in Config.Database moves that query too. The column holding the name is fixed per framework: firstname and lastname on ESX, fullName on ox_core, firstname and lastname inside the charinfo JSON on QB-Core and QBox. Those three sit in server/garages.lua, which the release encrypts, so Config.Database does not reach them and neither does an edit. A name that comes back empty is replaced by the identifier.
ktx_cases writes into the vehicle table as well, when a case pays out a vehicle. On ESX and QB-Core the adapter inserts into owned_vehicles and player_vehicles, and those names stand in bridge/server/esx.lua and bridge/server/qb-core.lua rather than in the config. A server that renamed either table changes the line there. On QBox and ox_core the vehicle is created through the framework instead, so there is no name to keep in sync.
ktx_fishing and ktx_dispatch stay inside their own tables.
Rows that pile up
The activity log in ktx_garages is swept once a day. logRetentionDays decides how long a row lives. See Activity log.
Nothing else is swept. ktx_dispatch_history grows with every call, ktx_fishing_sessions and ktx_fishing_catches with every session and every catch, ktx_case_openings with every opening. Their switch stops the writing, it deletes nothing, so on a busy server those four are yours to trim.