FiveM MariaDB Data Truncated for Column แก้อย่างไร? วิธีแก้ Error 1265 เมื่อค่าถูกแปลงหรือตัดไม่ตรง Data Type

 FiveM MariaDB Data truncated for column คือ Error หรือ Warning ที่ MariaDB ใช้เมื่อค่าที่กำลัง INSERT หรือ UPDATE ไม่สามารถถูกเก็บใน Column ได้ตรงตามรูปแบบที่ Data Type คาดหวัง จึงเกิดการแปลง ตัด หรือสูญเสียข้อมูลบางส่วน โดย MariaDB กำหนดรหัส 1265, SQLSTATE 01000 และชื่อ WARN_DATA_TRUNCATED.

ตัวอย่างข้อความที่อาจเห็นใน FiveM Console:

Data truncated for column 'status' at row 1
Data truncated for column 'type' at row 1
Data truncated for column 'amount' at row 1
Data truncated for column 'created_year' at row 1

Error นี้ไม่เหมือน 1264 Out of range value และไม่เหมือน 1406 Data too long โดยตรง เพราะ 1265 มักชี้ไปที่ปัญหา การแปลงค่าหรือรูปแบบข้อมูลไม่ตรงกับ Data Type ของ Column มากกว่าเพียงตัวเลขเกินช่วงหรือข้อความยาวเกินพื้นที่.

แนวทางตรวจที่ควรใช้คือ:

Error 1265
↓
ดู Table / Column
↓
ดูค่าที่ Resource ส่งจริง
↓
SHOW CREATE TABLE
↓
ดู Data Type
↓
ตรวจ ENUM / DECIMAL / DATE / YEAR / Numeric Conversion
↓
ตรวจ Parameter Order
↓
ตรวจ SQL_MODE
↓
แก้ข้อมูลหรือ Schema ต้นเหตุ

① Error 1265 คืออะไร

MariaDB กำหนด:

Error Code: 1265
SQLSTATE: 01000
Symbol: WARN_DATA_TRUNCATED

ข้อความคือ:

Data truncated for column '...' at row ...

คำว่า truncated ในที่นี้ไม่ได้แปลเพียงว่า “ข้อความยาวแล้วถูกตัดท้าย” เสมอไป แต่สามารถเกิดจากการแปลงค่าไปเป็น Data Type เป้าหมายแล้วข้อมูลบางส่วนไม่สามารถถูกแทนค่าได้อย่างสมบูรณ์

② Error 1265 ต่างจาก Error 1264 อย่างไร

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

1264
Out of range value

หมายถึงค่าตัวเลขอยู่นอก Range ที่ Column รองรับ

ส่วน:

1265
Data truncated

หมายถึงข้อมูลถูกแปลงหรือตัดแล้วไม่สามารถเก็บได้อย่างสมบูรณ์ตาม Data Type ปลายทาง

MariaDB แยก Error Codes สองตัวนี้ไว้คนละรายการโดยตรง.

จำง่ายๆ:

1264
= ค่าอยู่นอกช่วง

1265
= ค่าแปลงแล้วสูญเสีย/ไม่ตรงรูปแบบ

③ Error 1265 ต่างจาก Error 1406 อย่างไร

1406 Data too long for column เกิดเมื่อข้อมูลยาวเกินขนาด Column ที่รองรับ

ส่วน 1265 สามารถเกิดแม้ข้อมูลไม่ได้ยาวมาก แต่ ค่าไม่เหมาะกับ Type เช่นนำ String ที่ไม่อยู่ในรายการ ENUM ไปบันทึกลง ENUM Column. MariaDB มีตัวอย่างตรงที่ Insert ค่า ENUM ที่ไม่ถูกต้องแล้วเกิด Error 1265.

ดังนั้น:

1406
= ขนาดข้อมูลใหญ่เกิน

1265
= รูปแบบ/การแปลงข้อมูลไม่ตรง

④ สาเหตุที่พบบ่อยใน FiveM

ควรตรวจอย่างน้อย:

① ค่าไม่อยู่ใน ENUM
② String ถูกใส่ Numeric Column
③ Decimal มี Scale ไม่ตรง
④ Date/Year Format ไม่ถูกต้อง
⑤ Parameter สลับ Column
⑥ Resource Version กับ Schema Version ไม่ตรง
⑦ Column ถูกเปลี่ยน Type หลัง Migration
⑧ SQL_MODE ต่างจาก Server เดิม
⑨ Import ข้อมูลจาก Schema คนละแบบ
⑩ Resource ส่งค่าใหม่ที่ Database รุ่นเก่าไม่รองรับ

⑤ ENUM เป็นสาเหตุยอดนิยม

สมมติ Table:

CREATE TABLE `characters` (
    `status` ENUM(
        'online',
        'offline'
    ) NOT NULL
);

แต่ Resource ส่ง:

busy

ค่าดังกล่าวไม่ได้อยู่ใน ENUM Definition

MariaDB Documentation แสดงตัวอย่างว่าการ Insert ค่า ENUM ที่ไม่อยู่ใน Allowed Values สามารถเกิด ERROR 1265 Data truncated for column.

⑥ วิธีตรวจ ENUM

ใช้:

SHOW CREATE TABLE `characters`;

แล้วหา:

`status` enum(
    'online',
    'offline'
)

จากนั้นเปรียบเทียบกับค่าที่ Resource ส่งจริง

ถ้า Resource ส่ง:

active

แต่ Database ยอมรับเพียง:

online
offline

ก็พบ Root Cause แล้ว

⑦ อย่าเพิ่ม ENUM Value แบบเดาสุ่ม

ถ้า Script ส่ง:

active

อย่ารีบ:

ALTER TABLE ...

เพิ่ม active เข้า ENUM ทันที

ต้องตรวจก่อนว่า Official Resource Version กำหนดค่า:

active

จริงหรือไม่

อาจเป็น Bug เช่น:

Resource A
ใช้ online/offline

Resource B
ใช้ active/inactive

แล้วสอง Scripts เขียน Column เดียวกันด้วย Data Model คนละแบบ

⑧ Resource Version กับ ENUM ต้องตรงกัน

ตัวอย่าง:

Script v1
status:
online
offline

แต่ Script v2 เปลี่ยนเป็น:

online
offline
away

ถ้า Database Migration ไม่เคยเพิ่ม:

away

Resource ใหม่สามารถเริ่มสร้าง Error 1265 ได้

นี่เป็นตัวอย่างคลาสสิกของ:

Resource ใหม่
+
Schema เก่า

⑨ DECIMAL ก็เกิด 1265 ได้

MariaDB Documentation ของ DECIMAL แสดงกรณีที่ค่ามี Fractional Precision มากกว่าที่ Column กำหนด และระบบสามารถรายงาน 1265 Data truncated for column.

สมมติ:

`rating` DECIMAL(10,2)

Resource ส่ง:

12.345678

Column รองรับทศนิยมตาม Scale ที่กำหนดเพียง 2 ตำแหน่ง

Database จึงต้องจัดการ Fraction ส่วนเกินตาม SQL Mode/Context

⑩ DECIMAL(M,D) คืออะไร

ตัวอย่าง:

DECIMAL(10,2)

แนวคิดคือ:

M = จำนวน Digits รวม
D = จำนวน Digits หลังจุดทศนิยม

MariaDB ใช้ DECIMAL สำหรับ Exact Fixed-point Numeric Data และ Range/Scale ถูกกำหนดจาก Precision ที่ตั้งไว้.

ดังนั้นอย่าใช้:

DECIMAL(5,2)

กับค่าที่ Application อาจต้องเก็บ Digits มากกว่าที่ Schemaรองรับ

⑪ เงินหรือค่าทศนิยมต้องกำหนด Scale ให้ตรง

สมมติ Resource คำนวณ:

125.6789

แต่ Database ต้องการ:

DECIMAL(10,2)

ต้องกำหนด Business Rule ให้ชัดว่า:

125.68

เป็นค่าที่ต้องการหรือไม่

Application ควรจัดการ Precision/rounding ตาม Requirement แทนปล่อยให้ Database Truncation เป็นสิ่งที่ตัดสิน Gameplay Logic โดยบังเอิญ

⑫ YEAR ก็สร้าง 1265 ได้

MariaDB Documentation ยกตัวอย่างการ Insert:

2013-12-12

ลง YEAR Column แล้วเกิด:

ERROR 1265
Data truncated for column

เพราะค่าที่ส่งไม่ตรงรูปแบบข้อมูลที่ YEAR Column คาดหวัง.

ดังนั้นถ้า FiveM Resource ใช้ Fields เช่น:

model_year
registration_year
created_year

ต้องตรวจ Data Type จริง

⑬ อย่าส่ง DATE เข้า YEAR

สมมติ Column:

`model_year` YEAR

แต่ Resource ส่ง:

2026-08-13

Database ไม่ได้ถูกออกแบบให้เก็บ Date เต็มใน Column นี้

ควรส่ง:

2026

ถ้า Data Model ต้องการเพียงปี

หรือเปลี่ยน Schema เป็น:

DATE
DATETIME
TIMESTAMP

หาก Requirement ต้องเก็บวัน/เวลาเต็มจริง

⑭ Data Type ต้องสะท้อนข้อมูลจริง

อย่าใช้:

YEAR

เพียงเพราะข้อมูล “เกี่ยวกับเวลา”

หรือ:

INT

เพียงเพราะข้อมูลดูเหมือนตัวเลข

ควรถามว่า:

ข้อมูลนี้มีความหมายอะไร?
ต้อง Query แบบไหน?
ต้องเก็บ Precision เท่าไร?
ค่าที่เป็นไปได้มีอะไร?

ก่อนกำหนด Type

⑮ String ลง Numeric Column

สมมติ:

`level` INT

แต่ Resource ส่ง:

level_10

นี่คือ Data Type Contract ที่ไม่ตรงกัน

อาจเกิดจาก:

Parameter ผิด
Config Format เปลี่ยน
JSON Decode ผิด
Variable Mapping ผิด

อย่าเริ่มจากเปลี่ยน INT เป็น VARCHAR

ต้องถามก่อนว่า level ควรเป็นเลขจริงหรือไม่

⑯ Parameter สลับกันเป็นสาเหตุสำคัญ

ตัวอย่าง:

MySQL.update.await([[
    UPDATE `players`
    SET `status` = ?,
        `level` = ?
    WHERE `id` = ?
]], {
    level,
    status,
    playerId
})

SQL ต้องการ:

Parameter 1 = status
Parameter 2 = level

แต่ Resource ส่ง:

Parameter 1 = level
Parameter 2 = status

จึงอาจกลายเป็น:

status = 10
level = "online"

จากนั้น MariaDB ต้องพยายามแปลงข้อมูลผิดประเภท

⑰ SQL Syntax ถูกไม่ได้แปลว่า Values ถูก

Query:

UPDATE `players`
SET `status` = ?,
    `level` = ?
WHERE `id` = ?;

อาจ Parse ถูก 100%

แต่ถ้า Parameters ไม่ตรง Column:

Syntax = ถูก
Data Mapping = ผิด

Error จึงเกิดตอน Database ประมวลผล Values ไม่ใช่ตอน Parse SQL

⑱ oxmysql Parameters ต้องตรวจให้ครบ

oxmysql Query API รองรับ Parameter Values และ prepare ใช้ ? เป็น Value Placeholder ตาม Documentation ปัจจุบัน.

ตัวอย่าง:

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

เมื่อเจอ 1265 ต้องตรวจ:

SQL
+
Parameter Order
+
Parameter Type

พร้อมกัน

⑲ mysql_debug ช่วยได้

oxmysql ระบุว่า Real Query Speeds และข้อมูล Query Debug สามารถดูผ่าน Debug UI และ Server Console เมื่อเปิด mysql_debug.

เป้าหมายไม่ได้มีเพียงดู Query ช้า

แต่ช่วยจับว่า:

Resource ไหน
↓
Execute Query ไหน
↓
ตอน Error เกิด

จากนั้นกลับไปตรวจ Values ใน Resource

⑳ อย่า Print JSON หรือข้อมูลส่วนตัวทั้งหมด

หากต้อง Debug Parameter ให้เก็บเฉพาะ:

Resource
Column
Lua type
Value length
Record ID

ตามความจำเป็น

เช่น:

print(
    'status type:',
    type(status),
    'value:',
    status
)

ไม่จำเป็นต้อง Dump Player Data ทั้งก้อนออก Console

㉑ วิธีดู Data Type จริง

ใช้:

SHOW CREATE TABLE `players`;

แล้วตรวจ:

ENUM?
INT?
DECIMAL?
YEAR?
DATE?
VARCHAR?

อย่าอ้างจากไฟล์ install.sql เพียงอย่างเดียว เพราะ Production Database อาจไม่ได้ถูก Migration ตาม Resource Version ปัจจุบัน

㉒ ตรวจ Column แบบเร็ว

สามารถใช้:

SHOW COLUMNS FROM `players`;

เพื่อดู:

Field
Type
Null
Key
Default
Extra

จากนั้นหาว่า Column ที่ Error ระบุเป็น Type อะไร

㉓ SQL_MODE เกี่ยวข้องอย่างไร

MariaDB ระบุว่าเมื่อไม่ได้เปิด Strict Mode ระบบสามารถปรับ Invalid Values บางประเภท เช่นการตัด String หรือปรับค่าตัวเลข และสร้าง Warning แทน ขณะที่ Strict Mode ทำให้ Statements ที่มี Invalid Data ล้มเหลวได้มากขึ้น.

ดังนั้น Server สองเครื่องที่ใช้ Schema เดียวกันอาจแสดงผลต่างกันหาก:

SQL_MODE

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

㉔ วิธีดู SQL_MODE

ใช้:

SELECT @@sql_mode;

หรือ:

SELECT @@SESSION.sql_mode;

จากนั้นเปรียบเทียบระหว่าง Server เดิมกับ Server ใหม่หาก Error เริ่มหลังย้ายเครื่อง

㉕ อย่าปิด Strict Mode เพื่อให้ Error หาย

นี่เป็นวิธีที่ควรหลีกเลี่ยง

ถ้าค่า:

active

ไม่อยู่ใน ENUM

การทำให้ Database ยอมแปลงค่าหรือใช้ Default/Empty Representation อาจทำให้ข้อมูลที่ถูกบันทึก ไม่ใช่ข้อมูลที่ Resource ตั้งใจ

MariaDB ระบุว่า Non-strict Mode สามารถปรับ Invalid Values และสร้าง Warning ได้.

ดังนั้น:

Error ชัดเจน

มักดีกว่า:

Query ผ่าน
แต่ข้อมูลผิด

㉖ ENUM ผิดแล้วถูกเก็บเป็นอะไร

Behavior ต้องดู SQL Mode และ Context ที่ใช้งาน แต่ MariaDB แสดงตัวอย่างชัดว่า Invalid ENUM Value สามารถก่อให้เกิด 1265.

ดังนั้นไม่ควรพึ่งว่าค่าที่ไม่ถูกต้องจะถูกแปลงเป็นค่าที่ Application ต้องการโดยอัตโนมัติ

Resource ต้อง Validate ก่อน Query

㉗ Server-side Validation สำคัญ

ถ้า Column:

ENUM('online','offline')

Server ควรมี Allowed Values:

local allowed = {
    online = true,
    offline = true
}

if not allowed[status] then
    return
end

ก่อนส่ง SQL

ไม่ควรปล่อย Client ส่ง String ใดก็ได้ลง Database

㉘ Client ไม่ควรกำหนด ENUM ตรงๆ

ถ้า Client ส่ง:

status = "admin"

Server ไม่ควร:

UPDATE database

ทันที

ต้อง Validate:

Value ถูกไหม?
ผู้เล่นมีสิทธิ์ไหม?
Transition ถูกต้องไหม?

Database Constraint เป็น Safety Layer ไม่ใช่ Authorization Layer

㉙ ENUM หรือ Lookup Table แบบไหนดี

ไม่มีคำตอบเดียว

ENUM เหมาะเมื่อ:

Allowed Values มีชุดเล็ก
เปลี่ยนไม่บ่อย

ส่วน Lookup Table อาจเหมาะเมื่อ:

Values เปลี่ยนบ่อย
มี Metadata เพิ่ม
ต้อง Reference จากหลาย Tables

Error 1265 จึงอาจเป็นโอกาสให้ตรวจ Data Model ไม่ใช่เพียงเพิ่ม ENUM Value ทุกครั้ง

㉚ Resource Update เพิ่ม ENUM Value

สมมติ Resource ใหม่เพิ่ม:

pending

แต่ Database:

ENUM(
    'active',
    'inactive'
)

ยังไม่มี pending

ถ้า Official Migration ระบุ:

ALTER TABLE ...

ให้ใช้ Migration นั้นตาม Version

อย่าแก้ Resource ให้กลับไปส่งค่าเก่าเพียงเพื่อหลีกเลี่ยง Migration ถ้า Data Model ใหม่ต้องใช้ค่าใหม่จริง

㉛ Migration ไม่ครบเป็นสาเหตุหลักอีกครั้ง

Pattern ที่พบได้บ่อย:

Update Resource Files
↓
Restart FiveM
↓
ไม่ Import Migration SQL
↓
Resource ส่ง Data Format ใหม่
↓
Database Schema เก่า
↓
1265

ดังนั้นเมื่อ Error เริ่ม “ทันทีหลัง Update” ควรตรวจ Migration ก่อนแก้ Code

㉜ Restore Database จาก Backup เก่า

สมมติ Backup ใช้:

ENUM v1

แต่ Resource Files ปัจจุบันเป็น:

v3

หลัง Restore:

Resource ใหม่
+
Database เก่า

Error 1265 สามารถเริ่มเกิดแม้ก่อน Backup Server จะทำงานปกติ

ต้อง Restore Data พร้อม Migration ให้ Schema กลับมาตรง Version ปัจจุบัน

㉝ ย้าย Hosting แล้วเกิด 1265

ตรวจ:

MariaDB Version
SQL_MODE
Character Set
Collation
Schema
Resource Version

อย่าตรวจแค่:

Database connection สำเร็จไหม

เพราะ 1265 แปลว่า Queryผ่านมาถึง Data Processing แล้ว

㉞ Import CSV ก็ทำ 1265 ได้

หาก Data Import มี Field ที่ไม่ตรง Column Type เช่น:

YEAR column
← Full Date String

หรือ:

ENUM
← Value ที่ไม่มี

การ Import สามารถสร้าง Data Truncation Warnings/Errors ได้ตาม Data Conversion

ดังนั้น CSV Import ควร Validate ก่อน Production

㉟ DATE กับ DATETIME ต้องแยก

ถ้าข้อมูลต้องเก็บ:

2026-08-13

ใช้ Data Type ที่สอดคล้องกับ Date

ถ้าต้องเก็บ:

2026-08-13 19:15:00

ต้องดู Requirement ว่าใช้ DATETIME หรือ TIMESTAMP

อย่านำ Full Datetime String ไปเก็บใน YEAR เพียงเพราะต้องการปี เพราะ MariaDB แสดงตัวอย่างว่า Year Column กับ Full Date String สามารถสร้าง 1265 ได้.

㊱ String "10" กับ Number 10

Database สามารถมี Type Conversion Rules แต่ FiveM Resource ควรรักษา Type ให้ชัด

ถ้า Logic คาด:

level = number

ควรส่ง:

10

ไม่ใช่พึ่งให้ Database แปลง:

"10"

ทุกครั้ง

ยิ่ง Resource ใหญ่ การใช้ Type ที่สม่ำเสมอยิ่งช่วย Debug

㊲ Empty String กับ Numeric Column

ค่าประเภท:

""

ไม่ควรถูกใช้แทน:

0

หรือ:

NULL

โดยไม่มี Business Rule

ถ้า Column เป็น Numeric แต่ Form/Client ส่ง Empty String ให้ Server Normalize Value ก่อน Query

㊳ NULL กับ Empty String ต่างกัน

NULL

หมายถึงไม่มีค่าในเชิง SQL

ส่วน:

''

คือ String ที่มีความยาวศูนย์

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

ดังนั้น Resource ที่ Convert:

nil
→ ''

ทุกกรณีอาจสร้าง Data Type Problems เมื่อ Column เป็น Numeric/Date/Enum

㊴ Default Value ควรตรง Type

ถ้า Column:

`level` INT NOT NULL DEFAULT 0

Application ควรใช้:

0

ตาม Business Rule

ไม่ใช่:

''

เพียงเพื่อหลีกเลี่ยง NULL

การมี Schema Default ที่ถูกต้องช่วยลดการส่ง Invalid Representations

㊵ DECIMAL ต้องระวัง Rounding

MariaDB Documentation แสดงว่าค่า Fraction สามารถถูกปรับให้เข้ากับ Scale และสร้าง 1265 Notes/Warnings ได้ในบางกรณี.

ถ้าระบบต้องการสองตำแหน่ง:

12.345

ต้องกำหนด Application Policy เช่น:

12.35

อย่างชัดเจน

ไม่ควรให้ผลลัพธ์ทาง Gameplay ขึ้นอยู่กับ Database Conversion โดยไม่ตั้งใจ

㊶ อย่าใช้ FLOAT เพื่อหนี DECIMAL Error แบบสุ่ม

DECIMAL และ Floating-point Types มี Semantics คนละแบบ

ถ้าข้อมูลต้องการ Exact Decimal Representation ควรออกแบบ Precision/Scale ให้พอ

ไม่ควรเปลี่ยน Type เพียงเพื่อให้ Warning หายโดยไม่เข้าใจ Accuracy Requirement

㊷ Error 1265 ตอน ALTER TABLE

1265 สามารถเกิดระหว่าง Schema Modification ได้ด้วยเมื่อ Existing Data ไม่สามารถเข้ากับ Definition ใหม่ได้

MariaDB มีตัวอย่าง ALTER TABLE ที่พบข้อมูลไม่สอดคล้องแล้วเกิด Error 1265.

ดังนั้น Error ไม่ได้จำกัดเฉพาะ:

INSERT
UPDATE

เท่านั้น

㊸ ตัวอย่าง ALTER ที่เสี่ยง

สมมติเดิม:

`status` VARCHAR(20)

มีข้อมูล:

active
inactive
pending
unknown

แล้วเปลี่ยนเป็น:

ENUM(
    'active',
    'inactive'
)

Rows ที่เป็น:

pending
unknown

ไม่เข้ากับ Definition ใหม่

ดังนั้นก่อน ALTER ต้องตรวจ Existing Data

㊹ ตรวจค่าที่มีอยู่ก่อน ALTER ENUM

ใช้:

SELECT
    `status`,
    COUNT(*) AS `total`
FROM `players`
GROUP BY `status`
ORDER BY `total` DESC;

จะเห็นว่ามี Values อะไรจริง

จากนั้นเทียบกับ ENUM ใหม่

อย่า ALTER Production ก่อนรู้ Existing Values

㊺ ตรวจ DECIMAL ก่อนเปลี่ยน Scale

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

DECIMAL(10,4)

เป็น:

DECIMAL(10,2)

ควรตรวจว่าข้อมูลเดิมใช้:

4 decimal places

จริงมากแค่ไหน

เพราะการลด Scale สามารถเปลี่ยนค่าที่มีอยู่

㊻ Backup ก่อน Schema Conversion

การเปลี่ยน:

VARCHAR → ENUM
DECIMAL Scale
DATE Type
Numeric Type

เป็น Schema Migration

ก่อนทำ:

Backup
Test Copy
Migration
Verify

โดยเฉพาะ Table ที่มี Player Data จริง

㊼ ไม่ควรใช้ IGNORE เพื่อซ่อน Data Problem

MariaDB IGNORE สามารถเปลี่ยน Error หลายประเภทเป็น Warnings รวมถึง 1265 WARN_DATA_TRUNCATED.

ดังนั้น:

INSERT IGNORE ...

อาจทำให้ Query ดูเหมือนผ่าน

แต่ไม่ได้หมายความว่า Value ถูกเก็บตามที่ Resource ตั้งใจ

㊽ INSERT IGNORE อาจอันตรายกับ Gameplay State

สมมติ Resource ตั้ง:

status = pending

แต่ Database ENUM ไม่รองรับ

ถ้าบังคับให้ Queryผ่านด้วย Ignore:

Database State

อาจไม่ตรงกับ:

Runtime State

จากนั้น Player Reconnect แล้วโหลดค่ากลับ อาจได้ State ต่างจากก่อน Disconnect

ดังนั้นแก้ Schema/Data Contract ให้ตรงดีกว่า

㊾ Transaction ช่วยไหม

MySQL.transaction ของ oxmysql จะ Execute หลาย Queries และ Commit เฉพาะเมื่อทั้งหมดสำเร็จ หากหนึ่ง Query Fail จะไม่ Commitทั้งชุด.

จึงช่วยกรณี:

Query A สำเร็จ
Query B เกิด Data Truncated Error

ไม่ให้ Workflow เหลือข้อมูลครึ่งชุด

แต่ Transaction ไม่สามารถแก้ Type Mismatch ให้เอง

㊿ ตัวอย่าง Transaction

local success = MySQL.transaction.await({
    {
        query = [[
            UPDATE `characters`
            SET `status` = ?
            WHERE `id` = ?
        ]],
        values = {
            status,
            characterId
        }
    },
    {
        query = [[
            UPDATE `character_settings`
            SET `level` = ?
            WHERE `character_id` = ?
        ]],
        values = {
            level,
            characterId
        }
    }
})

ถ้า status ไม่อยู่ใน ENUM และ Query ล้มเหลว Transaction จะไม่ถูก Commit ทั้งชุดตามพฤติกรรมของ oxmysql.

51. Transaction ไม่ใช่ Validation

ยังต้องตรวจ:

status ถูก ENUM หรือไม่?
level เป็น Number หรือไม่?
date Format ถูกหรือไม่?

ก่อน Transaction

Transaction มีหน้าที่:

Atomicity

ไม่ใช่:

แก้ Invalid Input

52. วิธีหา Resource ต้นเหตุ

ใช้ลำดับ:

Error Timestamp
↓
Column
↓
oxmysql Debug
↓
Resource
↓
Query
↓
Parameter
↓
Source Code

oxmysql ระบุว่า Real Query Speeds จะแสดงใน Debug UI และ Server Console เมื่อเปิด mysql_debug.

53. Error เกิดเฉพาะ Player คนเดียว

ให้สงสัยข้อมูลเฉพาะ Record ก่อน

ตัวอย่าง:

Player A
status = online

Player B
status = offline

Player C
status = unknown_value

มีเพียง Player C Error

กรณีนี้อาจเป็น Legacy Data หรือ Resource เคยบันทึกค่าเก่าที่ Schema ใหม่ไม่รองรับ

อย่า ALTER ทั้ง Table ทันที

54. Error เกิดกับทุก Player

หากหลัง Update แล้วทุก Player ขึ้น:

Data truncated for column 'status'

มีเหตุผลสูงขึ้นที่จะตรวจ:

Migration
ENUM Definition
Resource Version
Parameter Mapping

ก่อน

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

Framework เดิมอาจใช้:

job_type:
police
ambulance
civilian

Framework ใหม่ใช้:

leo
ems
civ

Custom Table ที่เป็น ENUM ตาม Framework เดิมจะไม่เข้าใจ Values ใหม่

ต้อง Migration Data Model ไม่ใช่เพียงเปลี่ยน Resource Folder

56. Error หลัง Import Backup

ตรวจว่า:

Backup Data Version

ตรงกับ:

Current Table Schema

หรือไม่

Restore Data รุ่นเก่าลง Schema รุ่นใหม่ หรือกลับกัน สามารถสร้าง Conversion Problems ได้

57. Error หลังย้าย MariaDB Server

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

SELECT VERSION();
SELECT @@sql_mode;

รวมถึง:

SHOW CREATE TABLE `table_name`;

ระหว่าง Server เก่ากับใหม่

เพราะ SQL Mode มีผลต่อการจัดการ Invalid Values.

58. Error 1265 หลังเปลี่ยน SQL_MODE

ถ้าเดิม Non-strict:

Invalid Value
→ Warning / Adjust

แต่หลังย้าย Server กลายเป็น Strict:

Invalid Value
→ Statement Fail

อาจทำให้ Bug ที่มีมานานเพิ่งเริ่มปรากฏ

นี่ไม่ได้หมายความว่า Strict Mode เป็นปัญหาเสมอไป แต่อาจเป็น Strict Mode ช่วยเปิดเผยข้อมูลที่ Resource ส่งผิดมาตลอด

59. วิธีแก้ที่ดีกว่าปิด Strict Mode

ทำ:

① หา Invalid Value
② แก้ Resource
③ แก้ Migration
④ แก้ Existing Data
⑤ Verify Schema

แทน:

ปิด Strict Mode

เพื่อซ่อน Error

60. Error 1265 กับ Error 1292

MariaDB แยก 1265 WARN_DATA_TRUNCATED ออกจาก 1292 ER_TRUNCATED_WRONG_VALUE ซึ่งใช้ข้อความลักษณะ Truncated incorrect ... value.

ดังนั้นถ้า Error จริงเป็น:

1292

อย่าอ้างว่าเป็น 1265

ต้องอ่าน Code และข้อความเต็ม

61. Error 1265 กับ Error 1366

MariaDB IGNORE Documentation ยังแยก 1366 Incorrect ... value for column ออกจาก 1265 Data truncated.

Database Conversion Errors มีหลาย Code

จึงควรเก็บ:

Error Code
SQLSTATE
Message
Table
Column
Value

ครบ

62. อย่าแก้จากคำว่า "truncated" อย่างเดียว

คำว่า:

truncated

อาจพบในหลาย Context

เช่น:

1265 Data truncated
1292 Truncated incorrect value

ต้องใช้ Error Code เป็นตัวแยก Root Cause

63. วิธีแก้แบบ 5 นาที

เมื่อ FiveM Console ขึ้น:

Data truncated for column 'status'

ทำตามนี้:

  1. ยืนยันว่า Error คือ 1265
  2. จด Table และ Column
  3. ดู Query
  4. ดู Parameter จริง
  5. SHOW CREATE TABLE
  6. ตรวจว่า Column เป็น ENUM, DECIMAL, YEAR, Numeric หรือ Type อื่น
  7. ตรวจ Value ว่าตรง Type หรือไม่
  8. ตรวจ Parameter Order
  9. ตรวจ Resource Version
  10. ตรวจ Migration
  11. ตรวจ SQL_MODE
  12. แก้ Root Cause
  13. ทดสอบ Record เดิมอีกครั้ง

64. ตัวอย่าง Debug ENUM

Error:

Data truncated for column 'status'

Schema:

`status`
ENUM(
    'online',
    'offline'
)

Resource ส่ง:

away

ตรวจ Official Migration พบ Version ใหม่ควรเป็น:

ENUM(
    'online',
    'offline',
    'away'
)

กรณีนี้:

Resource = ใหม่
Schema = เก่า

จึง Migration ตาม Version

65. ตัวอย่าง Parameter Mapping ผิด

Schema:

status = ENUM
level = INT

Resource ต้องการ:

status = online
level = 50

แต่ส่ง:

status = 50
level = online

กรณีนี้:

อย่า ALTER ENUM
อย่าเปลี่ยน INT เป็น VARCHAR

ให้แก้ Parameter Order

66. ตัวอย่าง YEAR

Schema:

`model_year` YEAR

Resource ส่ง:

2026-08-13

MariaDB Documentation แสดงตัวอย่าง Full Date String ลง YEAR แล้วเกิด 1265.

แก้โดยส่ง:

2026

ถ้า Requirement คือปี

หรือเปลี่ยน Data Model เป็น DATE ถ้าต้องเก็บวันจริง

67. ตัวอย่าง DECIMAL

Schema:

`rating` DECIMAL(5,2)

Resource ส่งค่าที่มี Fraction มากกว่าที่ Column ต้องการ

MariaDB สามารถสร้าง 1265 Notes/Warnings เมื่อ Fraction ถูกปรับให้ตรง Scale.

Application ควรมี Precision Policy ที่ชัดเจน

68. Checklist FiveM Error 1265

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

  1. Error Code เป็น 1265 หรือไม่
  2. SQLSTATE เป็น 01000 หรือไม่
  3. Table ไหน
  4. Column ไหน
  5. Resource ไหน
  6. Query อะไร
  7. Parameter อะไร
  8. Lua Type คืออะไร
  9. Value จริงคืออะไร
  10. Column Data Type คืออะไร
  11. ENUM หรือไม่
  12. Value อยู่ใน ENUM หรือไม่
  13. DECIMAL หรือไม่
  14. Precision/Scale ถูกหรือไม่
  15. YEAR/DATE/DATETIME หรือไม่
  16. Format ถูกหรือไม่
  17. Numeric Column รับ String หรือไม่
  18. Parameter Order ถูกหรือไม่
  19. Existing Data มีค่า Legacy หรือไม่
  20. Resource Version คืออะไร
  21. Schema Version คืออะไร
  22. Migration ครบหรือไม่
  23. SQL_MODE คืออะไร
  24. Server เดิมกับใหม่ต่างกันหรือไม่
  25. Error เริ่มหลัง Update หรือไม่
  26. Error เริ่มหลัง Restore หรือไม่
  27. Error เกิดทุกคนหรือคนเดียว
  28. Client Input ถูก Validate หรือไม่
  29. Server Validate Type หรือไม่
  30. มี INSERT IGNORE ซ่อน Warning หรือไม่
  31. Transaction ใช้หรือไม่
  32. Backup ก่อน Migration แล้วหรือไม่
  33. Test Database มีหรือไม่
  34. Verify หลังแก้แล้วหรือไม่

ตาราง Error ที่มักสับสน

Errorความหมายหลัก
1264ตัวเลขอยู่นอก Range
1265Data ถูก Truncate/Convert ไม่สมบูรณ์
1292Truncated Incorrect Value
1366Incorrect Value for Column
1406Data ยาวเกิน Column
1062Duplicate Entry
1452Foreign Key Child ไม่มี Parent

MariaDB แยกรหัสเหล่านี้เป็น Errors/Warnings คนละชนิด จึงควรแก้ตาม Error Code จริง.

FiveM Data Truncated for Column แก้อย่างไร

เริ่มจาก:

SHOW CREATE TABLE `table_name`;

แล้วดู Column ที่ Error ระบุ

จากนั้นจับ Query/Parameters ของ Resource และเปรียบเทียบ:

Value ที่ส่ง
vs
Data Type ที่รับ

ถ้าสองอย่างไม่ตรง ให้แก้ Resource หรือ Schema ตาม Data Model ที่ถูกต้อง

FiveM Error 1265 คืออะไร

MariaDB Error 1265 คือ:

WARN_DATA_TRUNCATED

พร้อม SQLSTATE:

01000

และข้อความ:

Data truncated for column

FiveM ENUM Data Truncated แก้อย่างไร

ตรวจ Allowed Values:

SHOW CREATE TABLE `table_name`;

แล้วหา:

ENUM(...)

จากนั้นดูค่าที่ Resource ส่ง

MariaDB มีตัวอย่างตรงที่ค่าไม่อยู่ใน ENUM แล้วเกิด Error 1265.

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

ตรวจ:

Resource Version
↓
Migration SQL
↓
Current Schema

โดยเฉพาะ ENUM หรือ Data Types ที่ Script Version ใหม่เปลี่ยนไป

อย่าลดความเข้มของ Database Settings ก่อนตรวจ Migration

FiveM Data Truncated หลังย้าย VPS แก้อย่างไร

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

SELECT VERSION();
SELECT @@sql_mode;
SHOW CREATE TABLE `table_name`;

ระหว่างเครื่องเก่ากับใหม่

SQL Mode สามารถเปลี่ยนวิธีที่ MariaDB จัดการ Invalid Values.

FiveM Data Truncated เกิดจาก oxmysql ไหม

โดยทั่วไป Error 1265 คือ MariaDB แจ้งปัญหาการเก็บหรือแปลงค่าตาม Column Type ส่วน oxmysql เป็นตัวส่ง Queries และ Parameters

จึงควรตรวจ:

Resource Value
+
Parameter Mapping
+
Database Schema

ก่อน

FiveM ใช้ mysql_debug ตรวจได้ไหม

ได้ oxmysql ระบุว่า Query Timing/Debug สามารถดูผ่าน Debug UI และ Server Console เมื่อเปิด mysql_debug.

ใช้จับ Resource และ Query ที่ Error เกิด

FiveM ใช้ INSERT IGNORE แก้ 1265 ได้ไหม

ไม่ควรใช้เป็นวิธีแก้ Root Cause

MariaDB ระบุว่า IGNORE สามารถเปลี่ยน Error หลายชนิด รวมถึง 1265 ให้กลายเป็น Warning.

นั่นทำให้ Query ผ่านได้บางกรณี แต่ไม่ได้รับประกันว่าข้อมูลถูกเก็บตามที่ Application ต้องการ

FiveM ปิด Strict Mode ช่วยไหม

อาจเปลี่ยน Behavior จาก Error ไปเป็น Warning/การปรับ Invalid Values ในบางกรณี แต่ไม่ได้แก้ Resource หรือ Schema ที่ไม่ตรงกัน.

จึงควรแก้ต้นเหตุแทน

FAQ FiveM MariaDB Data Truncated

Error 1265 คืออะไร?

คือ MariaDB WARN_DATA_TRUNCATED เมื่อข้อมูลไม่สามารถเก็บใน Column ได้ตรงรูปแบบโดยสมบูรณ์.

Error 1265 กับ 1264 เหมือนกันไหม?

ไม่ 1264 คือ Out of Range ส่วน 1265 คือ Data Truncated.

Error 1265 กับ 1406 เหมือนกันไหม?

ไม่ 1406 เน้น Data Too Long ส่วน 1265 สามารถเกิดจาก Type Conversion หรือค่า ENUM/DECIMAL/Year ที่ไม่ตรง

ENUM ทำ Error 1265 ได้ไหม?

ได้ MariaDB มีตัวอย่าง Invalid ENUM Value ที่เกิด Error 1265 โดยตรง.

DECIMAL ทำ Error 1265 ได้ไหม?

ได้ MariaDB แสดงตัวอย่าง Fractional Values ที่เกิด 1265 เมื่อมีการปรับค่าตาม Scale.

YEAR ทำ Error 1265 ได้ไหม?

ได้ เช่นการส่ง Full Date String ไปยัง YEAR Column ตามตัวอย่างใน MariaDB Documentation.

Error เกิดจาก Parameter สลับได้ไหม?

ได้ หาก Resource ส่ง Value ผิด Column Database อาจพยายาม Convert ค่าคนละประเภทและเกิด Error/Warning

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

ไม่ควรเป็นขั้นตอนแรก เพราะ Non-strict Mode สามารถปรับ Invalid Values และสร้าง Warningแทน ซึ่งอาจซ่อนข้อมูลที่ไม่ถูกต้อง.

INSERT IGNORE ช่วยไหม?

สามารถทำให้ Error บางประเภทกลายเป็น Warning แต่ไม่ใช่การแก้ Data Contract.

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

ช่วยป้องกัน Workflow หลาย Queries ถูก Commit ครึ่งชุด หากหนึ่ง Query Fail แต่ไม่ได้แก้ Invalid Value เอง.

Error หลัง Update Script ควรตรวจอะไร?

ตรวจ Resource Version, Migration SQL และ Schema ปัจจุบันก่อน โดยเฉพาะ Column ที่เป็น ENUM หรือ Numeric/Date Types

Error เกิดเฉพาะ Player คนเดียวควร ALTER Table ไหม?

ไม่ควรรีบทำ ให้ตรวจข้อมูล Record และ Value ของ Player นั้นก่อน เพราะอาจเป็น Legacy/Corrupt Data เฉพาะราย

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

เมื่อ FiveM ขึ้น:

Data truncated for column

ให้ใช้สูตร:

1265
↓
ดู Column
↓
ดู Value
↓
ดู Data Type
↓
ตรวจ ENUM / DECIMAL / DATE / YEAR
↓
ตรวจ Parameter Order
↓
ตรวจ Schema Version
↓
ตรวจ SQL_MODE
↓
แก้ Root Cause

MariaDB กำหนด Error 1265 เป็น WARN_DATA_TRUNCATED และมีตัวอย่างชัดว่าปัญหาสามารถเกิดกับ Invalid ENUM Values, Decimal Precision และข้อมูลที่ไม่ตรงกับ YEAR Type ได้.

อย่าแก้ด้วย INSERT IGNORE หรือปิด Strict Mode เพียงเพื่อให้ Console เงียบ เพราะ MariaDB สามารถเปลี่ยน Invalid Data จาก Error ให้เป็น Warning/Adjusted Value ได้ ซึ่งอาจทำให้ค่าที่ Database เก็บไม่ตรงกับ State ที่ FiveM Resource คิดว่าบันทึกสำเร็จ.

สำหรับผู้อ่าน comsiam ให้จำสูตร “1265 = ตรวจชนิดข้อมูล ไม่ใช่เพิ่มขนาด Column ก่อน” และ comsiam แนะนำให้จับข้อมูล 4 อย่างให้ครบทุกครั้งคือ Resource + Query + Parameter + Column Type เพราะเมื่อเห็นทั้งสี่อย่าง ปัญหา Data Truncated ส่วนใหญ่จะระบุ Root Cause ได้ตรงกว่าการเปลี่ยน Database Configuration แบบลองผิดลองถูก

Comments

Popular posts from this blog

FiveM ยังน่าเล่นไหม? Enhanced เปลี่ยน FiveM แค่ไหน

FiveM คืออะไร เล่นอย่างไร สำหรับมือใหม่ เริ่มต้นตั้งแต่ศูนย์

วิธีตั้ง Admin Permission ด้วย add_ace และ add_principal FiveM แบบละเอียด