FiveM MariaDB Incorrect Value for Column แก้อย่างไร? วิธีแก้ Error 1366 เมื่อชนิดข้อมูลไม่ตรงกับ Column

August 13, 2026

FiveM MariaDB Error 1366 Incorrect value for column เกิดเมื่อ MariaDB ได้รับค่าที่ไม่สามารถตีความหรือแปลงให้ตรงกับ Data Type ของ Column ได้อย่างถูกต้อง เช่น Resource ส่งข้อความ "abc" ลง INT, ส่ง Empty String ลง Numeric Column หรือส่งค่ารูปแบบใหม่ลง Database Schema รุ่นเก่า MariaDB กำหนด Error นี้เป็น 1366, ชื่อ ER_TRUNCATED_WRONG_VALUE_FOR_FIELD และข้อความมีรูปแบบ Incorrect ... value ... for column ... at row ....

ตัวอย่างที่ FiveM Server อาจพบ:


Incorrect integer value: '' for column 'level' at row 1
Incorrect integer value: 'abc' for column 'player_id' at row 1
Incorrect value for column 'status' at row 1

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


Error 1366
↓
ดู Column ที่ Error
↓
ดูค่าที่ Resource ส่งจริง
↓
ดู Data Type
↓
ตรวจ Parameter Order
↓
ตรวจ nil / Empty String
↓
ตรวจ Resource Version กับ Database Schema
↓
ตรวจ SQL_MODE
↓
แก้ต้นเหตุ

ไม่ควรเริ่มจากการเปลี่ยนทุก Numeric Column เป็น VARCHAR หรือปิด Strict SQL Mode เพราะอาจทำให้ข้อมูลผิดประเภทถูกบันทึกลง Database แทนที่จะหยุด Resource ที่ส่งค่าผิด

① Error 1366 คืออะไร

MariaDB ระบุ Error 1366 ว่า:


ER_TRUNCATED_WRONG_VALUE_FOR_FIELD

พร้อมรูปแบบข้อความ:


Incorrect %s value: '%s'
for column '%s' at row %ld

และอธิบายว่าเกี่ยวข้องกับค่าที่ไม่ถูกต้องระหว่างการ Parsing/Conversion ให้เป็นชนิดข้อมูลของ Column.

ดังนั้น Error นี้มักหมายถึง:


SQL Syntax ผ่าน
↓
Table มีอยู่
↓
Column มีอยู่
↓
แต่ Value ไม่เหมาะกับ Column Type

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

สมมติ Table:


CREATE TABLE `players` (
    `level` INT NOT NULL
);

Resource ส่ง:


INSERT INTO `players`
    (`level`)
VALUES
    ('abc');

Database ต้องพยายามแปลง:


"abc"
↓
INTEGER

แต่ค่า "abc" ไม่ใช่ Integer ที่ถูกต้อง จึงสามารถเกิด Incorrect Integer Value ได้ตาม Type Conversion และ SQL Mode ที่ใช้งาน. MariaDB แนะนำว่าไม่ควรพึ่ง Implicit Type Conversion เมื่อสามารถกำหนดชนิดข้อมูลให้ชัดเจนได้.

③ Error ที่พบบ่อยมาก: Empty String ลง INT

ตัวอย่าง:


`level` INT NOT NULL

แต่ Resource ส่ง:

''

หรือ Empty String

FiveM Script อาจมี Logic เช่น:


local level = data.level or ''

หาก:


data.level = nil

จะกลายเป็น:


level = ''

แล้วถูกส่งลง Numeric Column

นี่เป็น Pattern ที่ควรตรวจทันทีเมื่อเห็น:


Incorrect integer value: ''

④ nil ไม่ควรถูกเปลี่ยนเป็น '' ทุกกรณี

Lua Developer บางคนใช้:


local value = input or ''

กับทุก Field

แต่ถ้า Column เป็น:


INT
BIGINT
DECIMAL
DATE

Empty String อาจไม่ใช่ค่าที่ถูกต้องสำหรับ Data Type นั้น

ต้องแยกตามความหมายจริง เช่น:


ไม่มี level
→ NULL ?
→ 0 ?
→ Reject Operation ?

ขึ้นกับ Business Rule และ Schema

⑤ NULL กับ Empty String ไม่เหมือนกัน

ใน SQL:


NULL

หมายถึงไม่มีค่า

แต่:

''

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

MariaDB แยก NULL ออกจากค่าของ Data Type ปกติ และ Column ที่กำหนด NOT NULL มีข้อจำกัดของตัวเอง.

ดังนั้น:


nil → ''

ไม่ควรถูกใช้เป็น Conversion Strategy แบบครอบจักรวาลใน FiveM Resource

⑥ สาเหตุหลักของ Error 1366 ใน FiveM

ตรวจ 10 จุดนี้ก่อน:


① String ถูกส่งลง INT/BIGINT
② Empty String ถูกส่งลง Numeric Column
③ Parameter Order สลับกัน
④ Resource ส่งค่ารูปแบบใหม่
⑤ Database Schema ยังเก่า
⑥ Column ถูกแก้ Data Type ผิด
⑦ Client ส่งค่าชนิดผิด
⑧ Lua Variable ถูก Convert ผิด
⑨ Import/Restore Schema คนละ Version
⑩ SQL_MODE เปลี่ยนหลังย้าย Server

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

ตัวอย่าง Query:


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

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


Parameter 1
= level

Parameter 2
= status

Resource กลับส่ง:


Parameter 1
= "online"

Parameter 2
= 50

Database จึงได้รับ:


level = "online"

แล้วอาจเกิด:


Incorrect integer value

⑧ อย่าแก้ INT เป็น VARCHAR ก่อนตรวจ Parameter

ถ้า:


level

ควรเป็นตัวเลขจริง

แต่ Database ได้:


online

การเปลี่ยน:

INT

เป็น:


VARCHAR(255)

จะทำให้ Query ผ่าน

แต่ Database จะกลายเป็น:


level = online

ซึ่งผิด Data Model หนักกว่า Error เดิม

Error 1366 จึงเป็นสัญญาณที่ช่วยจับ Resource Bug ได้ดี

⑨ oxmysql Placeholder ต้องจับคู่ Value ให้ถูก

oxmysql รองรับ ? สำหรับ Value Placeholder ใน Prepared Queries และ Parameters ต้องถูกส่งให้ตรงกับตำแหน่งที่ SQL คาดหวัง.

ตัวอย่าง:


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

หาก Query มี 3 Placeholders:


VALUES (?, ?, ?)

Values ต้องถูก Mapping ให้ถูกทั้ง:


จำนวน
ลำดับ
ชนิดข้อมูล

⑩ วิธีดู Data Type จริงของ Column

ใช้:


SHOW CREATE TABLE `players`;

แล้วหา Column ที่ Error ระบุ

ตัวอย่าง:


`player_id` BIGINT NOT NULL,
`level` INT NOT NULL DEFAULT 1,
`status` VARCHAR(20) NOT NULL

SHOW CREATE TABLE ใช้ดู Definition จริงของ Table ปัจจุบัน จึงมีประโยชน์กว่าการดูเพียง install.sql ที่อาจเป็นคนละ Version กับ Production Database.

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

สมมติ Resource ปัจจุบันมี:


`player_id` VARCHAR(80)

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


`player_id` INT

Resource ส่ง:


license:abc123...

ลง INT

ก็เกิด Incorrect Integer Value

ดังนั้น Pattern ที่ควรตรวจคือ:


Resource Schema ใหม่
+
Database Schema เก่า

⑫ Error หลัง Update Script ต้องสงสัย Migration ก่อน

ถ้าก่อน Update ใช้งานได้ปกติ แต่หลัง Update เริ่มขึ้น:


Incorrect value for column

ตรวจ:


① Release SQL
② Migration SQL
③ Current SHOW CREATE TABLE
④ Resource Version
⑤ Framework Version

ก่อนแก้ Code

Resource อาจเปลี่ยน Identifier จาก:

เป็น:


license:xxxxx

แต่ Database Column ยังคงเป็น Integer

⑬ Identifier เป็นสาเหตุยอดนิยม

FiveM Resources สามารถมี Identifier หลายรูปแบบ เช่น Internal Numeric ID หรือ String Identifier

ปัญหาเกิดเมื่อ Developer สมมติว่า:


identifier
=
integer เสมอ

ทั้งที่ Script รุ่นใหม่ส่ง:


license:...

ถ้า Column เป็น:

INT

ย่อมไม่เหมาะกับ String Identifier

ต้องตรวจ Official Data Model ของ Framework/Resource ที่ใช้งานจริงก่อนเปลี่ยน Schema

⑭ Internal ID กับ Player Identifier ต้องแยก

ตัวอย่าง:


players.id
= 150

แต่:


players.identifier
= license:abcd...

สองอย่างนี้เป็นคนละ Data Concept

ไม่ควรเอา:


identifier

ไป Insert ลง:

id

เพียงเพราะ Variable Naming ไม่ชัด

⑮ Lua type() ช่วย Debug ได้

ก่อน Query สามารถตรวจ:


print(type(playerId), playerId)

หรือ:


print(type(level), level)

ถ้าคาดว่า:


number

แต่ได้:


string

ก็เจอเบาะแสทันที

ตัวอย่าง:


expected:
number 50

actual:
string "50"

แม้ String Numeric บางกรณี MariaDBสามารถ Convert ได้ แต่ Application ควรรักษา Type Contract ให้ชัดเจนแทนการพึ่ง Implicit Conversion.

⑯ tonumber() ใช้ได้ไหม

ถ้า Input ตาม Business Rule ต้องเป็น Number จริง สามารถ Convert/Validate ใน Lua ก่อน Query เช่น:


local level = tonumber(input)

if not level then
    return
end

แต่ต้องระวัง:


tonumber("abc")
→ nil

ไม่ควรทำต่อ:


level = tonumber(input) or 0

โดยอัตโนมัติ ถ้า 0 มีความหมายแตกต่างจาก Invalid Input

⑰ อย่าเปลี่ยน Invalid Input เป็น 0 แบบสุ่ม

สมมติ:


character_id

ควรเป็น:

แต่ได้รับ:

abc

ถ้า Resourceทำ:


local id = tonumber(value) or 0

Databaseอาจรับ:


character_id = 0

Query จึงไม่ Error 1366 แล้ว

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


Invalid ID
Foreign Key Error
Record หาไม่เจอ

แทน

ควร Reject Invalid Input มากกว่าแปลงทุกอย่างเป็นศูนย์

⑱ Server ต้อง Validate Client Input

ถ้า Client ส่ง:


amount
level
playerId
slot

Server ควรตรวจ:


ชนิดข้อมูล
ช่วงค่า
สิทธิ์
ความสัมพันธ์กับ Player

ก่อน Query

อย่าพึ่ง MariaDB เป็น Layer แรกที่รู้ว่า:


amount = "hello"

ไม่ถูกต้อง

⑲ Client ส่ง Number เป็น String ได้

ข้อมูลจาก UI, JSON หรือ Event บาง Flow อาจกลายเป็น:


"25"

แทน:

Resource ควร Normalize Type ใน Server Logic ให้ตรงกับ Data Model ก่อนส่ง Database

MariaDB มี Implicit Type Conversion แต่เอกสารแนะนำว่าไม่ควรพึ่ง Conversion โดยนัยเมื่อสามารถใช้ Type ที่ชัดเจนได้.

⑳ Strict SQL Mode เกี่ยวอย่างไร

MariaDB มี SQL_MODE สำหรับควบคุมพฤติกรรม SQL หลายส่วน และ Strict Modes เช่น STRICT_TRANS_TABLES หรือ STRICT_ALL_TABLES สามารถทำให้ Invalid Conversions ถูกปฏิเสธเป็น Error แทนการปล่อยผ่าน.

จึงมีกรณี:


Server เก่า
→ Warning

Server ใหม่
→ Error 1366

แม้ Resource Code เหมือนกัน

㉑ วิธีดู SQL_MODE

ใช้:


SELECT @@sql_mode;

หรือ:


SELECT @@SESSION.sql_mode;

MariaDB Documentation ระบุว่าสามารถตรวจ Global/Session SQL Mode ได้ และ SQL Mode เป็นตัวกำหนด Compatibility/Strictness หลายด้าน.

㉒ ย้าย VPS แล้ว Error 1366

ถ้าหลังย้าย Server เริ่มเกิด Error ให้เปรียบเทียบ:


MariaDB Version
SQL_MODE
Schema
Resource Version

ระหว่างเครื่องเก่าและเครื่องใหม่

อย่าสรุปว่า:


VPS ใหม่มีปัญหา

เพียงเพราะ Error เริ่มหลังย้าย

อาจเป็น Database Configuration ที่เข้มกว่าเดิมและเปิดเผย Resource Bug ที่มีอยู่แล้ว

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

ไม่ควรเป็นทางแก้แรก

MariaDB แสดงว่าภายใต้ Strict SQL Mode การแปลงค่าคนละประเภทสามารถสร้าง Error 1366 ได้.

หากปิด Strict Mode คุณอาจเปลี่ยน:


Invalid Value
→ Error

ให้กลายเป็น:


Invalid Value
→ Conversion/Warning

แต่ Data Contract ระหว่าง Resource กับ Database ยังผิดอยู่

㉔ Error ชัดๆ ดีกว่าข้อมูลเสียเงียบๆ

ตัวอย่าง:


player_id
ควร = 500

แต่ Resource ส่ง:


license:abc

หาก Databaseหยุดด้วย Error 1366:


รู้ทันทีว่าผิด

ดีกว่าปล่อยให้ค่าถูกแปลงเป็นค่าอื่นแล้ว Resource ทำงานต่อ

㉕ IGNORE ไม่ใช่คำตอบหลัก

MariaDB ระบุว่า IGNORE สามารถเปลี่ยน Error บางประเภท รวมถึง 1366 ให้เป็น Warning แทน.

ดังนั้น:


INSERT IGNORE ...

อาจทำให้ Console ไม่มี Error

แต่ไม่ได้หมายความว่าค่าถูกต้อง

㉖ อย่าใช้ INSERT IGNORE เพื่อปิด Error 1366

ตัวอย่าง:


level = "abc"

ถ้าทำ:


INSERT IGNORE

แล้ว Query ถูกปรับ/ปล่อยผ่านตาม Behavior ของ Database

FiveM Runtime อาจคิดว่า:


level = abc

แต่ Database เก็บ:


ค่าอื่น

เมื่อ Player Reconnect State จะไม่ตรงกัน

นี่เป็นปัญหาที่แก้ยากกว่า Error 1366 เดิม

㉗ CAST ช่วยได้ไหม

MariaDB รองรับ CAST() และ CONVERT() สำหรับ Explicit Type Conversion.

ตัวอย่าง:


CAST(? AS SIGNED)

แต่ไม่ควรใช้ CAST เพียงเพื่อบังคับ Invalid Input ให้กลายเป็น Number

เช่น:

abc

ไม่ได้ควรถูก Cast เป็น Player ID ตั้งแต่แรก

㉘ Explicit Conversion เหมาะเมื่อไร

เหมาะเมื่อ Data Contract ชัดว่า:


Input เป็น String Numeric
เช่น "123"

และต้องการแปลงเป็น Integerอย่างมีเจตนา

แต่หาก Input สามารถเป็น:


abc
license:...
''
nil

ควร Validateใน Application ก่อน

㉙ Error 1366 กับ Error 1265 ต่างกันอย่างไร

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


1265
Data truncated

ส่วน:


1366
Incorrect value for column

MariaDB แยกสอง Error Codes นี้ออกจากกัน โดย 1366 ใช้ข้อความ Incorrect ... value ... for column.

ทั้งสองเกี่ยวข้องกับ Data Conversion แต่ต้องอ่าน Code จริงก่อนวิเคราะห์

㉚ Error 1366 กับ Error 1264 ต่างกัน


1264
Out of Range

ตัวอย่าง:


TINYINT
แต่ส่ง 500

ส่วน:


1366
Incorrect Value

ตัวอย่าง:


INT
แต่ส่ง "abc"

หนึ่งคือ:


เลขถูกชนิด
แต่เกิน Range

อีกหนึ่งคือ:


ค่าไม่เหมาะกับ Type

㉛ Error 1366 กับ Error 1406 ต่างกัน


1406
Data too long

เช่น:


VARCHAR(20)
← String 500 ตัว

แต่:

มักเกี่ยวกับ Type Conversion เช่น:


INT
← "hello"

จึงไม่ควรเพิ่ม VARCHAR Size เพื่อแก้ 1366

㉜ Error 1366 กับ Error 1054


1054
Unknown column

หมายถึง Column ไม่มีหรือชื่อผิด

แต่ Error 1366 หมายถึง Column มีอยู่พอที่ MariaDB จะพยายามใส่ค่าลงไปแล้วพบว่า Value ไม่ถูกต้อง

ดังนั้น:

ไม่ต้องเริ่มจากสร้าง Column ใหม่

㉝ Error 1366 กับ Error 1064


1064
SQL Syntax Error

หมายถึง Query Parse ไม่ผ่าน

ส่วน 1366:


Syntax ผ่าน
↓
MariaDB เริ่มประมวลผล Value
↓
Value ไม่ตรง Type

เป็นคนละ Layer

㉞ Error 1366 กับ Foreign Key

Foreign Key Error เช่น 1452 หมายถึง Child Key ไม่มี Parent

1366 หมายถึง Value ไม่ถูกต้องสำหรับ Column

แต่สามารถต่อเนื่องกันได้ เช่น Developer แก้:


"abc"

เป็น:

เพื่อหนี 1366

แล้ว:

ไม่มี Parent Row

จึงเปลี่ยนไปเป็น Foreign Key Error

นี่คือเหตุผลที่ไม่ควรแปลง Invalid Values เป็นศูนย์แบบสุ่ม

㉟ Error 1366 กับ ENUM

Invalid ENUM มักสัมพันธ์กับ Data Conversion/Truncation Error อื่น เช่น 1265 ตาม MariaDB ENUM behavior.

ดังนั้นถ้าข้อความ Error เป็น:


Incorrect integer value

ให้เน้น Numeric Conversion ก่อน

ถ้าเป็น:


Data truncated for column

และ Column เป็น ENUM ให้ตรวจ Allowed Values

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

สมมติ Framework เก่าเก็บ:


player_id
=
1234

Framework ใหม่เก็บ:


player_id
=
license:abc...

แต่ Custom Script Table ยัง:


player_id INT

จึงเริ่มเกิด 1366 หลัง Migration Framework

ต้อง Update Data Model ของ Custom Scripts ด้วย

㊲ อย่าแก้เฉพาะ Table ที่ Console ฟ้องตัวแรก

ถ้า Framework เปลี่ยน Identifier Type:


INT
→ VARCHAR

อาจมี Tables หลายตัวอ้าง Identifier นี้ เช่น:


players
vehicles
profiles
settings
logs

หากแก้เพียง Table แรก Error อาจย้ายไป Table ต่อไป

ควรทำ Schema Inventory ทั้งระบบ

㊳ วิธีหา Columns ที่ใช้ชื่อเดียวกัน

สามารถค้น Metadata ของ Database เพื่อหา Columns เช่น:


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

จากนั้นดูว่า:


บาง Table = INT
บาง Table = VARCHAR

หรือไม่

นี่ช่วยตอน Framework Migration ได้มาก

㊴ AUTO_INCREMENT ไม่ควรรับ String Identifier

หาก Column:


id INT AUTO_INCREMENT

ควรเป็น Internal Numeric Key

อย่านำ:


license:...

ไปใส่ id

ควรมี Column แยก เช่น:


id
identifier

ตาม Data Model

㊵ String Numeric ควร Normalize

สมมติ Resource ได้:


"50"

จาก UI

แต่ Database level เป็น INT

Serverสามารถ:


local level = tonumber(value)

if not level then
    return
end

แล้วค่อย Query

ทำให้ Data Contract ชัดขึ้นและลดการพึ่ง MariaDB Implicit Conversion

MariaDB Documentation แนะนำไม่ให้พึ่ง Implicit Type Conversion เมื่อสามารถใช้ Explicit Conversion ได้.

㊶ Decimal String ก็ต้องตรวจ

หาก Column:

INT

แต่ Resource ส่ง:


"10.5"

ต้องถามว่า:


Field นี้ควรเป็น Integer จริงหรือไม่?

ถ้าใช่ ต้องกำหนดว่าจะ:


Reject
Round
Floor
Ceil

ที่ Application Layer

ไม่ควรปล่อย Database เลือก Conversion Behavior ให้ Gameplay Logic

㊷ Boolean ก็สร้าง Type Confusion ได้

FiveM/Lua อาจใช้:


true
false

แต่ Database Column อาจเก็บ:

0
1

oxmysql Documentation ระบุด้วยว่า TINYINT 1 และ BIT ไม่ได้ถูก Return เป็น Boolean โดยอัตโนมัติในบาง API Behavior ที่ dokumentation กล่าวถึง.

จึงควร Normalize:


true → 1
false → 0

หรือใช้ Convention ของ Framework ให้สม่ำเสมอ

㊸ อย่า Insert Lua Table ลง Scalar Column

ตัวอย่าง Resource:


local metadata = {
    level = 5,
    status = 'online'
}

แล้วนำ:


metadata

ไปใส่ Column:

INT

ย่อมผิด Data Model

ถ้าต้องเก็บ Structured Data ต้อง Serialize/Normalize ตาม Schema ที่ Resource ออกแบบไว้

㊹ Query Parameter ควรมี Schema Contract

ตัวอย่างที่อ่านง่าย:


local playerId = tonumber(data.playerId)
local level = tonumber(data.level)
local status = tostring(data.status)

if not playerId or not level then
    return
end

จากนั้นค่อย:


MySQL.update.await(...)

ช่วยให้ Resource รู้ Type ก่อน Databaseรู้

㊺ mysql_debug ช่วยอะไร

oxmysql ระบุว่า Query Speeds/Debug Information สามารถดูใน Server Console เมื่อเปิด mysql_debug และผ่าน Debug UI ตามการใช้งานที่รองรับ.

เมื่อเจอ 1366 ให้จับ:


Resource
Query
Timestamp
Column

แล้วกลับไปดู Parameters ใน Code

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

หาก 499 คน Save ได้ แต่ Player เดียว Error:


Incorrect integer value

ให้ตรวจ Record/Data Flow ของ Player นั้นก่อน

อาจมี:


Legacy Identifier
Corrupt JSON
Old Character Data
Bad Config Value

ไม่ควร ALTER Table ทั้ง Serverทันที

㊼ Error เกิดทุก Player หลัง Update

ถ้าเกิดพร้อมกันแทบทั้งหมด ให้สงสัย:


Schema Migration
Parameter Mapping
Framework API Change

ก่อน

โดยเฉพาะหาก Errorเริ่มหลัง Update Resource เพียงครั้งเดียว

㊽ Error เกิดหลัง Restart Resource

ตรวจ Initialization Logic เช่น:


onResourceStart
↓
Load Config
↓
Insert Settings

Config อาจอ่าน String:


"false"

แต่ Database Columnเป็น Numeric Flag

หรือ:


"none"

ถูกใส่ลง Numeric ID

㊾ Config Value ต้อง Validate เช่นกัน

แม้ Config ไม่ได้มาจาก Player ก็สามารถผิดได้

ตัวอย่าง:


Config.DefaultLevel = "new"

แต่ Column:

INT

Server Owner แก้ Config แล้ว Restart Resource ก็เกิด 1366

ดังนั้น Debug ต้องตรวจ:


Client Input
Resource Logic
Config
Database

ทั้งหมด

㊿ Transaction ช่วยไหม

oxmysql MySQL.transaction ใช้ Execute หลาย Queries และ Commit เมื่อ Queries ทั้งหมดสำเร็จตาม Transaction API.

ดังนั้นถ้า:


Query 1 สำเร็จ
Query 2 เจอ Error 1366

Transaction สามารถช่วยไม่ให้ Business Operation ถูก Commit ครึ่งชุด

แต่ Transaction ไม่สามารถเปลี่ยน:


"abc"

ให้เป็น Integer ที่ถูกต้อง

51. Transaction ไม่ใช่ Data Validation

ให้จำ:


Validation
→ ตรวจ Value

Transaction
→ จัด Atomicity

Constraint
→ ป้องกันข้อมูลผิดระดับ DB

ทั้งสามทำหน้าที่คนละอย่าง

ระบบที่ดีใช้ร่วมกัน

52. วิธี Debug Error 1366 แบบ 5 นาที

เมื่อ Console ขึ้น:


Incorrect integer value: ''
for column 'level'

ทำตามนี้:


① จด Table
② จด Column
③ จด Value ใน Error
④ SHOW CREATE TABLE
⑤ ยืนยันว่า Column เป็น INT/BIGINT หรือไม่
⑥ หา Resource Query
⑦ ดู Parameter ตรง Column
⑧ ตรวจ nil / ''
⑨ ตรวจ tonumber()
⑩ ตรวจ Parameter Order
⑪ ตรวจ Migration
⑫ ตรวจ SQL_MODE

ส่วนใหญ่จะเจอ Root Causeในลำดับนี้

53. ตัวอย่าง Debug จริง

Error:


Incorrect integer value:
'license:abc123'
for column 'player_id'

Schema:


player_id INT NOT NULL

Resource:


local playerId = GetPlayerIdentifier(source)

ค่า:


license:abc123

ตรงนี้เห็นชัดว่า:


Column ต้องการ Numeric Internal ID
แต่ Resource ส่ง String Identifier

ไม่ใช่ปัญหา INT Range และไม่ควรเปลี่ยนเป็น BIGINTเพื่อแก้

54. ตัวอย่าง Empty String

Schema:


`garage_id` INT NULL

Resource:


local garageId = data.garageId or ''

ถ้าไม่มี Garage:


garageId = ''

ทางแก้ต้องดู Data Model เช่น:


ไม่มี garage
→ NULL

อาจเหมาะกว่า Empty String หาก Schema/Logicออกแบบให้ Nullable

55. ตัวอย่าง Parameter สลับ

ต้องการ:


level = 10
status = online

แต่ Values:


{
    status,
    level
}

Databaseได้รับ:


level = online
status = 10

Error ที่เกิดขึ้นอาจเป็นเพียง Column แรกที่ Databaseตรวจพบ

หลังแก้ Column แรกแล้วอาจพบ Errorอีก Columnหนึ่ง

จึงควรตรวจ Mapping ทั้ง Query

56. ตัวอย่าง Resource Version ไม่ตรง

Resource v1:


player_id = integer

Resource v2:


player_id = UUID/string

แต่ Database:


Schema v1

หลัง Update Resource:


Incorrect integer value

นี่คือ Migration Problem

ควรใช้ Official Migration ของ Resource แทนเขียน ALTER แบบเดาเอง

57. วิธีแก้ Schema เมื่อยืนยันแล้วว่าต้องเปลี่ยน

ถ้า Official Schema ระบุว่า:


player_identifier

ควรเป็น:


VARCHAR(80)

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

INT

จึงค่อยทำ Schema Migration ตาม Definition ที่ Official Resource กำหนด

ก่อน Production Migration:


Backup
↓
ตรวจ Foreign Keys
↓
ตรวจ Index
↓
ตรวจ Existing Data
↓
Migration
↓
Verify

58. อย่าลืม Related Columns

ถ้า:


players.identifier

เปลี่ยนจาก Numeric เป็น String

แต่:


vehicles.owner
profiles.identifier
settings.owner

ยังเป็น INT

Server ก็ยังไม่สมบูรณ์

ต้อง Migration Columns ที่อ้าง Data Concept เดียวกันทั้งหมดตาม Official Schema

59. ตรวจหลังแก้ด้วย SHOW CREATE TABLE

หลัง Migration:


SHOW CREATE TABLE `players`;

และ Tables ที่เกี่ยวข้องอีกครั้ง

จากนั้น Test:


Player Join
Character Load
Save
Disconnect
Reconnect
Resource Restart

อย่าทดสอบเพียงว่า Query Error หาย

60. Checklist Error 1366 สำหรับ FiveM

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

Error Code เป็น 1366 หรือไม่
ข้อความบอก Incorrect Type อะไร
Table ไหน
Column ไหน
Value อะไร
Data Type Column คืออะไร
Value เป็น Lua Type อะไร
Empty String หรือไม่
nil ถูกแปลงเป็น '' หรือไม่
String Numeric หรือไม่
String Non-numeric หรือไม่
Parameter Order ถูกหรือไม่
จำนวน Parameters ถูกหรือไม่
Resource ไหน Query
Config มีค่าผิด Type หรือไม่
Client Input ถูก Validate หรือไม่
Server Validate Type หรือไม่
tonumber() ใช้ถูกหรือไม่
มี fallback or 0 แบบอันตรายหรือไม่
Resource Version อะไร
Database Schema Version อะไร
Migration ครบหรือไม่
Framework เปลี่ยน Identifier Type หรือไม่
Restore Database เก่าหรือไม่
SQL_MODE ต่างจากเครื่องเดิมหรือไม่
Strict Mode เปิดหรือไม่
มี INSERT IGNORE ซ่อน Error หรือไม่
Column Related Tables ถูก Migrationครบหรือไม่
Foreign Keys ตรง Type หรือไม่
Backup ก่อน ALTER แล้วหรือไม่
Test Player เดิมแล้วหรือไม่
Test Player ใหม่แล้วหรือไม่
Test Resource Restart แล้วหรือไม่
Monitor Error หลังแก้แล้วหรือไม่

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

Error	ความหมายหลัก
`1054`	Unknown Column
`1064`	SQL Syntax Error
`1062`	Duplicate Entry
`1264`	Out of Range
`1265`	Data Truncated
`1366`	Incorrect Value for Column
`1406`	Data Too Long
`1452`	Foreign Key Constraint Fail

MariaDB กำหนด 1366 แยกเป็น ER_TRUNCATED_WRONG_VALUE_FOR_FIELD จึงควรเริ่มจากชนิดข้อมูลและค่าที่ถูกส่ง ไม่ใช่แก้ Errorทั้งหมดด้วย Schema Change รูปแบบเดียว.

FiveM Incorrect Integer Value แก้อย่างไร

ถ้า Error เป็น:


Incorrect integer value: ''

ให้ตรวจว่า Resourceกำลังส่ง:

''

ลง:


INT / BIGINT

หรือไม่

จากนั้นแก้ Application Logic ให้ส่ง:


ตัวเลขที่ถูกต้อง
NULL เมื่อ Schema อนุญาต
หรือ Reject Operation

ตาม Business Rule

FiveM Error 1366 คืออะไร

MariaDB Error 1366 คือ:


ER_TRUNCATED_WRONG_VALUE_FOR_FIELD

และใช้ข้อความลักษณะ:


Incorrect ... value ...
for column ...
at row ...

FiveM Incorrect Integer Value '' แก้อย่างไร

ตรวจ:


nil → '' conversion

ก่อน

โดยเฉพาะ Code:


local id = data.id or ''

ถ้า Column เป็น INT อาจควรใช้ Validation:


local id = tonumber(data.id)

if not id then
    return
end

แทน

FiveM String ลง INT ได้ไหม

MariaDB มี Implicit Type Conversion ในหลาย Context แต่เอกสารแนะนำไม่ให้พึ่ง Conversion โดยนัยและควรใช้ Explicit Type Handling เมื่อเป็นไปได้.

สำหรับ FiveM Server ควร Convert/Validate ก่อน Query เพราะช่วยควบคุม Gameplay Logicได้ชัดกว่า

FiveM เปลี่ยน INT เป็น VARCHAR เพื่อแก้ได้ไหม

ทำได้เฉพาะเมื่อ Data Model จริงกำหนดว่า Field นั้นควรเป็น String เช่น Identifier แบบข้อความ

ถ้า Field ควรเป็น Numeric เช่น:


level
quantity
internal id

ไม่ควรเปลี่ยน Type เพียงเพื่อรับค่าที่ Resource ส่งผิด

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

ตรวจ:


Resource Version
Migration SQL
SHOW CREATE TABLE
Identifier Format
Parameter Mapping

ก่อน

ถ้า Resource เปลี่ยน Data Type Requirement แต่ Database ยังไม่ Migration ให้แก้ Schema ตาม Official Version

FiveM Error 1366 หลังย้าย VPS แก้อย่างไร

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


SELECT VERSION();
SELECT @@sql_mode;

และ:


SHOW CREATE TABLE `table_name`;

SQL Mode มีผลต่อความเข้มงวดของ Invalid Data Handling ใน MariaDB.

FiveM Error 1366 เกิดจาก oxmysql ไหม

Error 1366 เป็น Error ที่ MariaDB คืนเมื่อค่าที่กำลังประมวลผลไม่ถูกต้องสำหรับ Column ส่วน oxmysql เป็น Layer ที่ส่ง Queries และ Parameters จาก FXServer

ดังนั้นควรตรวจ:


Resource Logic
↓
Parameter
↓
Schema

ก่อนกล่าวว่า oxmysql มีปัญหา

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

ได้ oxmysql ระบุว่า Real Query Speeds และ Debug Information สามารถดูใน Server Console ด้วย mysql_debug และ Debug UI ตาม Environment ที่เหมาะสม.

ใช้เพื่อหา Resource/Query ที่เกิด Error แล้วตรวจ Parameters ใน Code

FiveM ปิด Strict Mode เพื่อแก้ Error 1366 ดีไหม

ไม่ควรเป็นขั้นตอนแรก

MariaDB ระบุว่าภายใต้ Strict SQL Mode การคืนค่าชนิดไม่ตรงตามที่กำหนดสามารถทำให้เกิด 1366 ได้.

ควรแก้ Resource/Data Contract ก่อน เพราะการลด Strictness อาจเปลี่ยน Error เป็น Warning แต่ไม่ทำให้ Value ถูกต้องขึ้น

FiveM INSERT IGNORE แก้ Error 1366 ได้ไหม

MariaDB ระบุว่า IGNORE สามารถเปลี่ยน Error 1366 เป็น Warning ในบาง Context.

แต่ไม่ควรใช้เป็น Root-cause Fix เพราะ Database อาจเก็บค่าที่ไม่ตรงกับสิ่งที่ FiveM Resource คาดหวัง

FAQ FiveM MariaDB Error 1366

Error 1366 คืออะไร?

คือ MariaDB ER_TRUNCATED_WRONG_VALUE_FOR_FIELD เมื่อค่าที่กำลังใช้ไม่ถูกต้องสำหรับ Column.

Incorrect integer value หมายถึงอะไร?

หมายถึง MariaDB ได้รับค่าที่ไม่สามารถใช้เป็น Integer ของ Column ได้อย่างถูกต้อง เช่น String ที่ไม่ใช่ตัวเลข

Empty String ลง INT ได้ไหม?

ไม่ควรใช้ Empty String เป็นตัวแทนของ Integer ที่ไม่มีค่า ควรเลือก Number, NULL หรือ Reject Input ตาม Schema/Business Rule

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

ได้ ถ้า String ถูกส่งไปยัง Numeric Column เพราะ Values อยู่ผิดลำดับ

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

ไม่ MariaDB แยก 1366 เป็น Incorrect Value และ 1265 เป็น Data Truncated.

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

ไม่ 1264 มักเป็นค่าตัวเลขเกิน Range ส่วน 1366 คือ Value ไม่ถูกต้องสำหรับ Type

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

ได้เฉพาะเมื่อ Data Model ระบุจริงว่าค่าควรเป็น String ไม่ควรทำเพียงเพื่อปิด Error

ใช้ tonumber() ช่วยได้ไหม?

ช่วย Validate Numeric Input ได้ แต่ต้องจัดการกรณี Conversion ล้มเหลวอย่างถูกต้อง ไม่ควรใช้ or 0 ทุกกรณี

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

Strict Mode อาจทำให้ Invalid Conversion ถูกแสดงเป็น Error แทนการยอมรับแบบผ่อนปรน จึงอาจทำให้ Bug ที่มีอยู่แล้วปรากฏชัดขึ้น.

INSERT IGNORE ควรใช้ไหม?

ไม่ควรใช้เพื่อซ่อน Error เพราะ MariaDB สามารถเปลี่ยน 1366 เป็น Warning ได้โดยที่ Data Contract ยังผิดอยู่.

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

ตรวจ Resource Version, Database Migration, Current Column Type และ Parameter Mapping ก่อน

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

ไม่ควรรีบ ALTER ให้ตรวจ Value/Record ของ Player นั้นก่อน เพราะอาจเป็น Legacy หรือ Corrupt Data

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

เมื่อ FiveM ขึ้น:


Incorrect value for column

หรือ:


Incorrect integer value

ให้ใช้สูตร:


1366
↓
ดู Value ใน Error
↓
ดู Column
↓
SHOW CREATE TABLE
↓
ดู Type
↓
ดู Parameter
↓
ตรวจ nil / ''
↓
ตรวจ Parameter Order
↓
ตรวจ Resource Version
↓
ตรวจ Migration
↓
ตรวจ SQL_MODE

MariaDB กำหนด 1366 เป็น ER_TRUNCATED_WRONG_VALUE_FOR_FIELD ซึ่งชี้โดยตรงว่าค่าที่กำลังส่งไม่เหมาะกับ Field ที่ Database ต้องการ.

อย่าแก้ด้วยการเปลี่ยน Numeric Columns เป็น VARCHAR, ปิด Strict Mode หรือใส่ INSERT IGNORE ก่อนรู้ต้นเหตุ เพราะ MariaDB สามารถเปลี่ยน Invalid Data จาก Error ไปเป็น Warning ได้ แต่ข้อมูลที่ถูกบันทึกอาจไม่ตรงกับ State ที่ Resourceคิดว่าเก็บสำเร็จ.

สำหรับผู้อ่าน comsiam ให้จำสูตร “1366 = ดูค่าที่ Resource ส่งก่อนดูว่าจะขยาย Column หรือไม่” และ comsiam แนะนำให้ตรวจ 4 อย่างพร้อมกันคือ Value + Lua Type + SQL Parameter Position + Database Column Type เพราะ Error Incorrect Value จำนวนมากไม่ได้เกิดจาก MariaDB เสีย แต่เกิดจาก Resource ส่งค่าถูกช่องผิดช่องหรือ Database Schema ไม่ตรงกับ Script Version