FiveM MariaDB Unknown Column แก้อย่างไร? วิธีแก้ Error 1054 เมื่อ Resource กับ Database Schema คนละ Version

August 13, 2026

FiveM MariaDB Unknown column คือ Error ที่เกิดเมื่อ Resource ส่ง SQL Query ไปเรียก Column ที่ MariaDB หาไม่พบใน Table หรือ Query Context นั้น โดย MariaDB กำหนด Error นี้เป็น 1054, SQLSTATE 42S22 และชื่อ ER_BAD_FIELD_ERROR พร้อมข้อความรูปแบบ Unknown column '...' in '...'.

ตัวอย่างที่อาจพบใน FiveM Console:

ERROR 1054 (42S22):
Unknown column 'citizenid' in 'field list'

หรือ:

SCRIPT ERROR: oxmysql was unable to execute a query!
Unknown column 'metadata' in 'field list'

หรือ:

Unknown column 'players.identifier' in 'where clause'

ปัญหานี้ต่างจาก Table doesn't exist เพราะกรณี Error 1054 Table อาจมีอยู่แล้ว แต่ Column ที่ SQL เรียกใช้ไม่มี ชื่อไม่ตรง หรืออยู่ผิด Table/Alias.

สาเหตุที่พบได้บ่อยใน FiveM ได้แก่:

ไม่ได้รัน Migration หลังอัปเดต Script
Resource ใหม่แต่ Database Schema เก่า
Database ใหม่แต่ Custom Script เก่า
Column ถูก Rename
Column ถูกลบ
พิมพ์ชื่อ Column ผิด
Query ใช้ชื่อ Column ของ Framework อื่น
Table Alias ผิด
Resource ต่อ Database คนละตัว
SQL ถูก Import ไม่ครบ
Parameter ถูกนำไปใช้ผิดลักษณะ
ใช้ String เป็น Identifier โดยไม่ Quote/Parameterize ให้ถูก

แนวทางแก้ที่ถูกต้องคือ:

Error 1054
↓
อ่านชื่อ Column
↓
ดูว่า Error อยู่ field list / where clause / on clause
↓
หา Resource และ Query
↓
SHOW COLUMNS
↓
SHOW CREATE TABLE
↓
ตรวจ Resource Version กับ Schema
↓
ตรวจ Migration
↓
แก้ Column หรือ Query ตาม Schema ที่ถูกต้อง

① Error 1054 คืออะไร

MariaDB ระบุ:

Error Code: 1054
SQLSTATE: 42S22
ER_BAD_FIELD_ERROR
Unknown column '%s' in '%s'

อย่างเป็นทางการ.

ตัวอย่าง:

SELECT
    `citizenid`,
    `name`
FROM `players`;

แต่ Table players จริงมีเพียง:

id
identifier
name

ไม่มี:

citizenid

MariaDB จึงไม่สามารถ Resolve ชื่อ Column นั้นได้

② Unknown Column ต่างจาก Table Doesn't Exist อย่างไร

จากบทความก่อนหน้า:

1146
Table doesn't exist

หมายถึง Table ที่ SQL อ้างถึงไม่มี

แต่:

1054
Unknown column

หมายถึง SQL ไปถึงขั้น Resolve Column แล้ว แต่ชื่อ Column ที่ระบุหาไม่พบใน Context ที่ใช้อยู่.

จำง่าย:

1146
ไม่มี Table

1054
มี Table/Query Context
แต่ไม่มี Column ที่เรียก

③ Unknown Column ต่างจาก SQL Syntax Error อย่างไร

Error:

1064
SQL Syntax Error

หมายถึง MariaDB Parse โครงสร้าง SQL ไม่ผ่าน

แต่:

1054
Unknown Column

โดยทั่วไป Query Parse ได้ไกลพอที่จะเริ่ม Resolve Identifiers แล้ว แต่ Column ที่อ้างถึงไม่ถูกต้อง.

ดังนั้นถ้า Error เป็น 1054 อย่าเริ่มจากแก้:

comma
parenthesis
semicolon

ก่อน

ให้ดูชื่อ Column ที่ MariaDBแจ้ง

④ อ่านคำว่า in field list ให้เป็น

ตัวอย่าง:

Unknown column 'citizenid' in 'field list'

มักหมายความว่า Column ถูกอ้างถึงในส่วนของรายการ Fields เช่น:

SELECT `citizenid`
FROM `players`;

หรือ:

INSERT INTO `players`
    (`citizenid`, `name`)
VALUES
    (?, ?);

หรือ:

UPDATE `players`
SET `citizenid` = ?
WHERE `id` = ?;

จุดสำคัญคือหา Query จริงก่อน

⑤ Unknown Column in WHERE clause

ตัวอย่าง:

Unknown column 'citizenid' in 'where clause'

Query อาจเป็น:

SELECT *
FROM `players`
WHERE `citizenid` = ?;

แต่ Table มี:

identifier

แทน

กรณีนี้ Resourceอาจเขียนมาสำหรับ Framework คนละตัว

⑥ Unknown Column in ON clause

ตัวอย่าง:

SELECT *
FROM `players` p
JOIN `characters` c
    ON c.`player_id` = p.`id`;

ถ้า characters ไม่มี:

player_id

ก็สามารถเกิด Unknown Column ระหว่างการ Resolve Join Condition ได้

ดังนั้นเมื่อ Errorเกี่ยวกับ Join ต้องตรวจ ทั้งสอง Tables และ Alias

⑦ วิธีตรวจ Columns ของ Table

ใช้:

SHOW COLUMNS FROM `players`;

MariaDB SHOW COLUMNS ใช้แสดงข้อมูล Columns ของ Table เช่นชื่อ Field, Type, Null, Key, Default และ Extra.

ตัวอย่างผล:

id
identifier
name
metadata
created_at

ถ้า Resource Query:

citizenid

แต่ไม่มีในรายการ ก็พบปัญหาเบื้องต้นแล้ว

⑧ ใช้ SHOW CREATE TABLE ยืนยัน Schema

ใช้:

SHOW CREATE TABLE `players`;

MariaDB ระบุว่า SHOW CREATE TABLE แสดง CREATE TABLE Statement ของ Table ปัจจุบัน จึงช่วยดู Column Definitions, Indexes และโครงสร้างจริงได้.

ตัวอย่าง:

CREATE TABLE `players` (
    `id` INT NOT NULL AUTO_INCREMENT,
    `identifier` VARCHAR(100) NOT NULL,
    `name` VARCHAR(100) NOT NULL,
    PRIMARY KEY (`id`)
);

ตรงนี้ชัดเจนว่าไม่มี:

citizenid

⑨ อย่าดู install.sql อย่างเดียว

Resource Folder อาจมี:

`citizenid` VARCHAR(50)

แต่ Production Database จริงอาจยังเป็น:

`identifier` VARCHAR(100)

เพราะ Migration ไม่ได้รัน

ดังนั้นต้องเปรียบเทียบ:

Resource SQL
vs
SHOW CREATE TABLE จริง

ไม่ใช่อ่านไฟล์ SQL แล้วสมมติว่า Databaseถูก Update ไปแล้ว

⑩ สาเหตุอันดับหนึ่ง: Migration ไม่ครบ

ตัวอย่าง:

Resource v1
ใช้ column:
identifier

Resource v2 เปลี่ยนเป็น:

citizenid

พร้อม Migration:

ALTER TABLE `players`
ADD COLUMN `citizenid` VARCHAR(50);

แต่ Admin Update เพียง Resource Folder

Database ยังไม่มี Column ใหม่

เมื่อ Resource v2 Query:

SELECT `citizenid`
FROM `players`;

จึงเกิด Error 1054

MariaDB รองรับการเพิ่ม Column ผ่าน ALTER TABLE ... ADD COLUMN.

⑪ อย่า ADD COLUMN เองก่อนหา Migration

ถ้าเห็น:

Unknown column 'citizenid'

อย่ารีบ:

ALTER TABLE `players`
ADD `citizenid` VARCHAR(50);

เพราะ Official Migration อาจต้องกำหนด:

Data Type อื่น
NOT NULL
DEFAULT
UNIQUE
INDEX
Character Set
Position
Backfill

หรืออาจไม่ได้ต้องเพิ่ม Columnเลย เพราะ Queryของ Custom Script เป็นฝ่ายผิด

⑫ Resource ใหม่กับ Database เก่า

นี่เป็น Pattern ที่พบบ่อยมาก:

Resource v4
+
Database Schema v2
=
Unknown Column

โดยเฉพาะ Script ที่ Update แล้วเพิ่มข้อมูล เช่น:

metadata
last_seen
citizenid
account_id
status
garage_id

ถ้า Migrationหลัง Versionไม่ได้รัน SQL ใหม่จะหา Columnไม่พบ

⑬ Database ใหม่แต่ Resource เก่าก็เกิดได้

กรณีกลับกัน:

Database Schema ใหม่
+
Custom Script เก่า

เช่น Schema ใหม่ Rename:

identifier
→ citizenid

แต่ Custom Script ยัง:

SELECT `identifier`
FROM `players`;

ผลก็เป็น Error 1054 ได้

ดังนั้นไม่ควรสรุปทุกครั้งว่า:

Database ต้องเพิ่ม Column

บางครั้งต้องแก้ Resource Query ให้ใช้ Columnใหม่

⑭ Rename Column เป็นสาเหตุได้

สมมติ Migration เปลี่ยน:

owner

เป็น:

identifier

Custom Resource เก่ายังทำ:

SELECT *
FROM `vehicles`
WHERE `owner` = ?;

แต่ Tableใหม่ไม่มี owner

Error:

Unknown column 'owner' in 'where clause'

MariaDB ALTER TABLE รองรับ Operations สำหรับปรับโครงสร้าง Columns รวมถึงการเปลี่ยน Columnsตาม Syntax ที่รองรับ.

⑮ อย่าเพิ่ม Column เก่ากลับเพียงเพื่อให้ Custom Script ผ่าน

ถ้า Frameworkใหม่เปลี่ยน Data Model จาก:

owner

เป็น:

citizenid

การเพิ่ม:

owner

กลับมาอีก Column อาจทำให้เกิดข้อมูลซ้ำสองแหล่ง:

owner = A
citizenid = B

และ Resources คนละตัวอ่านคนละค่า

ควร Update Custom Script ให้ใช้ Data Model ปัจจุบันถ้านั่นคือ Official Schema

⑯ Framework คนละตัวใช้ชื่อ Column ไม่เหมือนกัน

Custom Script ที่ทำมาสำหรับ Framework A อาจคาด:

citizenid

แต่ Framework B ใช้:

identifier

หรือ:

charid

ดังนั้น Error 1054 หลังติดตั้ง Script ใหม่อาจหมายถึง:

Script ไม่ Compatible กับ Framework ปัจจุบัน

ไม่ใช่ Database เสีย

⑰ อย่า Copy SQL ของ Framework อื่นมารวมกัน

ถ้า Resource Requirements บอกว่าใช้ Data Modelหนึ่ง แต่ Serverใช้ Frameworkอีกตัว การ Import SQL จากอีก Frameworkเพียงเพื่อให้ Columnปรากฏ อาจสร้าง Mixed Schema

ผลในอนาคตอาจเป็น:

Duplicate Data
Foreign Key Error
Unknown Column เพิ่ม
Required Field Error
Resource Load ผิด

ต้องเลือก Integration ที่รองรับ Frameworkจริง

⑱ วิธีค้น Column ทั้ง Database

MariaDB information_schema.COLUMNS มี Metadata ของ Columns ทุก Tables รวมถึง:

TABLE_SCHEMA
TABLE_NAME
COLUMN_NAME
DATA_TYPE
COLUMN_DEFAULT
IS_NULLABLE

ตัวอย่าง:

SELECT
    TABLE_SCHEMA,
    TABLE_NAME,
    COLUMN_NAME,
    DATA_TYPE
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = DATABASE()
  AND COLUMN_NAME = 'citizenid';

ถ้าไม่มีผลลัพธ์ แสดงว่า Databaseปัจจุบันไม่มี Columnชื่อนี้เลย

⑲ หา Column ที่ชื่อคล้ายกัน

หาก Error:

Unknown column 'citizenid'

แต่ไม่แน่ใจว่า Schemaใช้ชื่ออะไร สามารถตรวจ:

SHOW COLUMNS FROM `players`;

แล้วดูว่าอาจมี:

identifier
citizen_id
character_id
player_id

แทน

ไม่ควร Rename หรือเพิ่ม Column จนกว่าจะรู้ว่า Resourceต้องการ Data Conceptใดจริง

⑳ ตรวจ Database ปัจจุบันด้วย

ใช้:

SELECT DATABASE();

MariaDB DATABASE() คืนชื่อ Default Database ของ Session ปัจจุบัน.

สมมติคุณเปิด phpMyAdmin Database:

fivem_prod

แล้วเห็น Column citizenid

แต่ FXServerจริงต่อ:

fivem_test

ซึ่งไม่มี Column

FiveMก็ยัง Error

㉑ Connection String ผิด Database ทำ Unknown Column ได้

Official oxmysql Documentation ระบุให้กำหนด mysql_connection_string ก่อน Resources และ Connection String มีชื่อ Database ที่ FXServer ใช้งาน.

ตัวอย่าง:

set mysql_connection_string "mysql://user:pass@localhost:3306/fivem"

ถ้า SQL Migrationถูกนำไปใช้กับ:

fivem_new

แต่ FiveMยังใช้:

fivem

Tableอาจมีเหมือนกัน แต่ Columns คนละ Version

จึงเกิด 1054 แทน 1146ได้

㉒ ทำไม Database ผิดตัวถึงเกิด 1054 แทน 1146

สมมติทั้งสอง Databaseมี Table:

players

Database A:

players
- id
- identifier

Database B:

players
- id
- identifier
- citizenid

Resourceต้องใช้ B

แต่ Connectionไป A

Tableจึงมี:

players

แต่ไม่มี:

citizenid

ผลคือ:

1054 Unknown Column

ไม่ใช่ 1146

㉓ Error หลัง Restore Database

สมมติ Resource Files ปัจจุบันเป็น v5

แต่ Restore Backupของ Databaseจาก v3

หลัง Restore:

Table ทุกตัวอยู่ครบ

จึงไม่เกิด 1146

แต่ Columns ที่เพิ่มใน v4/v5 หาย

FiveMจึงเริ่มขึ้น:

Unknown column

หลายตัว

กรณีนี้ต้อง Apply Migrations จาก Version Backupไป Versionปัจจุบันตามลำดับ

㉔ อย่า Import Fresh install.sql ทับ Production โดยไม่ตรวจ

หากมี Player Dataอยู่แล้ว:

characters
vehicles
inventory
accounts

ไม่ควรใช้ Fresh Installation SQL ซ้ำโดยอัตโนมัติ

ควรหา:

migration.sql
upgrade.sql
ALTER TABLE
release migration

ที่ตรง Version

Fresh Install Schema กับ Upgrade Schema มีวัตถุประสงค์ต่างกัน

㉕ Table มี Column แต่ Error ยังขึ้น

ถ้า:

SHOW COLUMNS FROM `players`;

เห็น:

citizenid

แต่ Consoleยังขึ้น:

Unknown column 'citizenid'

ให้ตรวจต่อ:

Database ที่ FiveMต่ออยู่
Table Alias
ชื่อ Tableจริงใน Query
Database-qualified name
Resource Queryจริง

อาจกำลังตรวจ players ใน Databaseหนึ่ง แต่ Queryจริงใช้ Tableอีกตัว

㉖ Table Alias คืออะไร

ตัวอย่าง:

SELECT
    p.`identifier`
FROM `players` AS p;

ตรงนี้:

คือ Alias ของ players

ถ้าเขียน:

SELECT
    x.`identifier`
FROM `players` AS p;

x ไม่มีใน Query Context

จึงเป็น Identifier Problem ที่ต้องแก้ SQL ไม่ใช่เพิ่ม Column

㉗ Join Alias ผิดเป็นสาเหตุยอดนิยมใน Custom Script

ตัวอย่าง:

SELECT
    p.`identifier`,
    c.`firstname`
FROM `players` p
JOIN `characters` c
    ON p.`character_id` = x.`id`;

แต่ไม่มี Alias:

ปัญหานี้อยู่ที่ Query

ไม่ใช่ Schema

㉘ Column อยู่คนละ Table

สมมติ:

players
- id
- identifier

characters
- id
- firstname
- lastname

แต่ Query:

SELECT
    p.`firstname`
FROM `players` p;

firstname อาจมีอยู่จริง แต่ อยู่ใน characters ไม่ใช่ players

ดังนั้นคำว่า Unknown Columnไม่ได้แปลว่า Columnไม่มีทั้ง Database

อาจเพียงอ้างผ่าน Table/Aliasผิด

㉙ ใช้ information_schema ตรวจตำแหน่ง Column

สามารถใช้:

SELECT
    TABLE_NAME,
    COLUMN_NAME
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = DATABASE()
  AND COLUMN_NAME = 'firstname';

information_schema.COLUMNS มีข้อมูล Column ของแต่ละ Tableบน Server.

หากผล:

characters | firstname

แสดงว่า Queryที่ใช้:

players.firstname

ผิด Table

㉚ Unknown Column จาก Typo

ตัวอย่างง่ายๆ:

Database:

identifier

Resource Query:

identifer

ขาดตัว:

MariaDBไม่สามารถเดาได้ว่า Developerหมายถึง Columnใด

จึงคืน 1054

ก่อน Migrationใหญ่ ให้ตรวจ Spellingเสมอ

㉛ Column Name ตัวพิมพ์ใหญ่เล็กควรใช้ให้สม่ำเสมอ

แม้ Identifier Case Rules มีรายละเอียดต่างกันตามชนิด Identifier และ Platform แต่แนวทางที่ปลอดภัยคือให้ Schemaกับ Resourceใช้ชื่อเดียวกันทุกจุด ไม่ผสม:

CharacterID
characterId
character_id

ถ้าเป็นคนละชื่อจริง SQLก็ไม่ได้ถือว่าเป็น Columnเดียวกันโดยอัตโนมัติ

㉜ String ที่ไม่ Quote อาจถูกตีความเป็น Column

ตัวอย่างที่ผิด:

SELECT *
FROM `players`
WHERE `status` = active;

ถ้า active ถูกเขียนเป็น Bare Identifier MariaDBอาจพยายามตีความเป็นชื่อ Identifier/Column แทน String Value

รูปแบบที่เหมาะกว่า:

SELECT *
FROM `players`
WHERE `status` = ?;

แล้วส่ง:

active

ผ่าน Parameter

oxmysql ระบุว่า Placeholdersใช้ส่ง Query Parameters แยกจาก SQL และช่วย Execute Parameters อย่างปลอดภัย.

㉝ อย่าต่อ User Input เข้า SQL ตรงๆ

ไม่ควร:

local query =
    "SELECT * FROM players WHERE identifier = " ..
    identifier

ถ้า Identifierเป็น String Queryอาจกลายเป็น SQL ที่ MariaDBตีความ Identifierผิดชนิด

ควร:

MySQL.query.await(
    'SELECT * FROM `players` WHERE `identifier` = ?',
    {
        identifier
    }
)

oxmysql รองรับ Parameterized Queries และ Query API คืน Rows/Result Data ตามประเภท Statement.

㉞ Value Placeholder ไม่ใช่ Column Placeholder

oxmysql prepare Documentation ปัจจุบันระบุว่า:

ใช้สำหรับ Value Placeholders และ ?? Column Placeholders / Named Placeholders ไม่รองรับใน API นั้น.

ดังนั้นอย่าเขียน:

SELECT ?
FROM `players`;

แล้วหวังว่า Parameter:

identifier

จะถูกตีความเป็นชื่อ Column แบบเดียวกับ SQL Identifier

㉟ Dynamic Column Name ต้อง Whitelist

ถ้าต้อง Dynamic Sort:

name
created_at
level

อย่านำ Client Inputมาต่อ SQLโดยตรง

ใช้ Mapping:

local allowedColumns = {
    name = '`name`',
    created = '`created_at`',
    level = '`level`'
}

แล้วเลือกเฉพาะค่าที่ Serverกำหนด

ส่วน Valuesจริงยังส่งด้วย ?

㊱ Reserved Keyword ก็ต้องระวัง

MariaDB มีรายการ Keywords ผ่าน information_schema.KEYWORDS.

ถ้า Columnใช้ชื่อที่ชน Keyword หรือ SQL Parserตีความได้หลายแบบ ควรใช้ Identifier Quoting/ชื่อที่ชัดเจนตาม Schema

อย่างไรก็ตาม ถ้า Resourceและ Official Schemaใช้ชื่อเดียวกันอยู่แล้ว อย่า Rename Production Columnเพียงเพราะชื่อดูแปลกโดยไม่ตรวจ Dependencies

㊲ Error หลังเพิ่ม Custom Column

สมมติ Adminเพิ่ม:

vip_level

บน Development Database

แต่ลืมเพิ่มใน Production

Custom Resource Query:

SELECT `vip_level`
FROM `players`;

Devทำงาน

Production:

ดังนั้น Custom Database Changesต้องมี Migration Scriptเหมือน Resource Changesอื่น

㊳ ห้ามแก้ Production ด้วยการจำจาก Dev

ใช้:

SHOW CREATE TABLE `players`;

จากทั้ง Dev และ Production แล้วเทียบจริง

MariaDB SHOW CREATE TABLE แสดง Definition ของ Table จึงเหมาะกับ Schema Comparison.

อย่าเดาว่า:

น่าจะเหมือนกัน

㊴ information_schema ช่วยเปรียบเทียบ Columns ได้

ตัวอย่าง:

SELECT
    COLUMN_NAME,
    COLUMN_TYPE,
    IS_NULLABLE,
    COLUMN_DEFAULT
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME = 'players'
ORDER BY ORDINAL_POSITION;

MariaDB information_schema.COLUMNS มีข้อมูล Type, Default และ Nullability ของแต่ละ Column.

เหมาะกับการสร้าง Schema Checklist

㊵ Column ถูกลบโดย Migration

บางครั้ง Migrationใหม่ตั้งใจ:

DROP old_column

เพราะข้อมูลย้ายไป Tableใหม่

Custom Scriptยังอ้าง:

old_column

Error 1054จึงถูกต้อง

อย่าเพิ่ม old_column กลับทันที

ต้องตรวจว่า Resourceใหม่ควรอ่านข้อมูลจาก:

new_column
หรือ
new_table

แทน

㊶ Data Migration กับ Schema Migration ต้องทำคู่กัน

สมมติ:

fullname

ถูกแยกเป็น:

firstname
lastname

การเพิ่ม Columnsอย่างเดียวอาจยังไม่พอ

ต้อง Backfill Existing Data ตาม Migration Logic

ดังนั้นการแก้ 1054 ด้วย:

ADD COLUMN

โดยไม่มี Data Migration อาจทำให้ Errorหายแต่ข้อมูลเก่ากลายเป็น NULL/Default

㊷ Column Type ต้องตรงด้วย

เมื่อจะเพิ่ม Columnที่หาย อย่าเพียงให้ชื่อเหมือนกัน

ต้องตรวจ:

Type
Length
NULL
DEFAULT
Index
Unique
Foreign Key
Character Set

เพราะ Resourceอาจคาด:

VARCHAR(50)

แต่คุณสร้าง:

INT

แล้ว Errorถัดไปจะกลายเป็น:

1366 Incorrect Value
1264 Out of Range
1406 Data Too Long

㊸ Error 1054 มักเป็น Error ตัวแรกของ Schema Mismatch

หลังแก้ Columnแรก อาจเจอ:

Unknown column 'column_b'

ต่อ

ถ้าเป็นแบบนี้หลาย Columnหลัง Update อย่าแก้ทีละ Columnด้วยมือ

นั่นเป็นสัญญาณแรงว่า:

Database Schema Version
ไม่ตรง
Resource Version

ควรหยุดและหา Migrationทั้งชุด

㊹ 5 Unknown Columns พร้อมกันควรทำอย่างไร

ถ้า Consoleขึ้น:

Unknown column 'citizenid'
Unknown column 'metadata'
Unknown column 'last_seen'
Unknown column 'account_id'
Unknown column 'status'

หลัง Updateเดียว

อย่าทำ:

ALTER TABLE ADD
ALTER TABLE ADD
ALTER TABLE ADD
...

จากการเดา

ให้หา Official Migration ของ Releaseนั้นก่อน

นี่มักเร็วและปลอดภัยกว่ามาก

㊺ mysql_debug ช่วยหา Resource ที่ส่ง Query

Official oxmysql Documentation ระบุว่า:

set mysql_debug true

จะพิมพ์ Queriesใน Server Console และสามารถจำกัดรายชื่อ Resourcesที่ต้อง Debugได้.

ตัวอย่าง:

set mysql_debug [
  "my_resource"
]

เหมาะกับกรณี:

Unknown column

แต่ Error Stackไม่ชัดว่า Resourceไหนเป็นต้นเหตุ

㊻ Debug UI ของ oxmysql

oxmysql Debug UI สามารถแสดง Queriesที่ Resources Execute, Response Time และ Statisticsแยกตาม Resource โดย Documentationแนะนำใช้ใน Developmentหรือ Server Player Countต่ำ.

จึงช่วยตอบ:

Resource ไหน
Query ไหน
ใช้ Column อะไร

ได้รวดเร็ว

㊼ ไม่ต้องเปิด Debug ทั้ง Production ตลอดเวลา

ถ้า Serverมี Playersจำนวนมาก Official oxmysql Documentationแนะนำว่าควรพิจารณา Database Loggingที่เหมาะสมแทนการเปิด Debug UIแบบถาวร.

ใช้ Debugเพื่อจับ Errorแล้วปิด/จำกัด Resourceตามความเหมาะสม

㊽ วิธี Debug แบบ 5 นาที

เมื่อ Consoleขึ้น:

Unknown column 'citizenid' in 'field list'

ทำ:

① จด Error Code = 1054
② จด Column = citizenid
③ จด Context = field list
④ หา Resource
⑤ Copy Query
⑥ SHOW COLUMNS FROM table
⑦ SHOW CREATE TABLE table
⑧ ตรวจ DATABASE()
⑨ ตรวจ Resource Version
⑩ ตรวจ Migration

จากนั้นค่อยตัดสินว่า:

Query ผิด
หรือ
Schema เก่า

㊾ ตัวอย่าง Case 1 — Migration ไม่ได้รัน

Error:

Unknown column 'metadata'
in 'field list'

Resourceใหม่ Query:

SELECT
    `identifier`,
    `metadata`
FROM `players`;

แต่:

SHOW COLUMNS FROM `players`;

มี:

identifier
name
created_at

ไม่มี:

metadata

ตรวจ Release Migrationพบว่ารุ่นใหม่เพิ่ม Metadata Column

Root Cause:

Resource ใหม่
+
Schema เก่า

แก้ด้วย Migrationของ Versionนั้น

㊿ ตัวอย่าง Case 2 — Custom Script ใช้ Framework ผิด

Custom Script:

SELECT `citizenid`
FROM `players`;

แต่ Frameworkของ Serverใช้:

identifier

และไม่มี citizenid

ในกรณีนี้ไม่ควรเพิ่ม citizenid ให้ Databaseทันที

ต้องแก้ Integrationให้ใช้ Identity Columnที่ Frameworkจริงใช้

51. ตัวอย่าง Case 3 — Table Alias ผิด

Query:

SELECT
    p.`identifier`
FROM `players` p
JOIN `characters` c
    ON x.`player_id` = p.`id`;

Aliasที่ประกาศมี:

p
c

แต่ Queryใช้:

นี่คือ SQL Query Bug

Schemaไม่ต้องเปลี่ยน

52. ตัวอย่าง Case 4 — Column อยู่ผิด Table

Query:

SELECT
    p.`firstname`
FROM `players` p;

แต่ firstname อยู่:

characters

ตรวจด้วย:

SELECT
    TABLE_NAME
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = DATABASE()
  AND COLUMN_NAME = 'firstname';

พบ:

characters

จึงต้องแก้ Join/Queryให้ถูก Table.

53. ตัวอย่าง Case 5 — Database ผิดตัว

SHOW CREATE TABLE players ใน phpMyAdmin:

มี citizenid

แต่ FiveMยัง Error

ตรวจ:

SELECT DATABASE();

ได้:

fivem_old

ขณะที่ Schemaใหม่อยู่:

fivem_new

MariaDB DATABASE() ใช้ดู Default Databaseของ Session.

ให้แก้ Connection/Migration Targetให้ตรง

54. ตัวอย่าง Case 6 — String ไม่ถูก Parameterize

ผิด:

local query =
    "SELECT * FROM players WHERE status = " ..
    status

เมื่อ:

status = active

SQLที่เกิดขึ้น:

SELECT *
FROM players
WHERE status = active;

active อาจถูกตีความเป็น Identifier แทน String Literal

ควร:

MySQL.query.await(
    'SELECT * FROM `players` WHERE `status` = ?',
    {
        status
    }
)

oxmysql Placeholdersใช้ส่ง Parametersแยกจาก Query Structure.

55. Unknown Column จาก SELECT *

SELECT * เองไม่ทำให้ Unknown Columnจาก Field Listที่ไม่ได้ระบุ

แต่ Errorอาจเกิดใน:

WHERE
JOIN
ORDER BY
GROUP BY

ของ Queryเดียวกัน

ตัวอย่าง:

SELECT *
FROM `players`
ORDER BY `last_seen`;

ถ้าไม่มี:

last_seen

ก็ยัง Errorได้

ดังนั้น Copy Queryเต็มก่อน Debug

56. ORDER BY Column หาย

Resourceใหม่อาจเพิ่ม Feature:

เรียงตาม last_seen

แต่ Migrationไม่ได้เพิ่ม:

last_seen

Query:

SELECT *
FROM `players`
ORDER BY `last_seen` DESC;

จะล้มเหลว

Root Causeยังเป็น Schema Versionไม่ตรง

57. GROUP BY Column หาย

เช่น:

SELECT `job`, COUNT(*)
FROM `players`
GROUP BY `job`;

ถ้า jobถูกย้ายไป Tableอื่นแล้ว Queryเก่ายังใช้ก็เกิด Errorได้

อย่าเพิ่ม jobกลับก่อนตรวจ Data Modelใหม่

58. INSERT Column หาย

Query:

INSERT INTO `players`
(
    `identifier`,
    `metadata`
)
VALUES
(
    ?,
    ?
);

ถ้า metadataไม่มีใน Table MariaDBไม่สามารถ Insertได้

นี่ต่างจาก Error 1364 ซึ่ง Fieldมีอยู่แต่ไม่ได้รับค่าหรือ Default

จำ:

1054
Columnไม่มี

1364
Columnมี
แต่ Required Value/Defaultไม่มี

59. UPDATE Column หาย

Query:

UPDATE `players`
SET `last_seen` = NOW()
WHERE `identifier` = ?;

ถ้า last_seenไม่มี:

ไม่ใช่ Error Date/Datetime

เพราะ Databaseยังไม่ถึงขั้นตรวจค่าของ NOW()

มันหา Columnไม่เจอก่อน

60. ALTER TABLE ควรใช้เมื่อยืนยันแล้วว่า Schema ขาดจริง

MariaDBรองรับการเพิ่ม Columnด้วย:

ALTER TABLE ...
ADD COLUMN ...

และรองรับการแก้ Definitionผ่าน ALTER TABLE.

แต่ก่อนทำ Production ควร:

Backup
ตรวจ Official Migration
ตรวจ Existing Data
ตรวจ Index/Constraint
ทดสอบบนสำเนา

61. อย่าลืม Default และ Existing Rows เมื่อ ADD COLUMN

สมมติ Official Migrationเพิ่ม:

`status` VARCHAR(20) NOT NULL DEFAULT 'active'

ถ้าคุณสร้างเพียง:

ADD COLUMN `status` VARCHAR(20);

Schemaจะไม่เท่ากัน

แม้ Error 1054หาย แต่ Behaviorของ Resourceอาจผิด

นี่คือเหตุผลว่าทำไมควรใช้ Migrationจริง

62. Backup ก่อน Schema Change

Error 1054หลายกรณีแก้ด้วย Codeโดยไม่ต้องแตะ Database

แต่ถ้าต้อง:

ADD COLUMN
CHANGE COLUMN
DROP COLUMN

Productionควร Backupก่อน

เพราะ Schema Changeอาจกระทบ Existing Dataและ Resourcesอื่นที่ใช้ Tableเดียวกัน

63. ถ้า Tableใหญ่มากอย่า ALTER แบบรีบๆ

MariaDB ALTER TABLE มีหลาย Operations/Algorithms และผลกระทบขึ้นกับ Operationกับ Table/Engine.

Server Productionที่มี Tableใหญ่ควรทดสอบ Migrationและวาง Maintenance Windowตามความเหมาะสม

อย่าทำ Liveเพียงเพราะต้องการให้ Consoleเงียบเร็ว

64. Error 1054 หลังแก้แล้วควรตรวจอะไรต่อ

หลัง Migration:

SHOW COLUMNS FROM `players`;

จากนั้น:

SHOW CREATE TABLE `players`;

ยืนยันว่า Columnมี Definitionตรงกับ Official Schema.

แล้ว Test:

Resource Start
Player Join
Load Character
Save Character
Reconnect
Relevant Feature

65. Checklist FiveM Error 1054

ตรวจทั้งหมดนี้:

Error Code เป็น 1054 หรือไม่
SQLSTATE เป็น 42S22 หรือไม่
Column ชื่ออะไร
Errorอยู่ field list หรือไม่
Errorอยู่ where clause หรือไม่
Errorอยู่ Join/ON หรือไม่
Resource ไหนส่ง Query
Queryเต็มคืออะไร
Tableไหน
Aliasไหน
SHOW COLUMNS มี Columnหรือไม่
SHOW CREATE TABLE มี Columnหรือไม่
Columnอยู่ Tableอื่นหรือไม่
information_schema.COLUMNS พบ Columnที่ไหน
พิมพ์ชื่อผิดหรือไม่
Columnถูก Renameหรือไม่
Columnถูก Dropหรือไม่
Resourceเพิ่ง Updateหรือไม่
Migrationรันหรือยัง
Resource Versionตรง Schemaหรือไม่
Frameworkตรงกับ Scriptหรือไม่
Custom Scriptเก่าหรือไม่
Databaseถูกตัวหรือไม่
SELECT DATABASE() ได้อะไร
Connection Stringชี้ Databaseไหน
Restore Backupเก่าหรือไม่
SQL Importครบหรือไม่
Resourceใช้ Dynamic Columnหรือไม่
Dynamic Columnผ่าน Whitelistหรือไม่
Valueถูกต่อเข้า SQLโดยตรงหรือไม่
ควรใช้ Parameterหรือไม่
Aliasถูกต้องหรือไม่
Column Typeตาม Migrationคืออะไร
Default/NULLถูกต้องหรือไม่
Backupก่อน ALTERแล้วหรือไม่

ตาราง Error ที่ควรแยกให้ออก

Error	ความหมายหลัก
`1048`	Column ไม่รับ NULL
`1049`	Unknown Database
`1054`	Unknown Column
`1062`	Duplicate Entry
`1064`	SQL Syntax Error
`1146`	Table Doesn't Exist
`1264`	Out of Range
`1265`	Data Truncated
`1292`	Incorrect/Truncated Value
`1364`	Field ไม่มี Default
`1366`	Incorrect Value
`1406`	Data Too Long
`1452`	Foreign Key Constraint Fail

MariaDB Error Reference แยก Error 1054 เป็น ER_BAD_FIELD_ERROR ชัดเจน.

FiveM Unknown Column แก้อย่างไร

เริ่มจาก:

SHOW COLUMNS FROM `table_name`;

และ:

SHOW CREATE TABLE `table_name`;

MariaDBรองรับคำสั่งทั้งสองสำหรับตรวจ Column Metadata และ Table Definition.

จากนั้นเทียบกับ Queryของ Resource

ถ้า:

Resource Query มี Column
Database ไม่มี Column

ต้องหาว่า:

Migrationขาด
หรือ
Resourceใช้ Schemaผิด

FiveM Error 1054 คืออะไร

คือ:

ER_BAD_FIELD_ERROR

SQLSTATE:

42S22

ข้อความ:

Unknown column '...' in '...'

FiveM Unknown Column in Field List คืออะไร

หมายถึง MariaDBหา Column/Identifierที่ Queryอ้างถึงใน Field Contextนั้นไม่พบ

ตรวจ:

SELECT list
INSERT column list
UPDATE assignment

และดูชื่อ Table/Aliasที่ Columnควรอยู่

FiveM Unknown Column in WHERE Clause แก้อย่างไร

ตรวจ:

SHOW COLUMNS FROM `table_name`;

แล้วเทียบกับ:

WHERE `column_name` = ?;

หาก Columnถูก Renameหลัง Framework Update ให้แก้ Resourceให้ใช้ Schemaปัจจุบันหรือ Apply Migrationที่ถูก Version

FiveM Unknown Column หลัง Update Script แก้อย่างไร

ตรวจตามนี้:

Resource Version
↓
Migration Files
↓
SHOW CREATE TABLE
↓
Column ที่ Resource Query

ถ้าหลาย Columnsหายพร้อมกันหลัง Update มีโอกาสสูงว่า Database Migrationยังไม่ครบ มากกว่าจะเป็น Columnผิดทีละตัว

FiveM Unknown Column หลังเปลี่ยน Framework แก้อย่างไร

ตรวจว่า Custom Scriptใช้ชื่อ Fieldsของ Frameworkเดิมหรือไม่ เช่น:

identifier
citizenid
character_id
owner

อย่าเพิ่ม Columnsของ Frameworkเดิมกลับเข้า Databaseใหม่แบบสุ่ม

ควรแก้ Integrationให้ตรง Data Modelของ Frameworkปัจจุบัน

FiveM Unknown Column หลัง Restore Database แก้อย่างไร

ถ้า Backupเก่ากว่า Resource Files:

Tableอาจอยู่ครบ
แต่ Columnsใหม่หาย

ให้ Apply Migrationsจาก Version Backupไป Versionปัจจุบันตามลำดับ

ไม่ควร Import Fresh Schemaทับ Dataโดยอัตโนมัติ

FiveM Unknown Column ทั้งที่ Column มีอยู่ทำอย่างไร

ตรวจ:

SELECT DATABASE();

จากนั้นตรวจ:

Table Alias
Tableจริง
Connection String
Databaseที่ phpMyAdminกำลังเปิด

MariaDB DATABASE() คืน Databaseปัจจุบันของ Session และ oxmysql Connection Stringกำหนด Databaseที่ FiveMใช้งาน.

FiveM ดู Columns ทั้ง Table อย่างไร

ใช้:

SHOW COLUMNS FROM `players`;

MariaDBจะแสดง Columnsและข้อมูลพื้นฐานของแต่ละ Field.

หรือใช้:

SHOW CREATE TABLE `players`;

เพื่อดู Definitionเต็ม.

FiveM หา Column ทั้ง Database อย่างไร

ใช้:

SELECT
    TABLE_NAME,
    COLUMN_NAME,
    DATA_TYPE
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = DATABASE()
  AND COLUMN_NAME = 'column_name';

MariaDB information_schema.COLUMNS เก็บ Metadataของ Columnsทุก Tablesบน Server.

FiveM เพิ่ม Column ยังไง

ถ้า Official Migrationยืนยันว่าต้องเพิ่มจริง สามารถใช้ MariaDB ALTER TABLE ... ADD COLUMN ตาม Definitionที่ Resourceกำหนด.

ตัวอย่างเชิงโครงสร้าง:

ALTER TABLE `players`
ADD COLUMN `status`
VARCHAR(20)
NOT NULL
DEFAULT 'active';

แต่ ห้ามคัดลอกตัวอย่างนี้ไปใช้กับ Columnอื่นโดยไม่ดู Official Schema

FiveM ใช้ mysql_debug หา Query ได้ไหม

ได้ Official oxmysql Documentationระบุว่า:

set mysql_debug true

จะ Print Queriesใน Server Console และสามารถจำกัดเฉพาะ Resourcesที่ต้องการ Debugได้.

เหมาะกับ Error 1054 ที่ไม่รู้ว่า Scriptตัวไหนเรียก Columnผิด

FiveM oxmysql Debug UI ช่วยไหม

ช่วยได้ โดย Debug UI แสดง Queriesที่ Resources Execute, Query Response Times และ Statistics ต่อ Resource.

ใช้ใน Developmentหรือ Player Countต่ำตามคำแนะนำของ Documentation

FiveM ใช้ ? แทน Column Name ได้ไหม

ไม่ควรใช้ Value Placeholder ? เพื่อแทน SQL Column Identifier แบบทั่วไป

oxmysql prepare ระบุว่ารองรับ ? สำหรับ Value Placeholders และไม่รองรับ ?? Column Placeholdersหรือ Named Placeholdersใน APIนี้.

Dynamic Columnควร Whitelistใน Codeก่อนสร้าง Query

FiveM Unknown Column เกิดจาก String ไม่ใส่ Quote ได้ไหม

เกิดได้ในเชิง Query Construction หากค่าที่ตั้งใจให้เป็น Stringถูกเขียนเป็น Bare SQL Identifier

วิธีที่ปลอดภัยและชัดกว่าคือใช้ Parameter:

WHERE `status` = ?

แล้วส่งค่าแยกผ่าน oxmysql Placeholder.

FAQ FiveM MariaDB Unknown Column

Error 1054 คืออะไร?

MariaDB Error 1054 คือ ER_BAD_FIELD_ERROR หรือ Unknown column.

SQLSTATE 42S22 คืออะไร?

เป็น SQLSTATE ที่ MariaDBระบุสำหรับ Error 1054 Unknown Column.

Unknown Column หมายถึง Table ไม่มีไหม?

ไม่ Tableอาจมีอยู่แล้ว แต่ Columnที่ Queryอ้างถึงไม่อยู่ใน Table/Contextนั้น

ดู Column ของ Table ยังไง?

ใช้:

SHOW COLUMNS FROM `table_name`;

ดู Schemaเต็มยังไง?

ใช้:

SHOW CREATE TABLE `table_name`;

Unknown Column หลัง Update Script เกิดจาก Migrationได้ไหม?

ได้ หาก Resourceใหม่เรียก Columnที่ Database Schemaเก่ายังไม่มี การไม่ได้ Apply Migrationเป็นสาเหตุสำคัญที่ควรตรวจ

Unknown Column หลัง Restore Backup เกิดได้ไหม?

ได้ ถ้า Backup Databaseเก่ากว่า Resource Versionปัจจุบัน Tablesอาจอยู่ครบแต่ Columnsรุ่นใหม่หาย

Unknown Column หลังเปลี่ยน Framework เกิดได้ไหม?

ได้ เพราะ Frameworkต่างกันสามารถใช้ชื่อ Columns/Data Modelต่างกัน Custom Scriptเก่าจึงอาจอ้าง Fieldsที่ Frameworkใหม่ไม่มี

ต้อง ADD COLUMN ทุกครั้งไหม?

ไม่ ต้องยืนยันก่อนว่า Official Schemaควรมี Columnนั้นจริง เพราะบางครั้ง Queryของ Resourceเป็นฝ่ายผิด

Column มีอยู่แล้วแต่ยัง Error ทำอย่างไร?

ตรวจ:

SELECT DATABASE();

พร้อมดู Table Alias, Connection String และ Databaseจริงที่ FiveMใช้.

ใช้ information_schema หา Columnได้ไหม?

ได้ information_schema.COLUMNS มี Metadataของ Columnsใน Tablesทุก Database.

mysql_debug ช่วยได้ไหม?

ได้ สามารถ Print Queriesที่ oxmysql Executeใน Server Console และจำกัด Resourcesที่ Debugได้.

ใช้ ? แทนชื่อ Columnได้ไหม?

? ใน oxmysql Prepareถูกออกแบบเป็น Value Placeholder ไม่ใช่ Dynamic Column Placeholder.

ประเด็นสำคัญ

เมื่อ FiveMขึ้น:

ERROR 1054
Unknown column '...' in '...'

อย่าเริ่มจาก:

ADD COLUMN แบบเดา
Import SQL ซ้ำ
เปลี่ยน Framework Table แบบสุ่ม

ให้ใช้ Flow นี้:

1054
↓
ดู Column ใน Error
↓
ดู field list / where / join
↓
หา Resource และ Query
↓
SHOW COLUMNS
↓
SHOW CREATE TABLE
↓
SELECT DATABASE()
↓
ตรวจ Resource Version
↓
ตรวจ Migration
↓
ตรวจ Framework/Data Model
↓
แก้ Query หรือ Schemaให้ตรงกัน

MariaDBกำหนด Error 1054 เป็น Unknown column และมีเครื่องมือมาตรฐานอย่าง SHOW COLUMNS, SHOW CREATE TABLE และ information_schema.COLUMNS สำหรับยืนยันว่า Columnมีอยู่จริง อยู่ Tableไหน และมี Definitionอย่างไร.

ถ้า Errorเกิดทันทีหลัง Updateและมี Columnsหายหลายตัว อย่าแก้ทีละ Columnด้วยมือ เพราะมักเป็นสัญญาณว่า Resourceกับ Database Schemaอยู่คนละ Version ให้หา Migrationของ Releaseนั้นก่อน ส่วนถ้า Errorเกิดเฉพาะ Custom Resourceหนึ่งตัวในขณะที่ Frameworkอื่นทำงานปกติ ให้สงสัย Queryหรือ Framework Compatibilityของ Resourceนั้นก่อน

สำหรับผู้อ่าน comsiam ให้จำสูตร “1054 = Table มี แต่ชื่อ Column ที่ Scriptเรียกไม่ตรง Schema” และ comsiam แนะนำให้เทียบ Query → SHOW COLUMNS → SHOW CREATE TABLE → Migration ตามลำดับ เพราะวิธีนี้ช่วยแยกได้ชัดว่า Databaseขาด Columnจริง หรือ Scriptเป็นฝ่ายเรียก Columnผิด โดยไม่ต้องแก้ Schemaแบบลองผิดลองถูก