FiveM MySQL Data Too Long for Column Error 1406 แก้อย่างไร? VARCHAR, TEXT, JSON และ Schema ไม่ตรง Resource

August 17, 2026

ปัญหา FiveM MySQL/MariaDB ขึ้น Data too long for column มักเกิดเมื่อ Resource พยายามบันทึกข้อมูลที่มีขนาดใหญ่กว่าที่ Column ใน Database รองรับ เช่น Character Identifier, Vehicle Plate, Phone Number, JSON, Inventory, Metadata, Business Data หรือข้อความจาก Script

ตัวอย่าง Error:

ERROR 1406 (22001): Data too long for column 'firstname' at row 1

Data too long for column 'plate' at row 1

Data too long for column 'inventory' at row 1

ER_DATA_TOO_LONG

MariaDB กำหนด Error 1406, SQLSTATE 22001 เป็น ER_DATA_TOO_LONG ซึ่งหมายถึงข้อมูลที่จะเก็บมีขนาดเกินสิ่งที่ Column รองรับ

สำหรับ FiveM ปัญหานี้ไม่ควรแก้ด้วยการเปลี่ยนทุก Column เป็น LONGTEXT หรือปิด Strict Mode ทันที เพราะบางครั้งต้นเหตุจริงคือ:

Resource Version ไม่ตรง Database
Column ถูกสร้างผิด
Import SQL เก่า
JSON โตผิดปกติ
Script ส่งข้อมูลผิด Field
Identifier Format เปลี่ยน
Character Data เสีย
Resource เก็บข้อมูลมากกว่าที่ออกแบบไว้

หลักการแก้คือ:

อ่านข้อความ Error → หา Column → ดูค่าจริง → ตรวจ Data Type → ตรวจ Schema จาก Resource → แก้ขนาดหรือแก้ข้อมูลต้นเหตุ → Test

① Error 1406 คืออะไร

MariaDB จะแจ้ง Error 1406 เมื่อค่าที่กำลังบันทึกมีขนาดใหญ่กว่าที่ Column สามารถรับได้

② ตัวอย่างง่ายที่สุด

สมมติ Database มี:

name VARCHAR(10)

แต่ Script ส่ง:

Christopher

ซึ่งยาวเกินขนาดที่กำหนด

Database อาจ Reject Query

③ VARCHAR คืออะไร

VARCHAR คือ String Type สำหรับเก็บข้อความที่มีความยาวแปรผัน โดยกำหนดขนาดสูงสุดของ Column ไว้ใน Schema

④ ตัวอย่าง

firstname VARCHAR(50)

หมายถึง Column ถูกออกแบบให้เก็บ String ภายในขนาดที่กำหนด

⑤ ถ้าข้อมูลยาวเกิน VARCHAR จะเกิดอะไร

MariaDB ระบุว่า เมื่อ String ยาวเกิน Column VARCHAR พฤติกรรมจะสัมพันธ์กับ SQL Mode โดยใน Strict Mode สามารถเกิด Error แทนการตัดข้อมูล

⑥ Strict Mode คืออะไร

MariaDB ถือว่าเมื่อเปิด:

STRICT_TRANS_TABLES
หรือ STRICT_ALL_TABLES

จะอยู่ใน Strict Mode และ Statement ที่พยายามบันทึกข้อมูลไม่ถูกต้องบางชนิดสามารถถูก Reject แทนปล่อยผ่าน

⑦ Strict Mode เป็นสาเหตุหรือไม่

Strict Mode อาจเป็นสิ่งที่ทำให้ Error แสดงออกมาอย่างชัดเจน

แต่ต้นเหตุจริงยังอาจเป็น:

ข้อมูลยาวเกิน Column

⑧ ควรปิด Strict Mode ไหม

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

เพราะหาก Database ยอมตัดข้อมูลเงียบ ๆ อาจทำให้ข้อมูล FiveM เสียโดยที่คุณไม่รู้ตัว

⑨ ตัวอย่าง Plate

Schema:

plate VARCHAR(8)

แต่ Resource ส่ง:

ABC123456789

ค่ามีขนาดเกินสิ่งที่ Schema ออกแบบไว้

⑩ วิธีแก้ไม่ได้มีแค่เพิ่ม VARCHAR

ต้องถามก่อนว่า:

Plate ควรยาวขนาดนี้จริงหรือไม่?

ถ้า Resource ควรสร้าง Plate เพียง 8 ตัว แต่ Generator Bug สร้าง 12 ตัว:

ควรแก้ Generator

ไม่ใช่เพิ่ม Column อย่างเดียว

⑪ Error ที่ firstname

ตัวอย่าง:

Data too long for column 'firstname'

อาจเกิดจาก Character Name ยาวกว่า Schema รองรับ

⑫ ควรเพิ่ม firstname เป็น VARCHAR(255) เลยไหม

ไม่ควรรีบ

ตรวจ Resource SQL ก่อนว่า Developer กำหนดความยาวจริงเท่าไร

⑬ Error lastname ก็เหมือนกัน

ตรวจ:

Character Creator
Maximum Name Length
Database Schema

ให้ตรงกัน

⑭ Frontend Limit กับ Database Limit ควรตรงกัน

ถ้า Character UI อนุญาต 100 ตัวอักษร

แต่ Database รองรับ 50:

ผู้เล่นสามารถสร้าง Input ที่ Database บันทึกไม่ได้

⑮ Validation ควรเกิดก่อน Query

Application ควรตรวจว่า Input:

ยาวเกินหรือไม่

ก่อนส่ง MariaDB

⑯ Database Constraint ยังควรอยู่

เพราะเป็น Protection ชั้นสุดท้าย

⑰ Error plate หลังเปลี่ยน Vehicle Script

น่าสงสัยว่า:

Plate Format ใหม่
Schema เก่า

ไม่ตรงกัน

⑱ Error phone_number

Resource ใหม่อาจสร้างเบอร์แบบ:

555-123-4567

แต่ Schema เดิมออกแบบสำหรับเลขสั้นกว่า

⑲ อย่าแก้โดยตัดเบอร์ท้ายทิ้ง

เพราะอาจทำให้:

Phone Numbers ซ้ำ
Calls ผิดคน

⑳ ต้องแก้ Schema หรือ Generator ให้ตรงกัน

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

㉑ Error identifier

FiveM/Framework Resource อาจใช้ Identifier ที่มีความยาวมากกว่า Schema รุ่นเก่า

㉒ ตัวอย่าง

Database เก่า:

identifier VARCHAR(40)

แต่ Resource ปัจจุบันส่ง Identifier ที่ยาวกว่า

อาจเกิด Error 1406

㉓ ต้องตรวจ Framework Migration

ก่อนเปลี่ยน Column เอง

㉔ Error citizenid

citizenid มักเป็น Internal Character Identifier ใน Framework บางประเภท

ถ้ายาวเกิน:

ตรวจ Generator
ตรวจ Schema

㉕ Error license

อย่าตัด License Identifier เพื่อให้พอดี Column

เพราะ Identifier อาจใช้ระบุ Account

㉖ ตัด Identifier มีความเสี่ยงสูง

สองค่าที่เดิมไม่เหมือนกันอาจกลายเป็นเหมือนกันหลังถูกตัด

㉗ ทำให้ Account Mapping ผิดได้

ดังนั้นควรเก็บค่าครบตาม Resource Design

㉘ Error Discord Identifier

เช่นเดียวกัน

ตรวจ Schema Version ก่อน

㉙ Error JSON คือ Case ที่พบบ่อยมาก

FiveM Resources จำนวนมากอาจเก็บข้อมูลประเภท:

Inventory
Metadata
Appearance
Vehicle Properties

ใน JSON String

㉚ JSON โตขึ้นได้เรื่อย ๆ

ถ้า Player มี:

Items มาก
Metadata มาก
Custom Properties มาก

String อาจใหญ่ขึ้น

㉛ VARCHAR ไม่เหมาะกับ JSON ขนาดใหญ่เสมอไป

ต้องดู Resource Schema ว่าควรเป็น:

VARCHAR
TEXT
MEDIUMTEXT
LONGTEXT

แบบไหน

㉜ TEXT คืออะไร

MariaDB มี TEXT เป็น String Data Type สำหรับข้อมูลข้อความ และมีข้อจำกัดขนาดของตัวเอง

㉝ TEXT ไม่ได้ Unlimited

สำคัญมาก

TEXT ยังมี Maximum Size

ถ้าเกินก็สามารถเกิด Error 1406 ได้

㉞ TEXT กับ VARCHAR ต่างกันอย่างไร

ทั้งสองใช้เก็บ String แต่มีคุณสมบัติด้าน:

Maximum Size
Indexing
Storage

แตกต่างกัน

MariaDB ระบุว่า VARCHAR สามารถทำ Full Index ได้ ในขณะที่ TEXT มีข้อจำกัดด้านการ Index ตามความยาว

㉟ จึงไม่ควรเปลี่ยนทุกอย่างเป็น TEXT

เพราะ Column บางชนิดควรยังเป็น:

VARCHAR

เพื่อความหมายและ Index ที่เหมาะสม

㊱ String Data Types มีหลายชนิด

MariaDB รองรับชนิดข้อความหลายแบบ เช่น:

CHAR
VARCHAR
TEXT

รวมถึงชนิดขนาดใหญ่กว่า

㊲ MEDIUMTEXT คืออะไร

ใช้สำหรับ String ที่ต้องรองรับข้อมูลขนาดใหญ่กว่า TEXT

แต่ควรใช้เมื่อ Resource Schema ต้องการจริง

㊳ LONGTEXT คืออะไร

รองรับข้อมูลขนาดใหญ่มากกว่าอีกระดับ

แต่ไม่ได้หมายความว่าเป็นตัวเลือกที่ดีที่สุดสำหรับทุก Field

㊴ Inventory JSON อาจเหมาะกับ TEXT Type ใหญ่กว่า

ถ้า Official Resource Schema กำหนดแบบนั้น:

ควรทำตาม

㊵ Error inventory หลัง Update Resource

ตรวจ Migration ก่อน

Version ใหม่อาจเปลี่ยน Column จาก:

TEXT

ไป:

LONGTEXT

หรือ Data Model ใหม่

㊶ อย่า ALTER ก่อนดู Migration

Resource Developer อาจมี SQL Update ให้แล้ว

㊷ Error metadata

Metadata สามารถโตจาก:

Item Metadata
Character States
Custom Scripts

㊸ Metadata โตผิดปกติอาจเป็น Bug

ถ้า Resource append ข้อมูลเดิมซ้ำทุก Save:

JSON อาจโตขึ้นเรื่อย ๆ

㊹ เพิ่ม Column Size อย่างเดียวอาจเพียงเลื่อนปัญหา

วันนี้ 64 KB

อีกเดือนโตเป็นหลาย MB

ถ้า Bug ยัง append ต่อ

㊺ ต้องตรวจว่าข้อมูลควรใหญ่เท่าไร

เปรียบเทียบ:

Player ปกติ
Player ที่ Error

㊻ Error เฉพาะ Character เดียว

เป็นสัญญาณสำคัญ

อาจหมายถึง Character นั้นมี:

Inventory JSON ผิดปกติ
Metadata โต
Appearance Data เสีย

㊼ Error ทุก Character

น่าสงสัย:

Schema
Resource Version

มากกว่า Individual Data

㊽ Error เฉพาะ Player เก่า

อาจเป็น Legacy Data

㊾ Error เฉพาะ Player ใหม่

อาจเป็น New Save Format ที่ Schema เก่าไม่รองรับ

㊿ Error หลัง Framework Update

ให้ตรวจ:

Migration
Column Types
Resource Compatibility

ก่อน

51. Error หลัง Inventory Update

ตรวจว่า Inventory Resource เปลี่ยน:

Storage Format
Metadata Format

หรือไม่

52. Error หลัง Clothing Update

Appearance JSON อาจเปลี่ยนโครงสร้างและใหญ่ขึ้น

53. Error skin

บาง Character Systems เก็บ:

Model
Clothing
Face
Tattoos

รวมเป็น JSON

54. Appearance Data สามารถยาวมาก

โดยเฉพาะ Customization Resource ที่เก็บรายละเอียดจำนวนมาก

55. Error vehicle

Vehicle Properties อาจมี:

Mods
Colors
Damage
Extras

ใน JSON

56. Vehicle Properties ถูกเก็บใน VARCHAR สั้น

อาจเกิด 1406

57. Schema จาก Resource ใหม่อาจใช้ TEXT

จึงควรเปรียบเทียบ

58. Error trunk

ถ้า Trunk Inventory ถูกเก็บเป็น JSON ใน Column เดียว:

จำนวน Items
Metadata

อาจทำ String ใหญ่

59. Error glovebox ก็คล้ายกัน

ขึ้นกับ Inventory Architecture

60. Modern Inventory บางระบบแยก Items เป็น Rows

ไม่ได้เก็บ JSON ทั้งหมดใน Rowเดียว

ดังนั้นอย่าเดาว่า Inventory ทุก Serverเหมือนกัน

61. Resource Architecture มีผลมาก

Resourceหนึ่งใช้:

inventory JSON

อีกตัวใช้:

inventory_items table

62. วิธีแก้จึงต่างกัน

อย่า Copy SQLจาก Serverอื่น

63. Error business_data

Business Scriptอาจเก็บ:

Employees
Stock
Settings

ใน JSON

64. Error society

ตรวจ Resource Schema

อย่าเปลี่ยน Typeจาก Tutorialที่ใช้ Frameworkคนละตัว

65. Error notes

Playerอาจพิมพ์ Textยาวเกิน Field

66. UIควร Limit Text

เช่น Description/Notes:

Max Length

ให้สอดคล้องกับ Database

67. Chat Messageก็อาจ Errorได้

ถ้า Resourceบันทึกข้อความลง Columnที่สั้นเกิน

68. Phone Messages เป็น Caseหนึ่ง

ข้อความยาวกว่าที่ Phone Databaseรองรับ

69. ใช้ VARCHAR(255) เก็บข้อความ Chat ยาว ๆ อาจไม่พอ

แต่ต้องดู Phone Resource Schemaจริง

70. Tweet/Social Postก็เช่นกัน

ควรมีทั้ง:

UI Limit
Server Validation
Database Capacity

71. Billing Description

Invoice Descriptionยาวเกิน Schemaได้

ถ้า Playerพิมพ์ข้อความยาวมาก

72. Business Description

ร้านอาจมี Descriptionหลายร้อยตัวอักษร

Schemaต้องรองรับ Requirementนั้น

73. House Label

โดยทั่วไปควรสั้น

ถ้ามี Stringมหาศาลอาจแสดงว่า Scriptส่ง Fieldผิด

74. ส่ง JSON เข้า Column ชื่อ label

นี่อาจเป็น Query Mapping Bug

75. Error 1406 ไม่ได้แปลว่า Column เล็กเสมอไป

อาจหมายถึง:

Scriptส่งค่าผิด Column

76. ตัวอย่าง

Queryควรเป็น:

name → firstname
json → metadata

แต่ Parameter Orderผิด:

json → firstname

แน่นอนว่า firstname VARCHAR(50) จะรับ JSONไม่ได้

77. นี่สำคัญมาก

อย่าเห็น firstname Errorแล้วเพิ่ม firstnameเป็น LONGTEXTทันที

78. ตรวจ Query Parameters

โดยเฉพาะหลัง Developerแก้:

INSERT
UPDATE

79. Parameter Order ผิด

เกิดได้เมื่อ Query:

INSERT INTO players
(firstname, lastname, metadata)
VALUES (?, ?, ?)

แต่ Codeส่ง:

metadata
firstname
lastname

ผิดลำดับ

80. ผลอาจเป็น Data Too Long

หรือ Data Type Errorอื่น

81. Debug Actual Value

ดูว่าค่าที่พยายามเข้า Columnคืออะไร

ถ้า firstname มี JSONยาวหลายพันตัว:

Root Causeชัดเจนว่า Mappingผิด

82. อย่า Log Password/Secrets

ตอน Debugให้แสดงเฉพาะข้อมูลจำเป็น

83. Error Message มักบอก Column

เช่น:

Data too long for column 'metadata'

ใช้ชื่อนั้นเริ่ม Search Source Code

84. Search Column ใน Resource

เช่นค้น:

metadata

ใน:

SQL Files
Server Code
Migrations

85. ดู CREATE TABLE

ใช้:

SHOW CREATE TABLE players;

เพื่อดู Columnจริง

86. หรือ DESCRIBE

DESCRIBE players;

87. ตรวจ Field Type

เช่น:

metadata VARCHAR(255)

แล้วเทียบกับ Official Schema

88. ถ้า Official Schema เป็น LONGTEXT

ชัดเจนว่า Databaseอาจเก่า/สร้างผิด

89. ถ้า Official Schema ก็เป็น VARCHAR(255)

แต่ Valueยาว 20,000 ตัว

น่าสงสัย Resource/Data Bug

90. อย่าแก้ Schemaโดยไม่เปรียบเทียบสองฝั่ง

Expected Schema vs Actual Schema

91. Expected Schemaมาจากไหน

ใช้:

Official SQL
Migration
Resource Documentation

92. Actual Schemaมาจากไหน

Database Productionจริง

93. Errorหลัง Restore Backup

อาจ Restore Schemaเก่า

แต่ Codeเป็น Versionใหม่

94. Errorหลัง Update Codeอย่างเดียว

คล้ายกัน

Databaseไม่ได้ Migrationตาม

95. Version mismatch เป็นสาเหตุสำคัญ

Codeกับ Databaseต้องเดินคู่กัน

96. ALTER TABLE ใช้ทำอะไร

MariaDB ใช้ ALTER TABLE สำหรับแก้โครงสร้าง Table เช่นเปลี่ยน Column หรือ Index

97. ตัวอย่างแนวคิด

ALTER TABLE players
MODIFY COLUMN metadata LONGTEXT;

นี่เป็นเพียงตัวอย่าง

อย่ารันจนกว่าจะรู้ว่า Official Schemaต้องเป็นแบบนั้นจริง

98. Backupก่อน ALTER

จำเป็นสำหรับ Production

99. ALTER Column อาจใช้ทรัพยากร

โดยเฉพาะ Tableใหญ่

ควรทำช่วง Maintenance

100. อย่าปรับ Productionช่วง Peak

Charactersอาจกำลัง:

Save
Buy
Transfer

พร้อมกัน

101. Database Migrationควรทำก่อนเปิด Players

เหมาะกว่าแก้ขณะ Serverมีคนเล่น

102. Error 1406 กับ CHAR

CHAR ก็มี Length Limit และสามารถเกิด Data Too Long ได้เมื่อข้อมูลเกินขนาด

103. CHAR คืออะไร

เหมาะกับ Stringความยาวคงที่หรือใกล้เคียงตาม Design

104. Plateใช้ CHARได้ไหม

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

อย่าเปลี่ยน Typeโดยอาศัยบทความทั่วไป

105. VARBINARY ก็เกิด 1406ได้

MariaDBระบุว่าเมื่อข้อมูลเกินขนาด VARBINARY ภายใต้ Strict Modeสามารถเกิด Error 1406ได้เช่นกัน

106. ดังนั้น Error 1406 ไม่ใช่เฉพาะ VARCHAR

ประเด็นหลักคือ:

ค่ามีขนาดเกินสิ่งที่ Data Type/Columnรองรับ

107. LENGTH() คืออะไร

MariaDB LENGTH() ใช้วัดความยาว Stringเป็น Bytes ในโหมดปกติ ขณะที่ CHAR_LENGTH() วัดจำนวน Characters

108. ทำไมเรื่อง Bytesสำคัญ

ข้อความภาษาไทยและ Unicodeอาจใช้หลาย Bytesต่อ Character

ดังนั้น:

จำนวนตัวอักษร
จำนวน Bytes

ไม่ใช่สิ่งเดียวกัน

109. ภาษาไทย 100ตัวอักษรไม่จำเป็นต้องเท่ากับ100 Bytes

นี่สำคัญเวลา Debug String/Storage

110. ใช้ CHAR_LENGTH

เมื่อต้องการนับจำนวน Characters

111. ใช้ LENGTH

เมื่อต้องการดูขนาดใน Bytesตาม Behaviorปกติของ MariaDB

112. ตัวอย่างตรวจ

SELECT
CHAR_LENGTH(column_name),
LENGTH(column_name)
FROM table_name;

เปลี่ยนชื่อ Table/Columnให้ตรง Server

113. Emojiมีผลด้วยไหม

Unicode Charactersบางประเภทใช้หลาย Bytes

จึงควรคิดเรื่อง Character Setและ Storage

114. Character Setคืออะไร

กำหนดวิธีเก็บ Charactersใน Database

115. utf8mb4 พบได้บ่อย

รองรับ Unicodeกว้าง

แต่ Schemaของ Serverจริงเป็น Sourceหลัก

116. เปลี่ยน Character Setแก้ Error 1406ไหม

ไม่ควรทำโดยเดา

Errorอาจเกิดจาก Lengthจริงหรือ Schema mismatch

117. Row Size Too Large ต่างจาก Data Too Long

คนละ Error Family

Row Size Too Largeเกี่ยวกับขนาดโครงสร้าง Rowโดยรวม

Data Too Longมุ่งที่ค่าที่กำลังใส่ใน Columnหนึ่ง

MariaDBมีเอกสารแยกเรื่อง Row Size Too Large โดยเฉพาะ

118. เปลี่ยนทุก VARCHARเป็นใหญ่ขึ้นอาจทำ Row Size Problem

โดยเฉพาะ Tableที่มี Columnsจำนวนมาก

119. จึงต้องออกแบบ Schemaอย่างสมเหตุสมผล

ไม่ใช่:

ทุก Column = VARCHAR(5000)

120. ข้อมูล Textใหญ่ควรแยกตามลักษณะ

ถ้าข้อมูลเป็น:

JSON
Notes
Blob-like text

อาจต้อง Data Typeที่เหมาะกว่า

121. Data Modeling คืออะไร

การออกแบบว่า:

ข้อมูลอะไร
อยู่ Tableไหน
ใช้ Typeอะไร

122. FiveM Resource Ownerควรยึด Developer Schema

ถ้าไม่ได้พัฒนา Resourceเอง

123. Custom Developerควรเลือก Typeตาม Requirement

ไม่ใช่เลือก VARCHAR(255)ทุก Fieldโดยอัตโนมัติ

124. VARCHAR(255)ไม่ใช่มาตรฐานสากลสำหรับทุก String

เป็นเพียงขนาดที่พบได้บ่อยในหลายระบบ

125. Inventoryไม่ควรยัดใน VARCHAR(255)ถ้า JSONมีโอกาสโตมาก

ถ้า Architectureเลือก JSON Column

126. JSON Typeมีไหม

MariaDBมีรายละเอียดเกี่ยวกับ JSONในระบบ แต่ FiveM Resourcesอาจเลือก TEXT Storageเพื่อ Compatibility

ให้ยึด Resource Schema

127. Error JSON หลังเพิ่ม Item Metadata

Itemหนึ่งอาจมี:

Serial
Quality
Custom Name
Extra Data

เมื่อ Inventoryมีจำนวนมาก JSONขยาย

128. Inventory Scriptควรออกแบบ Capacity

ทั้ง Gameplayและ Storageต้องสอดคล้อง

129. Inventory Slot Limitไม่รับประกัน JSONเล็ก

เพราะ Metadataต่อ Itemอาจใหญ่มาก

130. Item Metadata Bugสามารถทำ JSONระเบิดได้

เช่น Metadataซ้อน Metadataเดิมทุก Save

131. ตัวอย่าง Concept

ครั้งแรก:

metadata = A

ครั้งต่อไป:

metadata = A + previous A

โตแบบผิดปกติ

132. ถ้า JSONโตทุก Save

ต้องแก้ Serialization Logic

ไม่ใช่เพิ่ม LONGTEXTต่อไปเรื่อย ๆ

133. Serialization คืออะไร

แปลง Object/Data Structureเป็น String/Formatเพื่อ Save

เช่น JSON

134. Deserialization คืออะไร

อ่าน Stringกลับเป็น Data Structure

135. Double Serialization คืออะไร

JSONถูก stringifyซ้ำ

เช่น Object:

{"name":"item"}

กลายเป็น Stringที่มี Escape Charactersซ้ำ

136. Double Serializationทำข้อมูลโต

และอาจทำ Parsingพัง

137. FiveM Metadata Errorควรตรวจ JSON Structure

โดยเฉพาะถ้า Valueดูเต็มไปด้วย:

\"\\\"

จำนวนมาก

138. Error appearance_data

Character Appearanceอาจถูก Serializeซ้ำเช่นกัน

139. Vehicle Modsก็เป็นได้

Resource Conversionผิดอาจทำ JSONใหญ่ผิดปกติ

140. ตรวจ Recordปกติกับ Recordผิด

เป็นวิธี Debugที่ดี

141. ตัวอย่าง

Playerปกติ:

metadata length = 5,000

Player Error:

metadata length = 500,000

แสดงว่าควรสงสัย Data Bug

142. อย่าเพิ่ม Columnทันทีจาก 64 KB เป็นหลาย GB

เพราะจะซ่อนต้นเหตุ

143. Error Messageมี Row Number

เช่น:

at row 1

หมายถึง Rowใน Statement/Operationที่เกิด Error ไม่จำเป็นต้องเป็น Database Primary ID = 1

144. มือใหม่มักเข้าใจผิด

row 1

ไม่ได้แปลว่า:

id = 1

เสมอไป

145. Bulk INSERTอาจมีหลาย Rows

Errorอาจบอกว่าค่าเกินใน Rowใดของ Statement

146. Import SQLใหญ่ก็เกิด 1406ได้

ถ้า Dumpมาจาก Schemaที่ Columnใหญ่กว่า Databaseปลายทาง

147. Example Migration

Source:

notes TEXT

Destination:

notes VARCHAR(255)

Importข้อความยาว:

Error 1406

148. Schemaต้อง Syncก่อน Data Import

ไม่ควร Import Dataเข้า Schemaที่ไม่ตรง

149. Database Mergeก็คล้ายกัน

สอง Serverอาจใช้ Resource Versionsต่างกัน

150. Mergeต้อง Normalize Schemaก่อน

ไม่เช่นนั้น Dataจาก Serverหนึ่งอาจไม่พอดีอีก Server

151. CSV Importก็เกิดได้

ถ้า Fieldยาวเกิน Column

152. Manual Data Editใน phpMyAdminก็เกิดได้

Database Ruleเหมือนเดิม

153. phpMyAdminไม่ได้ทำให้ Columnรองรับมากขึ้น

เป็นเพียง Management UI

154. HeidiSQLก็เช่นเดียวกัน

Toolไม่ใช่ต้นเหตุ

155. Errorเกิดตอน INSERT

แปลว่า Rowใหม่เข้าไม่ได้

156. Errorเกิดตอน UPDATE

หมายถึง Resourceกำลังเปลี่ยนค่าของ Rowเดิมให้ยาวเกิน Limit

157. Save Characterมักใช้ UPDATE

ดังนั้น Characterเล่นได้ช่วงหนึ่งแล้ว Errorตอน Saveก็เป็นไปได้

158. Inventoryโตระหว่าง Session

ตอน Loginยังพอดี

หลังเก็บ Itemsจำนวนมาก:

Saveแล้วเกิน

159. นี่ช่วยบอก Root Cause

ถ้า Errorเกิดเฉพาะตอน Disconnect:

ดู Save Data

160. Errorตอน Stop Resource

บาง Resources Save Cached Dataตอน Shutdown

JSONที่โตอาจ Errorตอนนั้น

161. อย่า Restartซ้ำโดยไม่แก้

เพราะทุก Restartอาจเกิด Save Errorเดิม

162. Dataล่าสุดอาจไม่ถูกบันทึก

ตรวจ Gameplay Impact

163. Errorใน Inventory Saveอาจทำ Item Rollback

เมื่อ Playerเข้าใหม่อาจเห็นข้อมูลเก่า

164. Errorใน Banking Notesอาจไม่ร้ายเท่า Balance Error

Severityขึ้นกับ Column

165. อ่าน Query Context

อย่าดูแค่ Column Name

166. ถ้า Query Save Moneyพร้อม JSON

หนึ่ง Fieldผิดอาจทำ Statementทั้งหมด Fail

167. Transactionsช่วยให้ Data Consistency

แต่ Resource Architectureต่างกัน

168. Errorหนึ่ง Fieldอาจหยุดหลาย Fields Update

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

169. Error logs table

Gameplayอาจยังทำงานแต่ Logsหาย

ยังมีผลกับ:

Staff Auditing

170. Discord webhook JSONไม่เกี่ยวกับ DBเสมอไป

อย่าสับสน Webhook Payloadกับ Database Column

171. Error webhook_message Column

ถ้า Resourceเก็บ Webhook Logsใน DB:

จึงค่อยเกี่ยว

172. TEXT Messageควรมี Limit

ป้องกัน Playerใส่ข้อความขนาดมหาศาล

173. Client-side Limitอย่างเดียวไม่พอ

Playerอาจ Bypass UIได้

Serverต้อง Validateด้วย

174. Server-side Validationสำคัญ

ก่อน Database Queryตรวจ:

Type
Length
Allowed Range

175. Data Too Longอาจใช้โจมตี Resourceที่ Validateไม่ดีได้

ในเชิงป้องกัน ระบบควร Reject Inputผิดปกติ

176. ไม่ควรเปิดเผยวิธี Bypass Input Validation

สำหรับ Server Ownerให้โฟกัสการป้องกัน:

Server Validation
Length Limit

177. SQL Injectionคนละเรื่อง

Parameterized Queryช่วย Security

แต่ Parameterized Queryไม่ได้แก้ Stringยาวเกิน

178. Prepared Statementยัง Error 1406ได้

ถ้าค่าจริงยาวเกิน Column

179. อย่าโทษ oxmysqlทันที

Database Bridgeเพียงส่ง Query

Root Causeอาจเป็น Resource Schema

180. oxmysql Error Messageมีประโยชน์

อาจแสดง:

Query
Parameters
Resource

ช่วยหา Source

181. ระวัง Logsมีข้อมูลส่วนตัว

ก่อนโพสต์ Publicควร Mask:

Tokens
Identifiersที่ไม่จำเป็น

182. Closed-source Resource

ถ้าไม่เห็น Queryให้ใช้:

Error
SQL Schema
Official Support

183. อย่าเดาแก้ Encrypted Resource Schema

Developerควรบอก Requirements

184. Errorเกิดหลังซื้อ Scriptใหม่

ตรวจ Installation SQLให้ครบ

185. บาง Scriptมี SQL แยก Framework

เช่น:

ESX SQL
QBCore SQL

Importผิดไฟล์สามารถสร้าง Column Typeผิด

186. Config Frameworkผิดก็เช่นกัน

Scriptอาจใช้ Data Structureคนละแบบ

187. Resource Bridgeควรตรง Framework

เช่นเดียวกับ Schema

188. Errorหลัง Framework Conversion

Serverที่ย้าย ESX → QBCore หรือกลับกันต้องทำ Data Migrationจริง

ไม่ใช่ Rename Tablesอย่างเดียว

189. Character Data Formatsต่างกัน

JSON Structure/Identifiersอาจไม่เหมือน

190. Error 1406อาจเป็นเพียง Errorแรก

หลังแก้ Lengthอาจพบ:

Unknown Column
Invalid JSON
Duplicate Key

ถ้า Migrationทั้งหมดไม่ถูก

191. อย่า Patchทีละ Errorถ้า Root Causeคือ Resourceผิด Framework

แก้ Compatibilityทั้งชุด

192. Checklist Error 1406

อ่าน Errorเต็ม
หา Table
หา Column
ดู Actual Value
ดู Column Type
ตรวจ Official Schema
ตรวจ Migration
Backup
แก้ SourceหรือSchema
Test

193. ถ้า Actual Valueสมเหตุสมผลแต่ Columnเล็ก

Schemaอาจต้องเพิ่ม

194. ถ้า Actual Valueผิดปกติ

แก้ Resource/Dataก่อน

195. ถ้า Valueอยู่ผิด Field

แก้ Query Mapping

196. ถ้า Errorเฉพาะ Legacy Player

Clean/Migrate Legacy Data

197. ถ้า Errorทุก Playerหลัง Update

Run Missing Migrationหรือ Roll Forwardอย่างถูกต้อง

198. ถ้า Errorหลัง Import

เปรียบเทียบ Source/Destination Schema

199. ถ้า Errorหลังย้าย Hosting

ตรวจว่า Restore Schemaครบและตรง Version

200. ไม่ควรทำอะไร

ปิด Strict Modeทันที
เปลี่ยนทุก Columnเป็น LONGTEXT
ตัด Stringแบบไม่รู้ความหมาย
Delete Character
Import SQLทับ
ALTERหลาย Columnพร้อมกัน

201. ทำไมไม่ควรปิด Strict Modeก่อน

MariaDBระบุว่า Strict Modeทำให้การเขียนข้อมูลที่ผิดบางประเภท Failแทนการถูกตัด/ปรับเป็น Warning ดังนั้น Errorอาจช่วยป้องกัน Data Lossแบบเงียบ ๆ

202. ทำไมไม่ควรใช้ INSERT IGNORE

แม้บาง SQL Behaviorอาจเปลี่ยน Errorเป็น Warningได้ แต่การทำให้ข้อมูลถูกตัดไม่ใช่ทางแก้ที่ดีสำหรับ Identifierหรือ JSONสำคัญ

203. ตัวอย่างอันตราย

Phone Number:

555123456789

ถูกตัดเหลือ:

55512345

อาจไม่ใช่เบอร์เดิมอีกแล้ว

204. Vehicle Plateก็เหมือนกัน

ตัด Plateอาจชนกับรถอื่น

205. Character Identifierยิ่งห้ามตัดสุ่ม

Account Mappingอาจเสียร้ายแรง

206. JSONถูกตัดคืออันตรายมาก

JSONอาจกลายเป็น:

Invalid JSON

และ Resource Parseไม่ได้

207. JSON Truncationอาจทำ Characterโหลดไม่ได้

ดังนั้น Strict Errorบางครั้งดีกว่าบันทึก JSONครึ่งเดียว

208. Data Integrityสำคัญกว่า Queryผ่าน

หลักเดียวกับ Duplicate Entry

209. วิธีวัด Valueก่อน Insert

Developerสามารถ Validate String Lengthใน Codeก่อน Query

210. ถ้า Valueเป็น JSON

อาจตรวจ:

Serialized Size
Expected Structure

211. ถ้าเกินผิดปกติให้ Reject/Log

แทนบันทึกข้อมูลเสีย

212. Server Ownerควรดู Player Dataไหม

เฉพาะเท่าที่จำเป็นต่อ Debug และต้องจัดการข้อมูลอย่างเหมาะสม

213. Database Backupก่อน Clean Data

จำเป็น

214. อย่า DELETE Characterเพราะ JSONใหญ่

อาจสามารถ:

Repair
Migrate

เฉพาะ Fieldได้

215. แต่ต้องรู้ Structure

ถ้าไม่รู้ให้ใช้ Official Support

216. Manual JSON Editเสี่ยง

เครื่องหมาย:

"
{
}
,

ผิดเพียงจุดเดียวอาจ Parseไม่ได้

217. JSON Validatorมีประโยชน์

สำหรับ Developer/Server Ownerตรวจ Structure

แต่ข้อมูล Sensitiveไม่ควร Uploadไป Websiteสาธารณะโดยไม่จำเป็น

218. ใช้ Local Toolsปลอดภัยกว่า

สำหรับข้อมูล Productionที่ Sensitive

219. Error Data Too Longไม่ได้เกิดจาก Internet

เป็น Database/Application Problem

220. Pingไม่เกี่ยว

การเปลี่ยน DNS/VPNไม่แก้ Column Size

221. Clear FiveM Cacheไม่ใช่ Fixหลัก

เพราะ MariaDBกำลังปฏิเสธ Queryฝั่ง Server

222. Reinstall GTA Vไม่เกี่ยว

Player Clientไม่ได้กำหนด Database Column

223. Restart MySQLไม่ช่วย

ถ้า Valueเดิมยังยาวเกิน:

Errorเดิมจะกลับมา

224. Restart FiveMก็เช่นกัน

ถ้า Schema/Resourceยังผิด

225. Reinstall MariaDBไม่ใช่คำตอบ

อาจเสี่ยง Database Dataโดยไม่จำเป็น

226. Quick Diagnosis Matrix

อาการ	สงสัย
ทุก Player Error	Schema/Migration
Playerเดียว Error	Abnormal Data
หลัง Update	Version mismatch
JSON Column	Size/Serialization
Plate/Phone	Generator/Schema
firstname/lastname	UI Limit/Schema
Valueดูเป็น JSONใน name	Parameter Mapping
Errorตอน Import	Source/Destination Schema

227. Error 1406 กับ VARCHAR Quick Fix

ตรวจ Official Schema

ถ้า Resourceกำหนด:

VARCHAR(100)

แต่ Productionเป็น:

VARCHAR(50)

Migrationอาจหาย

228. Error 1406 กับ TEXT Quick Fix

ตรวจว่า Resource Versionควรใช้:

TEXT
MEDIUMTEXT
LONGTEXT

อะไร

229. Error 1406 กับ JSON Quick Fix

ตรวจก่อนว่า JSON:

ใหญ่ตามปกติ
หรือโตจาก Bug

230. Error 1406 กับ Identifier Quick Fix

อย่าตัด Identifier

ทำ Columnให้ตรง Official Schema

231. Error 1406 กับ Phone Quick Fix

ตรวจ Formatและ Generator

232. Error 1406 กับ Plate Quick Fix

ตรวจ Plate Lengthและ Collision Rules

233. Error 1406 กับ Character Name Quick Fix

ปรับ:

UI max length
Server Validation
Database Capacity

ให้สอดคล้องกัน

234. Error 1406 กับ Description

ถ้าต้องการข้อความยาวจริงอาจต้องใช้ Text Typeที่ Resourceออกแบบไว้

235. Error 1406 กับ Logs

Log Payloadอาจใหญ่กว่าที่ออกแบบ

ควรตรวจว่ากำลัง Logข้อมูลมากเกินจำเป็นหรือไม่

236. Logทุก JSON Stateอาจทำ Databaseโตเร็ว

นอกจาก Error Lengthแล้วยังเพิ่ม Storage

237. Loggingควรเก็บข้อมูลที่จำเป็น

ไม่ใช่ Dumpทุก Objectตลอดเวลา

238. Error 1406 อาจเป็น Performance Warningทางอ้อม

ถ้า Metadataโตมหาศาล

แม้ขยาย Columnได้ Serverก็อาจ:

Saveช้า
Loadช้า

239. Large JSONทำ Queryหนักขึ้น

โดยเฉพาะถ้าบันทึกบ่อย

240. Normalize Data Modelอาจดีกว่า

สำหรับ Custom Developer หาก Dataใหญ่และ Queryเฉพาะส่วนบ่อย อาจพิจารณาแยกข้อมูลเป็น Tables

แต่เป็น Architecture Decision

241. Server Ownerไม่ควร Rewrite Resourceเพียงเพื่อ Errorเดียว

ใช้ Official Fixก่อน

242. Update Resourceถ้ามี Fix

ถ้า Developerแก้ Serialization Bugแล้ว

243. Backupก่อน Update

โดยเฉพาะ Resourceที่มี Migration

244. Changelogควรอ่าน

ค้นคำ:

database
migration
column
inventory
metadata

245. SQL Folderควรเก็บไว้

ใช้ตรวจ Schemaภายหลัง

246. Schema Documentationมีค่ามาก

โดยเฉพาะ Serverที่ติด Scriptsจำนวนมาก

247. จดว่า Resourceไหนแก้ Tableไหน

ลดปัญหาเวลาถอด Script

248. อย่าลบ Columnเก่าทันทีหลังเปลี่ยน Resource

ตรวจว่า Scriptsอื่นยังใช้หรือไม่

249. Database Schema Debtเกิดได้

เมื่อปรับ Columnsสุ่มตาม Errorsหลายปี

สุดท้ายไม่มีใครรู้ว่า Tableควรเป็นแบบไหน

250. วิธีลด Schema Debt

Official migrations
Version control
Document changes
Staging tests

251. Error 1406 FAQ

FiveM Data too long for column คืออะไร

หมายถึงค่าที่ Resourceพยายามบันทึกใหญ่เกิน Columnใน MariaDB รองรับ โดย Error 1406 มี SQLSTATE 22001 และชื่อ ER_DATA_TOO_LONG

Errorนี้เกิดกับ VARCHARเท่านั้นไหม

ไม่ สามารถเกี่ยวกับ String/Binary Data Typesอื่นที่มีข้อจำกัดขนาดได้ เช่น CHAR, TEXT และ VARBINARY

VARCHAR ยาวเกินเกิดอะไร

ใน Strict SQL Mode MariaDBสามารถ Rejectข้อมูลที่ยาวเกินและคืน Errorแทนการตัดค่าผ่าน

ปิด Strict Modeแก้ได้ไหม

อาจเปลี่ยน Behavior แต่ไม่ควรเป็นวิธีหลัก เพราะอาจทำให้ค่าถูกตัดและข้อมูลผิดโดยไม่แก้ Root Cause

เปลี่ยน VARCHARเป็นTEXTได้ไหม

ทำได้เมื่อ Schema/Requirementต้องการจริง แต่ไม่ควรเปลี่ยนทุก Fieldโดยอัตโนมัติ

เปลี่ยนเป็น LONGTEXTเลยดีไหม

ไม่ควรจนกว่าจะตรวจ Official Resource Schemaและ Actual Dataก่อน

TEXTเต็มได้ไหม

ได้ TEXT ก็มีข้อจำกัดขนาด และ MariaDBสามารถเกิด Error 1406เมื่อข้อมูลเกินได้

Inventoryขึ้น Data Too Longทำอย่างไร

ตรวจว่า Inventoryถูกเก็บแบบ JSONหรือ Rows, ดู Schemaที่ Resourceต้องการ และตรวจว่า JSONโตผิดปกติหรือไม่

Metadataใหญ่เกินแก้อย่างไร

ตรวจ Serializationก่อน เพราะอาจมี Bugทำข้อมูลซ้ำ/ซ้อนทุก Save

Vehicle JSONใหญ่เกินทำอย่างไร

ตรวจ Vehicle Resource Schemaและ Propertiesที่ถูก Save

Plateยาวเกินทำอย่างไร

ตรวจ Plate Generatorและ Schema ไม่ควรตัด Plateแบบสุ่ม

Phone Numberยาวเกินทำอย่างไร

ทำ Phone Format, UI Limit, Server Validationและ Database Schemaให้ตรงกัน

firstnameยาวเกินทำอย่างไร

ตรวจ Character Creator Maximum Lengthและ Schema

Identifierยาวเกินทำอย่างไร

อย่าตัด Identifier ให้ตรวจ Migration/Schemaของ Framework

Errorเกิด Characterเดียวทำอย่างไร

เปรียบเทียบขนาดและ Structureของ Fieldนั้นกับ Characterปกติ

Errorเกิดทุกคนทำอย่างไร

ตรวจ Schema/Resource Version/Migration

Errorเกิดหลัง Updateทำอย่างไร

อ่าน Changelogและ Run Database Migrationที่ตรง Version

Errorเกิดหลัง Restore Backupทำอย่างไร

ตรวจว่า Database Schemaของ Backupตรงกับ Codeปัจจุบันหรือไม่

Errorเกิดตอน Import SQLทำอย่างไร

เปรียบเทียบ Source Schemaกับ Destination Schemaก่อนแก้ Data

ALTER TABLEช่วยได้ไหม

MariaDBรองรับ ALTER TABLE เพื่อแก้โครงสร้าง Columns แต่ควร Backupและใช้ Definitionที่ตรง Resourceจริง

`LENGTH()` กับ `CHAR_LENGTH()` ต่างกันอย่างไร

MariaDBระบุว่า LENGTH() วัดเป็น Bytesในโหมดปกติ ส่วน CHAR_LENGTH() วัดจำนวน Characters

ภาษาไทยมีผลไหม

ข้อความ Unicodeสามารถใช้จำนวน Bytesไม่เท่ากับจำนวน Characters จึงควรแยกสองแนวคิดนี้เวลาตรวจขนาดข้อมูล

JSONถูกตัดได้ไหม

ไม่ควรปล่อยให้ JSONสำคัญถูกตัด เพราะอาจกลายเป็นข้อมูลที่ Parseไม่ได้

Clear FiveM Cacheช่วยไหม

โดยทั่วไปไม่ใช่ Fixสำหรับ MariaDB Error 1406

Restart Databaseช่วยไหม

ไม่ ถ้าค่ากับ Schemaยังเหมือนเดิม

ต้องลบ Characterไหม

ไม่ควรเป็นวิธีแรก ควรหา Fieldและข้อมูลที่ผิดก่อน

ต้องลบ Databaseสร้างใหม่ไหม

ไม่ และมีความเสี่ยงสูงมากโดยไม่จำเป็น

สรุป FiveM MySQL Data Too Long for Column Error 1406

FiveM MySQL/MariaDB Error 1406 Data too long for column หมายถึง Resource กำลังส่งค่าที่มีขนาดใหญ่เกิน Column ที่ Database รองรับ โดย MariaDB ระบุ Error นี้เป็น ER_DATA_TOO_LONG และ SQLSTATE 22001

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

VARCHAR สั้นเกิน → Resource Update แต่ไม่ได้ Migration → JSON Inventory/Metadata ใหญ่เกิน → Identifier Format เปลี่ยน → Character Input ยาวเกิน → Parameter ถูกส่งผิด Column → Serialization Bug ทำข้อมูลโตผิดปกติ

สิ่งที่ comsiam แนะนำคืออย่าเห็น Error 1406 แล้วเปลี่ยนทุก Field เป็น LONGTEXT หรือปิด Strict Modeทันที ให้เปิด SHOW CREATE TABLE หรือ DESCRIBE ตรวจ Schemaจริง แล้วเปรียบเทียบกับ SQL/Migrationของ Resource Versionที่ใช้อยู่ จากนั้นตรวจ Actual Valueด้วยว่าเป็นข้อมูลที่ควรมีขนาดนั้นจริงหรือไม่

อีกหลักที่ comsiam แนะนำคือให้ระวัง Fieldที่เป็น Identifier, Plate, Phone Number และ JSONเป็นพิเศษ การ “ตัดให้สั้นลง” เพื่อให้ Queryผ่านอาจทำให้ Identifierผิด, รถชนกัน, Phone Numberซ้ำ หรือ JSONเสียจน Characterโหลดไม่ได้ วิธีที่ถูกต้องคือทำให้ Code + Validation + Schema + Data Format ตรงกัน และ Backup Production Databaseก่อนใช้ ALTER TABLE หรือ Cleanข้อมูลจำนวนมากเสมอ