FiveM MySQL Table Doesn't Exist และ Unknown Column แก้อย่างไร? ตรวจ Schema, SQL Migration และ Resource Version ให้ตรงกัน

August 17, 2026

ปัญหา FiveM Database ขึ้น Table Doesn't Exist หรือ Unknown Column มักเกิดหลังติดตั้ง Resource ใหม่ อัปเดต Script ย้าย Database หรือ Import SQL ไม่ครบ แม้ MySQL/MariaDB จะเชื่อมต่อสำเร็จแล้วก็ตาม

ตัวอย่าง Error ที่พบบ่อย:

Table 'fivem.players' doesn't exist

Table 'fivem.owned_vehicles' doesn't exist

Unknown column 'citizenid' in 'field list'

Unknown column 'last_login' in 'where clause'

ER_NO_SUCH_TABLE

ER_BAD_FIELD_ERROR

จุดสำคัญคือ Error กลุ่มนี้ ต่างจาก MySQL Connection Error

ถ้าคุณเห็น:

Access denied

หรือ:

ECONNREFUSED

แปลว่ายังมีปัญหาที่การเชื่อมต่อ

แต่ถ้าเห็น:

Table doesn't exist

หรือ:

Unknown column

แปลว่า FiveM สามารถส่ง Query ไปถึง Database ได้แล้ว แต่ Database Schema ไม่ตรงกับสิ่งที่ Resource ต้องการ

หลักการแก้จึงเป็น:

หา Resource ที่ Error → หา Table/Column → ตรวจ Database จริง → ตรวจไฟล์ SQL/Migration → Backup → ปรับ Schema ให้ตรง Version → Test

① Table Doesn't Exist คืออะไร

หมายถึง Resource กำลัง Query Table ชื่อหนึ่ง แต่ใน Database ที่เชื่อมอยู่ไม่มี Table นั้น

ตัวอย่าง:

SELECT * FROM players;

แต่ Database ไม่มี:

players

Query จึงล้มเหลว

② Unknown Column คืออะไร

หมายถึง Table มีอยู่ แต่ไม่มี Column ที่ Query กำลังเรียกใช้

เช่น:

SELECT citizenid FROM players;

แต่ Table players ไม่มี Column:

citizenid

③ Table Missing กับ Column Missing ต่างกันอย่างไร

Table Missing

ไม่มีทั้ง Table

Unknown Column

Table มี แต่โครงสร้างภายในไม่ตรง

④ Error นี้แปลว่า Database เชื่อมได้แล้วหรือไม่

โดยทั่วไปใช่

เพราะ Database ต้องรับ Query ก่อนจึงจะสามารถตอบว่า:

Table ไม่มี
Column ไม่มี

⑤ จึงไม่ควรเปลี่ยน Password ก่อน

ถ้า Error เป็น:

Unknown column

การเปลี่ยน Database Password ไม่ได้แก้ Schema

⑥ ตัวอย่าง Table Missing

Table 'fivem.users' doesn't exist

หมายความว่า Resource คาดหวัง Table:

users

ใน Database:

fivem

แต่หาไม่พบ

⑦ ตัวอย่าง Unknown Column

Unknown column 'firstname'

หมายความว่า Queryเรียก Column:

firstname

แต่ Tableจริงไม่มี

⑧ สาเหตุอันดับแรก — ยังไม่ได้ Import SQL

Resource FiveM หลายตัวให้ไฟล์:

install.sql

database.sql

schema.sql

ต้อง Import ก่อนใช้งาน

⑨ แค่ลาก Resource ลง Folder ยังไม่พอ

หลาย Scriptsต้องทำทั้ง:

ติดตั้ง Resource
Import SQL
ตั้ง Config
Start Resource

⑩ Resource โหลดได้แต่ Table ไม่ถูกสร้างเอง

เป็นเรื่องปกติสำหรับ Scriptบางประเภท

ไม่ใช่ทุก Resourceทำ Auto Migration

⑪ วิธีหาไฟล์ SQL

เปิด Folderของ Resourceแล้วมองหา:

.sql

หรือ Folderชื่อ:

sql
database
migrations

⑫ README สำคัญมาก

ผู้พัฒนาอาจระบุว่า:

Import install.sql before starting the resource.

หรือให้ Run Migrationเฉพาะ Version

⑬ อย่า Import SQL ทุกไฟล์พร้อมกัน

เพราะอาจมี:

install.sql
update_1.sql
update_2.sql

ที่ต้องทำตามลำดับ

⑭ Migration คืออะไร

Migration คือการเปลี่ยน Database จาก Schema Versionเดิมไป Versionใหม่

เช่น:

Version 1:

users
- id
- name

Version 2:

users
- id
- name
- last_login

⑮ ถ้า Update Script แต่ไม่ Migration

Codeใหม่อาจ Query:

last_login

แต่ Databaseเก่ายังไม่มี

จึงเกิด:

Unknown column 'last_login'

⑯ Errorหลัง Update Resource ให้สงสัย Migrationก่อน

โดยเฉพาะถ้า Serverทำงานได้ก่อน Update

⑰ Errorหลังติดตั้ง Resource ใหม่

ให้ตรวจว่า:

Import SQLครบหรือยัง

ก่อนแก้ Source Code

⑱ Errorหลังย้าย Hosting

อาจเกิดจาก Restore Databaseไม่ครบ

เช่น Restore:

Users

แต่ไม่ได้ Restore:

Business Tables

⑲ Errorหลังเปลี่ยน Framework

ยิ่งมีโอกาสสูง

เพราะ Frameworkต่างกันอาจใช้:

Table Names
Column Names

คนละแบบ

⑳ ESX กับ QBCore Schema เหมือนกันไหม

ไม่ควรถือว่าเหมือนกัน

Resourceต้องรองรับ Frameworkที่ Serverใช้อยู่จริง

㉑ Resourceสำหรับ ESX เอาไปใช้ QBCoreตรง ๆ ได้ไหม

ไม่เสมอไป

แม้ Resourceเปิดได้ แต่ Queryอาจเรียก Table/Columnคนละแบบ

㉒ Framework Bridge คืออะไร

Resourceบางตัวมี Codeกลางเพื่อรองรับหลาย Framework

แต่ต้องเลือก Configให้ถูก

㉓ Configผิด Framework ทำ Unknown Column ได้

ตัวอย่าง Resourceมี:

Framework = ESX

แต่ Serverจริงเป็น:

QBCore

Resourceอาจยิง Queryผิด Schema

㉔ ตรวจ Framework Config ก่อนแก้ Database

สำคัญมาก

อย่าเพิ่ม Column ESXลง QBCoreเพียงเพื่อให้ Errorหาย หาก Resourceตั้ง Frameworkผิด

㉕ Table Prefix คืออะไร

บางระบบใช้ชื่อ Tableที่มี Prefix เช่น:

esx_users

หรือ:

qb_players

ขึ้นอยู่กับ Script

㉖ Resourceคาดชื่อ Tableหนึ่ง แต่ Databaseใช้อีกชื่อ

อาจต้อง:

แก้ Config
ใช้ Compatibility Layer
ใช้ Version Resourceที่ถูก

ไม่ควร Rename Tableทันที

㉗ วิธีดู Table ทั้งหมด

Database Clientทั่วไปสามารถแสดงรายการ Tablesใน Databaseที่เลือก

หรือใช้ SQL:

SHOW TABLES;

㉘ ถ้า Tableที่ Errorไม่มีจริง

คำถามต่อไปคือ:

มันควรถูกสร้างโดย Resource ไหน?

㉙ อย่าสร้าง Tableเปล่าด้วยตัวเองทันที

เช่นเห็น:

Table 'phone_messages' doesn't exist

แล้วสร้าง:

CREATE TABLE phone_messages (...);

แบบเดาเอง

เพราะ Column, Index และ Constraints อาจผิดทั้งหมด

㉚ ใช้ Schemaจาก Resourceจริง

เป็น Sourceที่เหมาะกว่า

㉛ วิธีดู Structure Table

ใช้:

DESCRIBE players;

㉜ หรือ

SHOW CREATE TABLE players;

ช่วยเห็น:

Columns
Types
Indexes
Defaults

㉝ Unknown Column ต้องตรวจชื่อจริง

เช่น Error:

Unknown column 'charinfo'

ดูว่า Tableมี:

char_info

หรือ:

charinfo

หรือไม่

㉞ พิมพ์ผิดหนึ่งตัวก็ Error

เช่น:

citizenid

กับ:

citizen_id

เป็นคนละชื่อ

㉟ Resource Updateอาจ Rename Column

เช่น Versionเก่า:

identifier

Versionใหม่:

citizenid

ถ้า Migrationไม่ครบก็ Error

㊱ Rename Columnเองอันตรายไหม

อันตรายถ้า Resourceอื่นยังใช้ชื่อเก่า

Server FiveMมักมีหลาย Scriptsใช้ Tableเดียวกัน

㊲ Shared Table คืออะไร

Tableหลักที่ Resourcesหลายตัวใช้ร่วมกัน เช่น:

players
users
owned_vehicles

ขึ้นอยู่กับ Framework

㊳ เปลี่ยน Shared Table ต้อง Searchทั้ง Server

ก่อนเปลี่ยน:

identifier

ควรค้นว่า Resourceไหนเรียก Columnนี้อยู่บ้าง

㊴ วิธีค้น Source Code

ค้นชื่อ Columnที่ Error เช่น:

citizenid

ใน Folder Resources

㊵ หา Queryที่สร้าง Error

มองหา:

SELECT
INSERT
UPDATE
DELETE

ที่ใช้ Columnนั้น

㊶ Consoleมักบอก Resource Name

เช่น:

@my-garage/server.lua

ช่วยจำกัด Scopeได้มาก

㊷ Consoleบอก Line Numberได้ไหม

บาง Error Stackมี:

server.lua:204

เปิดไฟล์บริเวณนั้นได้ทันที

㊸ อย่าแก้ Databaseทั้ง Serverเพราะ Resourceเดียว

ถ้า Errorมาจาก:

my_custom_phone

ให้ตรวจ Resourceนั้นก่อน

㊹ Resource Disableแล้ว Serverกลับปกติ

ช่วยยืนยันว่า Resourceนั้นเกี่ยวข้อง

แต่ไม่ใช่ Fixถาวรถ้าต้องการ Featureนั้น

㊺ Table Exists แต่ชื่อ Databaseผิด

อาจมี Databaseสองตัว:

fivem_old
fivem_new

Resourceเชื่อม fivem_new

แต่ Tablesอยู่ fivem_old

㊻ นี่ทำให้ Table Doesn't Exist ทั้งที่คุณเห็น Tableอยู่

เพราะคุณกำลังดูคนละ Database

㊼ ตรวจ Connection Stringก่อน Importซ้ำ

โดยเฉพาะหลัง:

Migration
Hosting Move

㊽ Database Nameต้องตรง

ตรวจ:

Host
Database

ที่ FiveM Resourceกำลังใช้อยู่จริง

㊾ Tableมีใน phpMyAdmin แต่ FiveMบอกไม่มี

ตรวจว่า phpMyAdminเปิด Databaseเดียวกับ FiveMหรือไม่

㊿ Case Sensitivity มีผลไหม

ชื่อ Tableอาจมีพฤติกรรมเรื่องตัวพิมพ์ใหญ่/เล็กแตกต่างตาม Environment

แนวทางปลอดภัยคือใช้ชื่อให้ตรงกับ Schemaจริง

51. `Players` กับ `players`

ไม่ควรถือว่าเหมือนกันทุก Environment

52. Migrationจาก WindowsไปLinuxอาจเปิดเผยปัญหา Case

เพราะ Filesystem/Database Configurationอาจต่าง

53. Table Doesn't Existหลังย้าย OS

ตรวจ:

Table Name Case

เพิ่มเติม

54. Column Name Caseล่ะ

ควรเขียนให้ตรงกับ Resourceอยู่ดี

แม้ Behaviorอาจต่างจาก Table Names

55. SQL Importเข้าผิด Database

พบได้บ่อยมาก

เช่น Import SQLเข้า:

test

แต่ FiveMใช้:

production

56. ตรวจ Databaseก่อนกด Import

สำคัญ

57. SQL Fileมี `USE database_name;` ไหม

บาง Dumpกำหนด Databaseไว้ภายใน

อาจทำให้ Importไปคนละที่กับที่คิด

58. SQL Fileมี CREATE DATABASEไหม

ตรวจให้ดีก่อน Import Production

59. SQL Fileมี DROP TABLEไหม

อันตรายมาก

หาก Importทับ Serverจริงโดยไม่อ่าน

60. Backupก่อน Import SQL

เป็นกฎพื้นฐาน

โดยเฉพาะ Production

61. Install SQLกับUpdate SQLต่างกัน

Install:

สำหรับ Databaseใหม่

Update/Migration:

สำหรับ Databaseที่มีข้อมูลอยู่แล้ว

62. ห้ามใช้ Fresh Install SQLทับ Productionโดยไม่อ่าน

เพราะอาจ:

DROP Tables
Reset Defaults
ลบข้อมูล

63. Migrationควร Preserve Data

โดยทั่วไป Update Scriptที่ดีจะใช้:

ALTER TABLE
ADD COLUMN

มากกว่าลบ Tableทั้งหมด

แต่ต้องอ่าน SQLจริง

64. ADD COLUMN คืออะไร

เพิ่ม Columnใหม่

ตัวอย่าง:

ALTER TABLE players
ADD COLUMN last_login DATETIME NULL;

นี่เป็นเพียงตัวอย่างแนวคิด ไม่ควรรันกับ Serverจริงจนกว่าจะรู้ว่า Resourceต้องการ Definitionอะไร

65. MODIFY COLUMN คืออะไร

เปลี่ยน Type/Propertiesของ Columnที่มีอยู่

66. CHANGE COLUMN คืออะไร

อาจใช้เปลี่ยน:

Name
Definition

ตาม Database Syntax

67. DROP COLUMN คืออะไร

ลบ Column

มีความเสี่ยงต่อข้อมูลและ Resourcesอื่น

68. DROP TABLE คืออะไร

ลบทั้ง Table

ไม่ควรใช้เป็นวิธี Troubleshootทั่วไป

69. CREATE TABLE IF NOT EXISTS ช่วยอะไร

ใช้สร้าง Tableเมื่อยังไม่มี

แต่ Table Definitionยังต้องถูกต้อง

70. Error Table Existsตอน Import

อาจหมายถึง SQLกำลังสร้าง Tableที่มีอยู่แล้ว

อย่าแก้ด้วย Drop Tableทันที

71. Duplicate Columnตอน Migration

เช่น:

Duplicate column name 'last_login'

อาจหมายถึง Migrationนั้นเคย Runแล้วบางส่วน

72. อย่ารัน Migrationซ้ำต่อทันที

ตรวจ Stateก่อน

73. Partial Migration คืออะไร

Migrationทำได้ครึ่งหนึ่งแล้ว Error

ทำให้ Schemaอยู่ระหว่างสอง Versions

74. Partial Migrationอันตราย

Resourceอาจเห็น:

Columnบางตัวมี
บางตัวไม่มี

เกิด Errorหลายแบบต่อกัน

75. หลัง Migration Failควรทำอะไร

หยุด
อ่าน Error
ตรวจ Schema
ใช้ Backupถ้าจำเป็น

ไม่ควร Runซ้ำแบบเดา

76. Schema Version คืออะไร

สถานะว่า Databaseตรงกับ Resource Versionใด

77. Resource VersionกับSchema Versionควรตรงกัน

นี่คือหลักสำคัญ

78. Version mismatch ตัวอย่าง

Code:

v2.5

Database:

v1.9

Codeใหม่อาจเรียก Columnsที่ Databaseเก่าไม่มี

79. Changelogช่วยอะไร

ดูว่า Updateเพิ่ม:

Tables
Columns
Indexes

อะไร

80. GitHub Release Notesมีประโยชน์ไหม

ถ้าเป็น Sourceทางการของ Resource:

มีประโยชน์

โดยเฉพาะ Database Changes

81. อย่าใช้ SQLจากคนอื่นที่ใช้ Resourceคนละ Version

Schemaอาจต่างกัน

82. Copy Tableจาก Serverอื่นดีไหม

ไม่ควรเป็นวิธีแรก

เพราะ:

Resource Version
Framework
Config

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

83. Unknown Columnหลังเปลี่ยน Framework Version

เช่น Frameworkเองเปลี่ยน Schema

Resourceเก่าอาจยัง Query Columnเดิม

84. Resource Compatibilityสำคัญ

ต้องตรวจว่า Scriptรองรับ:

Framework Version
Database Schema

ที่คุณใช้อยู่

85. Legacy Resource คืออะไร

Scriptเก่าที่ไม่ได้ Updateให้ตรง Frameworkปัจจุบัน

86. Legacy Resourceอาจต้อง Patch

แต่ควรเข้าใจ Schemaก่อนแก้ Source

87. Hardcode Columnใหม่เข้า Databaseทุกครั้งไม่ใช่ทางยั่งยืน

เพราะ Resource Logicอาจยังไม่ตรง

88. ตัวอย่าง

Resourceคาด:

citizenid

แต่ Server Frameworkใช้:

identifier

เพิ่ม citizenidเปล่า ๆ อาจทำให้ Queryผ่านแต่ไม่มีข้อมูลจริง

89. Queryผ่าน ≠ ระบบทำงานถูกต้อง

นี่สำคัญมาก

90. Columnต้องมี Dataที่ถูกความหมายด้วย

ไม่ใช่เพียงมีชื่อ

91. Character Identifier สำคัญ

ถ้า Columnที่ Resourceใช้ Identify Playerว่างทั้งหมด:

Data Mappingอาจเสีย

92. DEFAULT NULLช่วยให้ Errorหายแต่ Logicอาจพัง

ถ้า Resourceต้องใช้ค่าจริงในการ Lookup

93. อย่าเพิ่ม Columnเป็น NULLทุกอย่าง

เพียงเพื่อหยุด Error

94. ดู Sourceว่าค่า Columnมาจากไหน

เช่น:

citizenid

ควรสัมพันธ์กับ Character Identifierจริง

95. Insert Queryต้องเขียน Columnนั้นด้วยไหม

ถ้า Resource SELECT Columnแต่ไม่มี Scriptใด INSERTค่า:

ต้องตรวจ Design

96. Schemaจาก Developerช่วยตอบได้

ดู CREATE TABLEต้นฉบับ

97. Default Valueสำคัญไหม

สำคัญ

Columnอาจต้อง:

NULL
0
Empty JSON

ตาม Resource Logic

98. JSON Columnคืออะไร

Resourceบางตัวเก็บข้อมูลรวมเป็น JSON เช่น:

Metadata
Inventory

99. Unknown Columnใน JSON Queryได้ไหม

ได้ถ้า SQLกำลังอ้าง Columnหลักที่เก็บ JSON

100. JSON Key Missingไม่เหมือน Unknown Column

ถ้า Columnมีแต่ Keyภายใน JSONไม่มี:

เป็น Application/Data Problemอีกแบบ

101. Table Prefixใน Configแก้ได้ไหม

บาง Resourcesให้ตั้ง:

tableName

หรือ Framework Adapter

ถ้ามีควรใช้ Configแทนแก้ Source

102. Config First Principle

ก่อนแก้ Code/Databaseให้ตรวจว่า Resourceมี Optionรองรับ Schemaของคุณอยู่แล้วหรือไม่

103. SQL Adapter คืออะไร

Codeที่แปลง Queryให้เข้ากับ Framework/Schemaต่าง ๆ

104. Bridge Folderมีไหม

Resourcesบางตัวแบ่ง:

bridge/esx
bridge/qb

เลือกผิดอาจยิง Queryผิด

105. Auto-detect Frameworkเชื่อถือได้เสมอไหม

ไม่จำเป็น

ถ้า Serverมีหลาย Core Resourcesหรือ Custom Frameworkอาจ Detectผิด

106. Manual Framework Configอาจดีกว่า

เมื่อ Developerรองรับ

107. Unknown Columnหลังเปิด Multi-Character

อาจเกิดจาก Resourceคาด Identifierแบบใหม่

108. Multi-Characterเปลี่ยน Data Modelได้

เช่น Accountหนึ่งมี Charactersหลายตัว

Resourceต้องอ้าง:

Character ID

ไม่ใช่ Account IDอย่างเดียว

109. Phone Resourceมักใช้ Tablesของตัวเอง

ถ้าไม่ Import SQL:

Messages
Contacts

อาจ Error

110. Housingก็เช่นกัน

อาจมี Tables:

properties
keys

ตาม Script

111. Garage Resourceอาจต้อง Migration

โดยเฉพาะการเพิ่ม:

Garage State
Impound Data

112. Inventory Resourceอาจเปลี่ยน Schema

เช่นย้ายจาก:

Dedicated Table
JSON Column

ไปอีก Design

113. Banking Resourceอาจใช้ Transaction Tables

หาก Missingอาจ:

Bankโหลดได้บางส่วน
Historyพัง

114. Business Resourceอาจใช้หลาย Tables

เช่น:

businesses
employees
transactions

Importไม่ครบอาจ Errorทีละ Table

115. Job Resourceก็อาจ Add Columnให้ Framework Table

ต้อง Import Migration

116. Whitelist Resourceอาจต้อง Tablesเฉพาะ

อย่าคิดว่า Frameworkสร้างให้ทั้งหมด

117. Ban Resourceอาจใช้ Tableของตัวเอง

ถ้า Tableหาย Serverอาจเปิดได้แต่ Ban Systemไม่ทำงาน

118. Logs Resourceอาจ Error Missing Table

บางครั้ง Gameplayยังทำงาน แต่ Logsไม่ถูก Save

ยังควรแก้

119. Missing Table Severityขึ้นกับ Resource

ถ้าเป็น:

Core Character Table

Serverอาจเข้าไม่ได้ทั้งหมด

ถ้าเป็น:

Optional Statistics

อาจเสียเฉพาะ Featureนั้น

120. Console Errorซ้ำทุกวินาทีอันตรายไหม

อาจสร้าง:

Log Spam
Performance Overhead

และปิดบัง Errorอื่น

121. Disable Resourceชั่วคราวเมื่อจำเป็น

ถ้า Optional Resourceยิง Errorต่อเนื่องและยังแก้ไม่ได้

แต่ต้องรู้ Dependenciesก่อน

122. อย่า Disable Core Database Resource

เพียงเพราะ Resourceอื่น Queryผิด

123. Core vs Optional Resource

ต้องแยกให้ได้

124. Table Doesn't Existตอน Server Start

มักเกิดจาก Resourceทำ:

Startup Query
Data Load

ทันที

125. Table Doesn't Existตอน Player Join

Resourceอาจ Query Dataเฉพาะ Playerเมื่อ Connect

126. Unknown Columnตอน Save

อาจเกิดเฉพาะตอน:

Disconnect
Transaction

จึงไม่เห็นตอน Startup

127. Testต้องทำ Actionเดิม

ถ้า Errorเกิดตอนซื้อรถ:

ทดสอบซื้อรถหลังแก้

ไม่ใช่เพียง Restart Serverแล้วสรุปว่าหาย

128. ตรวจ Consoleหลัง Test

ต้องไม่มี:

New SQL Errors

ที่เกิดจาก Fix

129. ตรวจ Dataจริงด้วย

เช่นซื้อรถแล้วดูว่า:

Ownership Recordถูกสร้าง

ไม่ใช่เพียงไม่มี Error

130. Backupก่อน ALTER TABLE

จำเป็น

131. Backupก่อน Import Migration

จำเป็นเช่นกัน

132. Backupควรเก็บก่อน Version Update

เพื่อ Rollbackได้ถ้า Migrationมีปัญหา

133. Productionควรมี Stagingไหม

ถ้า Serverใหญ่/สำคัญ:

มีประโยชน์มาก

ทดลอง Resourceและ Migrationก่อน Live

134. Staging Database คืออะไร

สำเนาหรือ Environmentทดสอบที่ไม่ใช่ Productionจริง

135. อย่าใช้ Player Database Productionเป็นสนามทดลอง

โดยเฉพาะ Query:

UPDATE
DELETE
ALTER

ขนาดใหญ่

136. phpMyAdminแก้ Schemaได้ไหม

ได้

แต่ UIง่ายไม่ได้แปลว่าการเปลี่ยน Schemaไม่มีความเสี่ยง

137. HeidiSQLก็เหมือนกัน

Toolเป็นเพียง Interface

ความถูกต้องของ SQLยังสำคัญ

138. Database BackupจากPanelเพียงพอไหม

ถ้า Restoreได้และครอบคลุม Dataที่ต้องการ:

อาจเพียงพอ

แต่ Serverใหญ่ควรมี Backup Strategyชัดเจน

139. Backupหลังแก้ไม่แทน Backupก่อนแก้

เพราะต้องมีจุดย้อนกลับ

140. Error 1146 คืออะไร

MySQL/MariaDBมักใช้ Error Codeเกี่ยวกับ Tableที่ไม่มีในกรณี Table doesn't exist

แต่ในการแก้ FiveM ให้ข้อความ Table/Resourceสำคัญกว่าจำเลข Error

141. Error 1054 คืออะไร

มักพบกับ:

Unknown column

แต่เช่นเดียวกัน ให้โฟกัส:

Column
Query
Schema

142. ER_NO_SUCH_TABLE คืออะไร

ชื่อ Errorที่ Database Driverบางตัวแสดงเมื่อ Tableไม่พบ

143. ER_BAD_FIELD_ERROR คืออะไร

มักสัมพันธ์กับ Unknown Column/Fieldใน Query

144. Error Nameช่วย Search Sourceได้

แต่ไม่ควรแก้จาก Codeอย่างเดียวโดยไม่ดู Schema

145. Missing Indexทำ Unknown Columnไหม

ไม่

Index Missingเป็น Performance/Constraint Issueอีกแบบ

146. Missing Primary Keyทำ Table Missingไหม

ไม่

Tableยังมีอยู่

แต่ Resourceบางตัวอาจทำงานผิดถ้าคาด Key

147. Indexสำคัญกับ FiveMไหม

มากสำหรับ Tableใหญ่ เช่น:

Players
Transactions

แต่ไม่ใช่ Topicหลักของ Missing Table

148. Primary Key คืออะไร

Column/ชุด Columnsที่ระบุ Rowแบบ Unique

149. Unique Key คืออะไร

Constraintป้องกันค่าซ้ำตาม Definition

150. Foreign Key คืออะไร

Constraintเชื่อม Recordsระหว่าง Tables

FiveM Resourcesบางตัวใช้ บางตัวไม่ใช้

151. Import SQLแล้ว Foreign Key Error

เป็น Migration Issueอีกประเภท

ต้องตรวจ Table Order/Data

152. อย่าปิด Foreign Key Checksถาวร

เพื่อทำให้ Importผ่านโดยไม่รู้เหตุผล

153. Temporary Migration Settingsต้องใช้ด้วยความเข้าใจ

ไม่ควรเป็น Fixประจำ

154. Table Engineต่างกันมีผลไหม

เช่น InnoDB

อาจมีผลกับ Transactions/Constraints

แต่ Missing Tableยังต้องแก้ Schemaก่อน

155. Character Set/Collationไม่ทำให้ Tableหาย

เป็นคนละปัญหา

156. Collation Errorเกิดได้หลัง Migration

แต่ไม่ควรแก้พร้อม Unknown Columnถ้าไม่เกี่ยว

157. แก้ทีละ Error

ดีที่สุด

158. ถ้ามี Errorหลายสิบตัว

หา Errorแรกสุดหลัง Resource Start

เพราะ Errorต่อ ๆ มาอาจเป็นผลจากต้นเหตุเดียว

159. Example

Tableหลัก:

players

Missing

Resourcesต่อมาทั้งหมด Query Player Dataไม่ได้

จึงเกิด Errorเป็นชุด

160. Fix Root Tableก่อน

แล้ว Restart/Testใหม่

161. Console Error Orderมีความหมาย

อ่านจาก:

First Failure

ก่อน Last Failure

162. Resource Dependency Error

ถ้า Resource Aสร้าง Tableตอน Start แต่ Resource B Startก่อน

Bอาจ Queryก่อน Tableพร้อม

163. Auto Table Creationมีไหม

บาง Resourcesสร้าง Tableด้วย Code

ถ้า Resourceสร้าง Tableไม่สำเร็จอาจมี Errorก่อนหน้า

164. Permission CREATE TABLE

ถ้า Resourceต้อง Auto-createแต่ Database Userไม่มี Permission:

Tableอาจไม่ถูกสร้าง

165. Application Userจำเป็นต้อง CREATE TABLEเสมอไหม

ไม่

ถ้าใช้ Manual Migration:

ไม่จำเป็น

และ Productionบางระบบตั้งใจไม่ให้ Applicationแก้ Schema

166. Migration UserกับApplication Userแยกได้

เป็นแนวทางที่ดีใน Infrastructureที่เข้มขึ้น

167. Serverเล็กไม่จำเป็นต้องซับซ้อนมาก

แต่ควรเข้าใจว่า Permissionแต่ละชนิดทำอะไร

168. Import SQLด้วย rootแต่ FiveM Userใช้ Tableไม่ได้

อาจเป็น Permission Issue

ไม่ใช่ Table Missing

ข้อความ Errorจะช่วยแยก

169. `SELECT command denied`

แปลว่า Tableอาจมี แต่ Userไม่มีสิทธิ์อ่าน

170. Table Doesn't ExistกับPermission Errorไม่เหมือนกัน

อย่าแก้ Grantsเมื่อ Tableไม่มีจริง

171. View คืออะไร

Databaseอาจมี:

View

ที่ Resource Queryเหมือน Table

ถ้า Viewหายก็ Errorได้

172. Stored Procedureเกี่ยวไหม

บาง Advanced Systemsอาจใช้

แต่ FiveM Resourcesทั่วไปจำนวนมากใช้ Queriesตรง

173. Database Triggerคืออะไร

Logicที่ Databaseทำอัตโนมัติเมื่อ Insert/Update

ไม่ใช่สาเหตุหลักของ Unknown Columnโดยทั่วไป

174. Migrationอาจ Add Trigger

จึงควร Importตาม Developer Instructions

175. SQL Dumpจาก Serverเก่าอาจไม่รวม Views/Triggers

ถ้า Export Settingsไม่ครบ

อาจทำ Featureบางส่วนพังหลัง Restore

176. Restoreควรตรวจ Objectครบ

โดยเฉพาะ Serverที่ใช้ Database Featuresพิเศษ

177. แต่เริ่ม Troubleshootจาก Errorที่เห็น

ไม่ต้องตรวจทุก Database Featureโดยไม่มีเหตุผล

178. Table Prefixจาก Hostingไม่ได้เปลี่ยน Table Names

อย่าสับสนกับ Database/User Prefix

Hostingอาจ Prefixชื่อ Database แต่ Tablesข้างในยังชื่อเดิม

179. Example

Database:

account_fivem

Table:

players

ไม่จำเป็นต้องเป็น:

account_players

180. Unknown DatabaseกับUnknown Tableจึงต้องอ่านเต็ม

ตัวอย่าง:

account_fivem.players

จะบอกทั้ง Databaseและ Table

181. วิธีป้องกัน Schema Problems

เก็บ:

Resource Versions
SQL Migrations
Backups

อย่างเป็นระบบ

182. Update Checklist

ก่อน Update Resource:

อ่าน Changelog
ดู Database Changes
Backup
Update Code
Run Migration
Test

183. อย่า Auto-update Resource Productionโดยไม่อ่าน

โดยเฉพาะ Scriptsที่แก้ Database Schema

184. Dependency Updateก็ทำ Schemaพังได้ไหม

อาจทำให้ Resource Compatibilityเปลี่ยน

แต่ต้องดู Changelogจริง

185. Framework Updateควรทดสอบ Resourcesสำคัญ

เช่น:

Phone
Inventory
Garage
Housing
Banking

186. Database Migration Documentationควรเก็บไว้

อย่าลบ SQL Folderหลัง Importจนไม่รู้ History

187. Custom Schema Changesควรจด

ถ้าคุณปรับเอง เช่น:

เพิ่ม column custom_rank

ควร Document

188. มิฉะนั้น Updateครั้งหน้าอาจชน

Developer Migrationไม่รู้ Custom Changesของคุณ

189. Git Diff SQLช่วยได้

เห็นว่า Schema Fileเปลี่ยนอะไรระหว่าง Versions

190. Database Schema Comparison Toolมีประโยชน์

สำหรับ Serverใหญ่ แต่ไม่จำเป็นสำหรับมือใหม่

191. มือใหม่ใช้ SHOW CREATE TABLE ก็พอเริ่มได้

เปรียบเทียบกับ SQLต้นฉบับอย่างระวัง

192. อย่า Copy CREATE TABLEแล้ว Runถ้า Tableมีข้อมูล

อาจเกิด Conflict

193. ต้องเปลี่ยนเฉพาะ Difference

มักใช้ Migration/ALTERที่ Developerให้

194. Manual ALTERควรเป็นทางเลือกท้าย ๆ

เมื่อไม่มี Official Migrationและเข้าใจ Resourceดีพอ

195. Example ErrorหลังPhone Update

Unknown column 'avatar' in 'phone_contacts'

ให้ตรวจ Phone Resource Migration

ไม่ต้องแก้ Framework User Tableถ้าไม่เกี่ยว

196. Example ErrorหลังGarage Update

Unknown column 'garage' in 'owned_vehicles'

ตรวจ Garage/Framework Migrationและ Version

197. Example ErrorหลังHousing Install

Table 'fivem.properties' doesn't exist

ตรวจ Housing SQL Installation

198. Example ErrorหลังBusiness Install

Table 'fivem.business_transactions' doesn't exist

ตรวจว่า Import Business SQLครบหรือไม่

199. Example ErrorหลังInventory Update

Unknown column 'inventory' in 'players'

อย่าเพิ่ม Columnทันที

ตรวจว่า Inventory Versionใหม่ยังใช้ Modelแบบนั้นหรือไม่

200. Resourceบางตัวไม่ใช้ Database Tableเดิมแล้ว

Updateอาจย้ายข้อมูลไป Tableใหม่

ต้อง Run Migrationจริง ไม่ใช่สร้าง Fieldเก่ากลับมา

201. Migration Directionสำคัญ

Versionเก่า → ใหม่

ไม่ใช่เอา SQLใหม่ไปสุ่ม Importแล้วค่อย SQLเก่าตาม

202. Downgrade Resourceก็มี Schema Risk

ถ้า Databaseถูก Migrationไป Versionใหม่แล้ว

Codeเก่าอาจไม่เข้าใจ Schemaใหม่

203. Backupก่อน Upgradeช่วย Rollback

ทั้ง:

Code
Database

ควรมี Versionคู่กัน

204. Database Rollbackไม่ใช่แค่เปลี่ยนไฟล์ Resource

ต้อง Restore Schema/Dataให้ตรง Code

205. Migrationที่เพิ่ม Columnอย่างเดียวอาจ Rollbackง่ายกว่า

แต่ Migrationที่ Transform Dataอาจซับซ้อน

206. อย่าทำ Production Updateก่อนเวลาคนเล่นเยอะ

Maintenance Windowช่วยลดผลกระทบ

207. Server Restartหลัง Migrationจำเป็นไหม

ขึ้นอยู่กับ Resource

แต่ Resourcesอาจต้อง Reloadเพื่อใช้ Code/Schemaใหม่

208. Migrationแล้วไม่ Restart Resource

Codeเก่าอาจยัง Running

จึงควรวางขั้นตอน Updateให้ครบ

209. Database CacheในResourceมีไหม

บาง Resources Cache Data/Prepared Queries

Restart Resourceอาจจำเป็นหลัง Schema Change

210. Prepared Statementอ้าง Columnเก่า

ถ้า Codeใหม่ไม่ Reload Queryเก่าอาจยังถูกใช้ในบาง Architecture

211. Restartทั้ง Serverปลอดภัยกว่าเสมอไหม

ไม่จำเป็น

แต่ Maintenance Updateใหญ่บางครั้งเลือก Full Restartเพื่อให้ Stateสะอาด

212. ต้องประกาศก่อน Maintenance

ถ้ามี Players Online

ป้องกัน:

Transactionsค้าง
RPขาด

213. Database Changesระหว่าง Active Transactionsเสี่ยง

โดยเฉพาะ Tablesที่ Playersกำลังเขียน

214. Maintenance Modeช่วยได้

หยุด Gameplayขณะ Migration

215. Unknown Column Errorอาจทำให้ข้อมูลหายไหม

ตัว Queryที่ Errorอาจไม่สำเร็จ

ถ้าเป็น Save Query:

Dataล่าสุดอาจไม่ถูก Save

จึงควรแก้เร็ว

216. Missing Table Errorอาจทำ Characterสร้างไม่สำเร็จ

ถ้า Tableนั้นเป็นส่วนหนึ่งของ Character Creation

217. อย่าให้ Playersเล่นต่อหาก Core Saveพัง

เสี่ยง:

Money
Items
Progression

ไม่ Save

218. Optional Log Tableพังต่างจากPlayer Tableพัง

Severityต่างกัน

219. ดู Functionของ Table

ก่อนตัดสินใจว่าจะ Shut Down Serverหรือไม่

220. Server Ownerควรรู้ Core Tablesคร่าว ๆ

ไม่จำเป็นต้องเป็น DBA

แต่ควรรู้ว่า Tablesใดเก็บ:

Characters
Economy
Vehicles

221. Database Administrator หรือ DBA คืออะไร

ผู้ดูแล Databaseเชิงระบบ

FiveM Serverเล็กอาจไม่มีตำแหน่งแยก

222. Schemaคืออะไรแบบง่าย

โครงสร้าง Database:

Tables
Columns
Types
Keys

223. Dataคืออะไร

ค่าที่อยู่ภายใน Schema

เช่น:

Character A
เงิน 50,000

224. Schema ErrorกับData Errorต่างกัน

Schema Error:

Columnไม่มี

Data Error:

Columnมีแต่ค่าผิด

225. บทความ 271 เป็นตัวอย่าง Data/Type Error

Incorrect datetime value

226. บทความ 272 เป็น Connection Error

ยังเชื่อม Databaseไม่ได้

227. บทความนี้เป็น Schema Error

Connectionสำเร็จ แต่โครงสร้างไม่ตรง Resource

228. สาม Layerนี้ควรแยกให้ชัด

Connection → Schema → Data

229. ถ้าเข้าใจ Layer Troubleshootingจะง่ายขึ้นมาก

เพราะข้อความ Errorบอกจุดได้ค่อนข้างชัด

230. Error Matrix

Error	Layer
ECONNREFUSED	Connection
Access Denied	Authentication
Unknown Database	Database Selection
Table Doesn't Exist	Schema
Unknown Column	Schema
Incorrect Datetime	Data/Type
Duplicate Entry	Constraint/Data

231. Table Doesn't Exist Quick Fix

อย่า “สร้าง Tableเอง”

ให้:

หา Resource
หา Official SQL
Backup
Import/Migrateถูก Version

232. Unknown Column Quick Fix

หา Columnใน Error
ดู Tableจริง
ตรวจ Resource Version
หา Migrationที่เพิ่ม/เปลี่ยน Column

233. ถ้าไม่มี Migration File

ตรวจ Documentation/Release Notes

ก่อน Manual ALTER

234. ถ้า Resourceปิด Source

Developerอาจให้ SQL Updateแยกใน Customer Portal/Package

ใช้ Sourceทางการ

235. Pirated/Leaked Resourceเสี่ยง Database Schemaมาก

เพราะไฟล์อาจ:

ไม่ครบ
คนละ Version
ถูกแก้

นอกจากปัญหาด้านสิทธิ์แล้ว ยัง Debugยากมาก

236. ใช้ Resourceจากแหล่งที่เชื่อถือได้

ช่วยให้มี:

Documentation
Updates
Migration

ครบกว่า

237. Resource Escrowไม่ได้หมายความว่าไม่มี SQL

ส่วน Database Files/Configที่จำเป็นควรถูกจัดให้ตาม Resource Design

238. Missing SQLจาก Package

ควรติดต่อ Developer/Official Support

ไม่ควรเดา Schemaจาก Errorทีละ Column

239. เดา Schemaทีละ Errorมีปัญหาอะไร

วันนี้เพิ่ม:

column A

พรุ่งนี้ Error:

column B

สุดท้าย Tableอาจดูเหมือนครบแต่ Types/Indexesผิดทั้งหมด

240. Official CREATE TABLE สำคัญกว่า Guess

เพราะมี:

Types
Defaults
Indexes

ครบ

241. Indexหายแม้ Queryทำงาน

อาจ Performanceแย่มาก

นี่คือเหตุผลที่สร้าง Tableเปล่าเองไม่เหมาะ

242. Unique Constraintหายอาจเกิด Duplicate Data

แม้ไม่มี Errorทันที

243. Defaultผิดอาจสร้าง Data Bug

จึงต้อง Migrationถูกต้องทั้ง Schema

244. Nullabilityสำคัญ

Column:

NULL

กับ:

NOT NULL

มี Logicต่างกัน

245. Data Typeสำคัญ

เช่น:

INT
VARCHAR
JSON
DATETIME

ใช้แทนกันแบบสุ่มไม่ได้

246. VARCHAR Lengthสำคัญไหม

ได้

ข้อมูลยาวเกินอาจเกิด Error/Truncation

247. JSON Columnต้องมี JSONถูกต้อง

ถ้า Resourceคาด JSON

อย่าเปลี่ยนเป็น Textโดยไม่เข้าใจ

248. Primary Key Missingอาจทำ Updateผิด Row

ใน Resourceที่อาศัย Keyนั้น

249. Auto Increment คืออะไร

Column IDเพิ่มอัตโนมัติ

ถ้า Schemaต้นฉบับต้องมีแต่สร้างเองไม่มี:

Insertsอาจพัง

250. Character Tableสร้างเองจากชื่อ Columnอย่างเดียวจึงเสี่ยงมาก

ควรใช้ Framework Schemaจริง

251. วิธีตรวจว่า Migrationเคย Runหรือยัง

ดู:

Column
Migration Tableถ้ามี
Release State

ตาม Resource

252. Migration Tableคืออะไร

บางระบบเก็บ Versionของ Migrationที่เคย Run

แต่ไม่ใช่ทุก FiveM Resource

253. ไม่มี Migration Trackingทำอย่างไร

จด Manual Changeเอง

และ Backup SQL Schema

254. Schema Dumpคืออะไร

Exportเฉพาะโครงสร้าง Databaseโดยไม่เอา Data

มีประโยชน์เปรียบเทียบ

255. Production Schema Dumpควรเก็บเป็น Versionได้

สำหรับ Serverที่ Customเยอะ

256. Database Documentationลดปัญหาอนาคต

จดว่า:

Resourceไหนเพิ่ม Tableอะไร
Versionไหน

257. Tableชื่อคล้ายกันอย่าสับสน

เช่น:

owned_vehicle
owned_vehicles
player_vehicles

อาจเป็นคนละ Framework

258. อย่า Renameให้ตรง Errorโดยทันที

Resourceอื่นอาจใช้ Tableเดิม

259. Compatibility Viewใช้ได้ไหม

Advanced Adminอาจใช้ Database Viewเพื่อ Compatibilityบางกรณี

แต่ไม่ควรใช้เป็น Fixทั่วไปสำหรับมือใหม่

260. Better Fixคือใช้ Resource Adapterที่ถูก

เมื่อมี

261. Table Aliasใน SQLช่วยได้ไหม

Aliasเปลี่ยนชื่อใน Queryชั่วคราว

ไม่ได้ทำให้ Missing Tableเกิดขึ้นจริง

262. SQL Search Pathไม่มีแบบที่ควรเดา

FiveM Queryมักอ้าง Database Connectionที่เลือกไว้

263. Tableอยู่ Databaseอื่น

สามารถ Queryแบบ:

database.table

ได้ในบาง Design

แต่ Application Userต้องมี Permission

264. FiveM Resourceทั่วไปควรเชื่อม Databaseเดียวให้ชัด

ลด Complexity

265. Multi-Database Setupมีไหม

มีได้

แต่ Troubleshootingซับซ้อนขึ้น

266. Serverขนาดเล็กไม่ควรแยก Databaseโดยไม่มีเหตุผล

เพราะ Config/Permissionsเพิ่ม

267. Error Unknown Columnหลังเพิ่ม Custom Script

อาจ Scriptนั้นเขียนมาสำหรับ Schemaอื่น

ตรวจ Compatibilityก่อนเปลี่ยน Core Table

268. Developerควรหลีกเลี่ยง Hardcoded Framework Schemaถ้ารองรับหลาย Framework

ใช้ Adapter Layerจะดูแลง่ายกว่า

269. Server Ownerควรเลือก Scriptsที่รองรับ Frameworkตรง Version

ลดจำนวน Custom Patches

270. Custom Patchทุกตัวคือ Maintenance Cost

Update Frameworkครั้งหน้าอาจต้องแก้ใหม่

271. Database Schema Debt คืออะไร

การสะสม:

Custom Columns
Manual Fixes
Unknown Migrations

จนไม่มีใครรู้ว่า Productionต่างจากต้นฉบับอย่างไร

272. Schema Debtทำให้ Updateยากมาก

เพราะไม่รู้ว่าการ ALTERหนึ่งครั้งจะกระทบอะไร

273. ลด Schema Debtอย่างไร

ใช้ Migrations
Document Changes
Backup
Version Control

274. อย่าแก้ Schemaผ่าน phpMyAdminแล้วไม่จด

อีกหลายเดือนจะจำไม่ได้ว่า Columnนั้นมาจาก Resourceไหน

275. Comment Columnช่วยได้ไหม

Databaseบางระบบรองรับ Comments

แต่ Documentationภายนอกยังสำคัญกว่า

276. Naming Conventionช่วยอะไร

Custom Tablesควรมีชื่อชัดเจนเพื่อไม่ชน Resourceอื่น

277. Resource Table Prefixช่วยลดCollision

เช่น:

myphone_contacts

แทนชื่อทั่วไปมาก ๆ

แต่ขึ้นกับ Developer

278. Table Collision คืออะไร

สอง Resourcesใช้ Tableชื่อเดียวกันแต่ Schemaไม่เหมือนกัน

อาจทำให้ Updateตัวหนึ่งทำอีกตัวพัง

279. พบ Table Collisionทำอย่างไร

ต้องดู Resourcesทั้งสอง

ไม่ควร Import SQLของอีกตัวทับ

280. Phone Scriptsหลายตัวเป็นตัวอย่างที่ต้องระวัง

ถ้าเปลี่ยน Phone Resource:

Old Tables
New Tables

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

281. ลบ Old Tablesได้ไหม

หลัง Migrationและ Backupอาจทำได้ถ้าแน่ใจว่าไม่มี Resourceใช้แล้ว

แต่ไม่ควรรีบ

282. Old Tableไม่ทำให้ Serverพังเพียงเพราะยังอยู่

ส่วนใหญ่ Tableที่ไม่ได้ Queryเพียงกิน Storage

283. จึงไม่ต้อง Clean Databaseระหว่าง Troubleshootingทันที

เน้นให้ระบบทำงานถูกก่อน

284. Orphan Table คืออะไร

Tableเก่าที่ไม่มี Resourceใช้แล้ว

285. Orphan Column คืออะไร

Columnเก่าที่ไม่มี Codeใช้

286. ลบ Orphan Schemaต้องตรวจ Usageก่อน

Search Sourceทั้ง Server

287. SQL Query Logช่วยหา Usageได้ไหม

Advanced Database Adminสามารถดู Query Activityได้

แต่ไม่จำเป็นสำหรับ Caseง่าย

288. Search Source Codeมักง่ายกว่า

ถ้ามี Sourceครบ

289. Escrow Resourceทำให้ Search Queryยาก

ใช้:

Documentation
Developer Support
SQL Package

แทน

290. Errorแสดง Queryเต็มมีประโยชน์มาก

อ่านว่า:

SELECT ...
FROM ...
WHERE ...

จะเห็น Table/Columnที่ Resourceคาด

291. แต่ระวัง Query Logมีข้อมูล Player

ก่อนโพสต์ Publicควร Maskข้อมูลที่ไม่จำเป็น

292. SQL Injectionไม่เกี่ยวกับ Missing Tableโดยตรง

เป็น Security Topicอีกเรื่อง

แต่ Parameterized Queriesยังสำคัญ

293. อย่าแก้ Errorด้วยการต่อ SQL Stringมั่ว

เพียงเพื่อเปลี่ยน Columnแบบ Dynamic

294. Server Ownerไม่จำเป็นต้องรู้ SQLทั้งหมด

แต่ควรรู้คำพื้นฐาน:

SELECT
INSERT
UPDATE
ALTER
CREATE

295. SELECT

อ่านข้อมูล

296. INSERT

สร้าง Rowใหม่

297. UPDATE

แก้ Rowที่มีอยู่

298. DELETE

ลบ Row

299. CREATE TABLE

สร้าง Table

300. ALTER TABLE

แก้โครงสร้าง Table

301. DROP TABLE

ลบ Tableทั้งหมด

302. คำสั่งไหนเสี่ยงที่สุดสำหรับมือใหม่

โดยเฉพาะ:

DELETE
DROP
ALTER

ถ้าไม่เข้าใจ Scope

303. SELECTก่อน UPDATE

เป็นแนวปฏิบัติที่ดี

ดู Rowsก่อนเปลี่ยนข้อมูล

304. SHOW CREATE TABLEเป็น Read-only Inspection

เหมาะมากสำหรับ Troubleshooting Schema

305. DESCRIBEก็เช่นกัน

ช่วยดู Columnโดยไม่แก้ Data

306. วิธี Troubleshootแบบปลอดภัยเริ่มจาก Read-only

ก่อนทำ Migration/ALTER

307. Step 1 — อ่าน Errorเต็ม

ตัวอย่าง:

Unknown column 'garage_id' in 'field list'

308. Step 2 — หา Resource

ดู Stack/Console Prefix

309. Step 3 — หา Table

ดู Queryว่า Columnอยู่ใน Tableไหน

310. Step 4 — Inspect Schema

DESCRIBE your_table;

311. Step 5 — ตรวจ Resource Version

ดู Version/Changelog

312. Step 6 — หา Migration

มองหา SQL Updateที่เพิ่ม garage_id

313. Step 7 — Backup

ก่อนแก้ Production

314. Step 8 — Run Official Migration

ตาม Developer Instructions

315. Step 9 — Restart/Reload Resource

ตามความเหมาะสม

316. Step 10 — Test Featureเดิม

ดูทั้ง Consoleและ Data

317. ถ้าไม่มี Tableเลย

Flowคือ:

Resource
→ Installation SQL
→ Database Selection
→ Import

318. ถ้ามี Tableแต่ Columnหาย

Flowคือ:

Resource Version
→ Migration
→ Schema Comparison

319. ถ้ามี Columnแต่ชื่อไม่ตรง

ตรวจ:

Resourceสำหรับ Frameworkผิดหรือไม่

ก่อน Rename

320. ถ้ามีทุกอย่างแต่ Errorยังบอกไม่มี

ตรวจว่า Connectionไป Databaseตัวเดียวกับที่คุณกำลัง Inspectหรือไม่

321. Database Connectionอาจใช้ Cache Configเก่า

Resource/Serverอาจยังไม่ได้ Restartหลังเปลี่ยน Connection String

322. Restartอย่างมีแผน

อย่า Restart Productionซ้ำโดยไม่ดู Config

323. Table Missingหลัง Server Restartแต่ก่อนหน้านี้ใช้ได้

อาจ FiveMกลับไป Connection Configคนละ Environmentหลัง Restart

เช่น Environment Variableไม่ได้ถูกโหลด

324. Config Sourceหลายชั้นต้องระวัง

server.cfg
Environment
Panel Variables

ค่าใด Overrideค่าใดต้องรู้

325. Databaseชื่อผิดหลัง Restart

เป็นสัญญาณดีให้ตรวจ Config Loading

326. Unknown Columnเกิดเฉพาะ Test Server

Productionอาจมี Migrationที่ Testยังไม่ได้ Run

327. Schemaควร Syncทุก Environment

Development
→ Staging
→ Production

ควรใช้ Migrationชุดเดียวกัน

328. Manual Production Changeทำให้ Devตามไม่ทัน

นี่คือเหตุผลที่ควรเก็บ Migration Files

329. ตัวอย่าง Migrationที่ดี

หนึ่ง Fileต่อ Version เช่น:

001_initial.sql
002_add_last_login.sql
003_add_vehicle_state.sql

330. ทำไม Numberingช่วย

รู้ลำดับที่ต้อง Run

331. แต่ Third-party Resourceอาจใช้รูปแบบอื่น

ยึด Documentationของ Developer

332. Migrationอัตโนมัติดีไหม

สะดวก แต่ Productionควรมี Backupเพราะ Schemaยังถูกแก้จริง

333. Auto Migration Failต้องดู Errorแรก

อย่าเพียง Restartซ้ำหวังว่าจะผ่าน

334. Database Userไม่มี ALTER Permission

Auto Migrationอาจ Fail

แล้ว Resourceเริ่มต่อด้วย Schemaเก่า

335. นี่ทำให้ Unknown Columnตามมา

จึงควรอ่าน Migration Errorก่อน Unknown Column

336. Permission MigrationกับRuntimeอาจต่างกัน

Productionบางระบบ Run Migrationด้วย Admin User

แล้ว Runtimeใช้ Limited User

เป็นแนวทางที่ดี

337. มือใหม่ไม่จำเป็นต้องทำแยกทันที

แต่ควรไม่ใช้ rootแบบถาวรโดยไม่มีเหตุผล

338. Errorหลัง Restore Backupจากก่อน Update

ถ้า Codeยังเป็น Versionใหม่แต่ Databaseถูก Restoreกลับ Versionเก่า:

Unknown Columnเกิดได้ทันที

339. Restoreทั้ง CodeและDatabaseให้เป็น Versionคู่กัน

ถ้าจะ Rollbackเต็มรูปแบบ

340. Database Backup Dateสำคัญ

ต้องรู้ว่า Backupถูกสร้างก่อนหรือหลัง Migrationใด

341. อย่าตั้งชื่อ Backupแค่ backup.sql

ใช้ชื่อที่รู้:

Date
Version

จะช่วยภายหลัง

342. ตัวอย่าง

fivem-db-before-phone-v3.sql

ช่วยรู้จุดประสงค์

343. Backupมีข้อมูลผู้เล่น

ต้องเก็บ Private

344. อย่า Upload Dumpขึ้น Public Discord

อาจมี:

Identifiers
Personal Data
Credentialsบางระบบ

345. Error Screenshotควร Maskข้อมูลที่ไม่จำเป็น

แต่คง:

Table
Column
Resource

ไว้ให้ Debugได้

346. Staffทั่วไปแก้ Schemaได้ไหม

ควรจำกัดให้:

Developer
Server Owner

หรือผู้ที่เข้าใจ Database

347. ให้หลายคนแก้ Databaseพร้อมกันเสี่ยง

เพราะอาจ Run Migrationซ้ำ

348. Change Logภายในทีมช่วยได้

จดว่าใคร:

แก้อะไร
เมื่อไร

349. Database Lockเกิดจาก ALTERได้ไหม

Schema Changesบางประเภทอาจกระทบ Tableขณะทำงาน

จึงควร Maintenance

350. Tableใหญ่ Migrationอาจใช้เวลามากขึ้น

โดยเฉพาะ Transactions/Logsจำนวนมาก

351. อย่า Run ALTERหนักช่วง Peak

ลด Riskต่อ Players

352. Optimizeก่อน/หลัง Migrationจำเป็นไหม

ไม่เสมอไป

อย่าทำ Operationsเพิ่มโดยไม่มีเหตุผล

353. Schema Fixที่ดีต้อง Minimum Necessary Change

เปลี่ยนเฉพาะสิ่งที่ Resource Versionต้องการ

354. ไม่ควร “ปรับให้เหมือน Tutorialทั้งหมด”

Serverคุณอาจมี Custom Schema

355. Tutorialช่วยเข้าใจ Concept

แต่ Source of Truthควรเป็น:

Resource Version
Framework
Production Schema

356. Table Doesn't Exist FAQ

FiveM ขึ้น Table Doesn't Exist คืออะไร

Resourceกำลัง Query Tableที่ไม่มีอยู่ใน Databaseที่ FiveMเชื่อมอยู่

แก้อย่างไร

ตรวจว่า Import SQL/Migrationของ Resourceครบหรือไม่ และ FiveMเชื่อม Databaseถูกตัวหรือไม่

ต้องสร้าง Tableเองไหม

ไม่ควรเดา ควรใช้ SQL Schemaจาก Resourceหรือ Frameworkที่ถูก Version

Unknown Column คืออะไร

Tableมีอยู่ แต่ Queryเรียก Columnที่ไม่มีใน Schema

Unknown Columnเกิดหลัง Updateเพราะอะไร

Resourceใหม่อาจต้อง Migrationเพื่อเพิ่ม/เปลี่ยน Column

Import SQLซ้ำได้ไหม

ไม่ควรทำแบบสุ่ม เพราะ Install SQLบางไฟล์อาจสร้าง Tableใหม่หรือกระทบ Dataเดิม

ต้อง Backupไหม

ควร Backupก่อน Migration, ALTER หรือ Import SQLบน Production

Tableมีใน phpMyAdminแต่ FiveMบอกไม่มี

ตรวจว่า FiveMกับ phpMyAdminกำลังดู Databaseเดียวกัน

Tableชื่อเหมือนแต่ตัวพิมพ์ต่างกันมีผลไหม

อาจมีตาม Environment จึงควรใช้ชื่อให้ตรง Schemaจริง

ESX Resourceใช้กับ QBCoreแล้ว Unknown Columnทำอย่างไร

ตรวจ Resource Compatibility/Framework Configก่อนแก้ Database

เพิ่ม Columnให้ Errorหายได้ไหม

อาจทำให้ Queryไม่ Error แต่ไม่ได้รับประกัน Logicถูก ต้องรู้ Type, Default และข้อมูลที่ควรเก็บ

เปลี่ยน Columnเป็น VARCHARทั้งหมดได้ไหม

ไม่ควร เพราะ Resourceอาจต้องใช้ Date, Number, JSON หรือ Indexเฉพาะ

Unknown Columnเฉพาะ Characterหนึ่งเกิดได้ไหม

ได้ในบาง Data Logic แต่ Unknown Columnจริงมักเป็น Schema-level และมักกระทบ Queryแบบเดียวกันทุกคน

Missing Tableเกิดเฉพาะ Resourceเดียวทำอย่างไร

ตรวจ SQL Installation/Migrationของ Resourceนั้น

ต้องลบ Databaseแล้ว Importใหม่ไหม

โดยทั่วไปไม่จำเป็น และเสี่ยงข้อมูลหายมาก

Clear FiveM Cacheช่วยไหม

โดยทั่วไปไม่ เพราะปัญหาอยู่ฝั่ง Database Schema

Restart FiveMช่วยไหม

ถ้า Schemaยังผิด Errorจะกลับมา

Table Doesn't Existหลังย้าย Hostทำอย่างไร

ตรวจว่า Restore Databaseครบและ Connection Stringชี้ Databaseที่ถูกต้อง

Unknown Columnหลัง Restore Backupทำอย่างไร

Backupอาจเป็น Schema Versionเก่ากว่า Codeที่ใช้อยู่ ต้อง Migrationให้ตรง Version

Auto Migrationไม่ทำงานเพราะอะไร

อาจเกิดจาก:

Permission
Resource Error
Version

ต้องดู Consoleก่อน Errorอื่น

Database Userต้องมี ALTER Permissionไหม

เฉพาะกรณี Resourceต้อง Auto-migrate Schema ถ้า Migrationทำ Manualด้วย Admin User Runtime Userอาจไม่จำเป็นต้องมี

Error 1054 คืออะไร

มักสัมพันธ์กับ Unknown Column

Error 1146 คืออะไร

มักสัมพันธ์กับ Table Doesn't Exist

Table Missingทำข้อมูลหายไหม

การที่ Tableหายไม่ได้บอกโดยอัตโนมัติว่าข้อมูลถูกลบ เพราะอาจกำลังเชื่อม Databaseผิดตัว ต้องตรวจให้แน่ใจก่อน

Characterทั้งหมดหายหลังย้าย Serverทำอย่างไร

ตรวจ Connection Stringและ Database Nameก่อน Import/Restoreซ้ำ เพราะ FiveMอาจกำลังใช้ Databaseเปล่า

สรุป FiveM MySQL Table Doesn't Exist และ Unknown Column

FiveM Error Table Doesn't Exist และ Unknown Column เป็นปัญหาที่เกิดหลัง Database Connection สำเร็จแล้ว แต่ Schema ที่อยู่ใน Database ไม่ตรงกับ Query ของ Resource

จำลำดับนี้ไว้:

Table ไม่มี → ตรวจ Installation SQL / Database ที่เชื่อม
Table มีแต่ Column ไม่มี → ตรวจ Migration / Resource Version
ชื่อ Column ไม่ตรง Framework → ตรวจ Compatibility / Config
เพิ่ง Restore Database → ตรวจ Schema Version
เพิ่ง Update Script → อ่าน Changelog และ Migration ก่อน

สิ่งที่ comsiam แนะนำคืออย่าเห็น Unknown column แล้วสร้าง Columnตามชื่อ Errorทันที เพราะ Schemaไม่ได้มีเพียงชื่อ Field แต่ยังมี Data Type, Default, Index, Nullability และ Logicว่าค่านั้นมาจากไหน การสร้าง Columnแบบเดาอาจทำให้ Errorหายแต่ข้อมูล Character, Vehicle, Banking หรือ Businessผิดเงียบ ๆ ในภายหลัง

อีกหลักที่ comsiam แนะนำคือก่อน Import SQL, Run Migration หรือใช้ ALTER TABLE กับ Production Database ให้ Backupก่อนเสมอ จากนั้นใช้ Schemaและ Migrationที่ตรงกับ Resource Versionจริง ทดสอบ Featureที่เคย Error และตรวจข้อมูลที่บันทึกใน Databaseด้วย ไม่ใช่ดูเพียงว่า Consoleไม่มีข้อความแดงแล้วสรุปว่าระบบสมบูรณ์