FiveM MariaDB Incorrect Date/Datetime Value แก้อย่างไร? วิธีแก้ Error 1292 เมื่อวันเวลาไม่ตรง Format หรือ SQL Mode

August 13, 2026

FiveM MariaDB Error 1292 มักพบเมื่อ Resource พยายามบันทึกวันหรือเวลาที่ MariaDB ไม่สามารถตีความได้อย่างถูกต้อง เช่น วันที่ไม่มีจริง, รูปแบบ DD/MM/YYYY ถูกส่งลง DATE, String ว่างถูกส่งลง DATETIME, Timestamp ถูกใช้ผิดหน่วย หรือ Database Schema กับ Script คนละเวอร์ชัน

MariaDB กำหนด Error 1292, SQLSTATE 22007 และชื่อ ER_TRUNCATED_WRONG_VALUE โดยข้อความหลักคือ Truncated incorrect ... value.

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


Incorrect datetime value: '2026-13-45'
for column 'last_seen' at row 1

หรือ:


Truncated incorrect datetime value

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


Error 1292
↓
ดู Column
↓
ดูค่าที่ Resource ส่งจริง
↓
ดูว่าเป็น DATE / DATETIME / TIMESTAMP / YEAR
↓
ตรวจ Format
↓
ตรวจ Timestamp หน่วยวินาทีหรือมิลลิวินาที
↓
ตรวจ SQL_MODE
↓
ตรวจ Resource กับ Schema Version
↓
แก้ต้นเหตุ

① Error 1292 คืออะไร

MariaDB ระบุ:


Error Code: 1292
SQLSTATE: 22007
ER_TRUNCATED_WRONG_VALUE

โดย Database ได้รับค่าที่ไม่สามารถตีความเป็น Temporal/Numeric Value ตามรูปแบบที่ Statement หรือ Column ต้องการได้อย่างถูกต้อง.

กรณี FiveM ที่พบบ่อยคือ:


DATE
DATETIME
TIMESTAMP
YEAR

ได้รับค่าที่ Format ไม่ถูกต้อง

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

สมมติ Table:


CREATE TABLE `players` (
    `last_seen` DATETIME NOT NULL
);

แต่ Resource ส่ง:


13/08/2026 19:30

ขณะที่รูปแบบมาตรฐานที่ใช้กับ MariaDB DATETIME โดยทั่วไปคือ:


YYYY-MM-DD HH:MM:SS

เช่น:


2026-08-13 19:30:00

MariaDB ระบุว่า DATETIME ใช้สำหรับเก็บค่ารวมวันที่และเวลา และมีรูปแบบมาตรฐานตาม Temporal Data Type ของระบบ.

③ DATE ต่างจาก DATETIME อย่างไร

DATE

เก็บเฉพาะ:


YYYY-MM-DD

เช่น:


2026-08-13

MariaDB ระบุช่วงปกติของ DATE ตั้งแต่ปี 1000 ถึง 9999.

DATETIME

เก็บทั้ง:


YYYY-MM-DD HH:MM:SS

เช่น:


2026-08-13 19:30:00

ใช้เมื่อ FiveM Resource ต้องจำทั้งวันและเวลา.

④ TIMESTAMP ต่างจาก DATETIME อย่างไร

TIMESTAMP และ DATETIME ใช้เก็บวันเวลาได้ แต่มี Semantics และ Range ต่างกัน

MariaDB ระบุว่า TIMESTAMP ถูกเก็บบนพื้นฐานของ Epoch Seconds และมีข้อจำกัด Range ของตัวเอง ขณะที่ DATETIME เหมาะกว่าเมื่อจำเป็นต้องเก็บวันเวลาที่อยู่นอก Range ของ TIMESTAMP.

ดังนั้นอย่าเลือก:


TIMESTAMP

หรือ:


DATETIME

เพียงเพราะทั้งคู่ดูเหมือนวันเวลา

ให้ดู Requirement ของ Resource

⑤ FiveM มักใช้วันเวลาตรงไหน

ตัวอย่าง:


last_seen
created_at
updated_at
last_login
banned_until
expires_at
owned_since
last_save

ถ้า Script หนึ่งมอง Field เป็น:


Unix Timestamp

แต่อีก Script มองเป็น:


DATETIME String

ก็สามารถเกิด Data Conversion Error ได้

⑥ รูปแบบวันที่ผิดเป็นสาเหตุหลัก

ตัวอย่างที่ควรหลีกเลี่ยงเมื่อ Column ต้องการ SQL Date:


13/08/2026
08/13/2026
13-08-2026
August 13, 2026

รูปแบบที่ชัดกว่า:


2026-08-13

สำหรับ DATE

และ:


2026-08-13 19:30:00

สำหรับ DATETIME

การใช้ Format เดียวกันทั้ง Resource ช่วยลด Conversion Bugs

⑦ วันที่ไม่มีจริงก็ Error ได้

ตัวอย่าง:


2026-02-31

หรือ:


2026-13-01

ไม่ใช่วันที่ปกติที่ถูกต้อง

MariaDB มี SQL_MODE เช่น ALLOW_INVALID_DATES ซึ่งสามารถเปลี่ยนวิธีที่ Database จัดการวันที่บางประเภทได้ โดยเอกสารเตือนว่าการเก็บ Invalid Dates แล้วเปลี่ยน Mode ภายหลังอาจทำให้ผลลัพธ์ไม่แน่นอน.

ดังนั้นอย่าเปิด ALLOW_INVALID_DATES เพียงเพื่อให้ Resource ที่ส่งวันที่ผิดทำงานต่อ

⑧ ALLOW_INVALID_DATES คืออะไร

MariaDB ระบุว่า Mode:


ALLOW_INVALID_DATES

สามารถอนุญาตบางวันที่ซึ่งปกติถือว่าไม่ถูกต้อง ตราบใดที่ Day อยู่ในช่วงที่ Mode ยอมรับ.

ตัวอย่างเชิงแนวคิด:


2026-02-31

อาจได้รับการจัดการต่างจาก Configuration ปกติ

แต่สำหรับ FiveM Production ไม่ควรใช้ Mode นี้เพื่อซ่อน Resource Bug

⑨ Zero Date คืออะไร

MariaDB สามารถมี Special Date Value เช่น:


0000-00-00

หรือ:


0000-00-00 00:00:00

ขึ้นกับ SQL_MODE ที่ใช้อยู่ และ NO_ZERO_DATE สามารถเปลี่ยนการยอมรับค่าเหล่านี้ได้.

ดังนั้น Server ที่ย้าย Hosting แล้วเริ่ม Error อาจต้องตรวจว่า SQL Mode เครื่องใหม่เข้มกว่าเครื่องเดิมหรือไม่

⑩ อย่าใช้ 0000-00-00 แทน NULL แบบสุ่ม

หาก Field หมายถึง:


ยังไม่มีวันหมดอายุ

ควรถามว่า Data Model ควรใช้:


NULL

หรือไม่

MariaDB ระบุว่า NULL หมายถึง Unknown/Missing Value และไม่เหมือน Empty String หรือเลขศูนย์.

ดังนั้น:


NULL

กับ:


0000-00-00

ไม่ควรถูกมองว่าเป็นสิ่งเดียวกัน

⑪ Empty String ลง DATETIME ต้องระวัง

Code ลักษณะนี้:


local expiresAt = data.expiresAt or ''

ถ้า Column:


`expires_at` DATETIME

Resource อาจส่ง:

''

เข้าสู่ Temporal Column

วิธีที่เหมาะกว่าคือกำหนด Business Rule ให้ชัดว่า:


ไม่มีวันหมดอายุ
→ NULL

หรือ:


ต้องมีวันที่
→ Reject Operation

ไม่ใช่เปลี่ยน Missing Value ทุกชนิดเป็น Empty String

⑫ nil กับ NULL ต้องออกแบบให้ถูก

ถ้า Column อนุญาต:


NULL

และข้อมูลไม่มีจริง การเก็บ NULL มักสื่อความหมายชัดกว่าการสร้างวันที่ปลอม

MariaDB ระบุชัดว่า NULL ไม่เท่ากับ Empty String หรือ Zero Value.

⑬ Parameter Order สลับทำ Date Error ได้

ตัวอย่าง:


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

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


Parameter 1 = DATETIME
Parameter 2 = INT

Resource กลับส่ง:


Parameter 1 = 50
Parameter 2 = "2026-08-13 19:30:00"

Database อาจพยายามตีความ:


last_seen = 50

แล้วเกิด Temporal Conversion Error

จึงต้องตรวจ Parameter Order ก่อนแก้ Schema

⑭ oxmysql Placeholder ต้องตรงกับ Value

oxmysql รองรับ Parameter Placeholders เพื่อแยก Values ออกจาก SQL และ Documentation ปัจจุบันระบุการใช้ Parameters กับ Queries โดยตรง.

ตัวอย่าง:


MySQL.update.await(
    'UPDATE `players` SET `last_seen` = ? WHERE `id` = ?',
    {
        lastSeen,
        playerId
    }
)

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


SQL
Parameter Order
Parameter Value
Parameter Type

ไม่ใช่ดู SQL อย่างเดียว

⑮ ใช้ NOW() ได้เมื่อไร

หาก Requirement คือ:

เก็บเวลาที่ Database Execute Query

สามารถใช้ MariaDB:


NOW()

หรือ:


CURRENT_TIMESTAMP()

แทนการประกอบ String วันเวลาเองใน Lua

MariaDB ระบุว่า NOW() และ CURRENT_TIMESTAMP() คืนค่าจุดเวลาปัจจุบันสำหรับการใช้งานกับ Temporal Operations.

ตัวอย่าง:


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

⑯ NOW() ลด Format Bug ได้

แทน Resource ทำ:


local time =
    day .. '/' ..
    month .. '/' ..
    year

แล้วส่ง Database

สามารถให้ Databaseสร้าง Current Datetime เอง:


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

หาก Requirementคือ Database Current Time จริง

ช่วยตัดปัญหา Format ที่ Resourceสร้างผิดออกไปส่วนหนึ่ง

⑰ แต่ NOW() ไม่เหมาะกับทุกกรณี

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


เวลาที่ Event เกิดจริงจากระบบอื่น

หรือ:


วันหมดอายุที่คำนวณไว้ล่วงหน้า

ก็ยังต้องส่งค่าที่ถูกต้องเข้า Database

อย่าใช้ NOW() แทนทุก Temporal Field เพียงเพื่อให้ Error หาย

⑱ Unix Timestamp คืออะไร

บาง Resource ไม่ส่ง:


2026-08-13 19:30:00

แต่ส่ง Integer Epoch เช่น:

1786624200

ถ้า Column เป็น:


BIGINT

อาจตั้งใจเก็บ Epoch

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


DATETIME

ต้องมี Conversion Strategy ที่ชัดเจน

อย่าส่ง Numeric Epoch ลง DATETIME โดยหวังว่า Database จะเดาความหมายเอง

⑲ Unix Seconds กับ Milliseconds ต่างกันมหาศาล

ตัวอย่างเชิงแนวคิด:


Unix seconds
≈ 1,786,xxx,xxx

แต่ milliseconds:


≈ 1,786,xxx,xxx,xxx

ต่างกันประมาณ:


1,000 เท่า

ดังนั้น Resource ที่เปลี่ยน Library แล้วเริ่มส่ง Milliseconds แทน Seconds สามารถสร้าง Date/Range Problems ได้

⑳ FROM_UNIXTIME ใช้ทำอะไร

MariaDB มี:


FROM_UNIXTIME(...)

สำหรับแปลง Unix Timestamp เป็น Temporal Value

แต่ MariaDB ระบุว่า Timestamp Range มีข้อจำกัด และค่า Unix Timestamp ที่อยู่นอกช่วงรองรับสามารถคืน NULL.

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


Seconds หรือ milliseconds?

ก่อนใช้

ตัวอย่าง:


SELECT FROM_UNIXTIME(1786624200);

㉑ อย่าใส่ Milliseconds เข้า FROM_UNIXTIME โดยตรง

ถ้า Value เป็น:


1786624200000

แต่ Function คาด Unix Seconds ตาม Use Case ปกติ ค่าอาจเกิน Range อย่างรุนแรง

ต้อง Normalize:


milliseconds
÷ 1000
=
seconds

เมื่อ Data Contract ของระบบยืนยันว่า Input คือ Milliseconds จริง

㉒ STR_TO_DATE ใช้เมื่อไร

MariaDB มี:


STR_TO_DATE(string, format)

สำหรับ Parse String ตาม Format ที่กำหนด

เช่นใน Migration/Import ที่ต้องรับ String Formatเฉพาะ

MariaDB ระบุว่า Invalid Date String สามารถทำให้ STR_TO_DATE() คืน NULL พร้อม Warning และภายใต้ SQL Mode บางแบบอาจเกิด Error.

㉓ ตัวอย่าง STR_TO_DATE

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


13/08/2026

อาจ Parseตาม Format:


SELECT STR_TO_DATE(
    '13/08/2026',
    '%d/%m/%Y'
);

แต่สำหรับ Runtime Resource หากสามารถส่ง:


2026-08-13

ตรงตั้งแต่ต้น จะง่ายและปลอดภัยกว่าการ Parse Stringทุก Query

㉔ อย่าใช้ STR_TO_DATE ซ่อน Format ที่ไม่แน่นอน

ถ้า Client บางคนส่ง:


13/08/2026

บางคนส่ง:


08/13/2026

คุณไม่ควรเดาว่า:


ตัวแรกคือวันหรือตัวแรกคือเดือน?

กำหนด API Contract เดียว:


YYYY-MM-DD

จะลด Ambiguity มากกว่า

㉕ YEAR ต้องส่งให้ถูก Type

MariaDB YEAR แสดงผลแบบสี่หลัก และรองรับช่วงหลักตั้งแต่ 1901–2155 รวม Special Zero Value ตามกฎของ Type.

ถ้า Column:


`model_year` YEAR

ควรส่ง:

ไม่ใช่:


2026-08-13

㉖ สองหลักสำหรับ YEAR ไม่ควรใช้

MariaDB Documentation ระบุว่ารูปแบบปีสองหลักยังรองรับแต่มีความคลุมเครือและถูกมองว่า Error-prone.

ดังนั้น FiveM Resourceควรใช้:

แทน:

เพื่อลด Ambiguity

㉗ DATE Range ก็ต้องตรวจ

MariaDB DATE รองรับช่วงวันตาม Data Type ของมัน ไม่ใช่ทุกค่า String ที่ดูเหมือนวันจะใช้ได้.

ถ้า Script ส่ง:


99999-01-01

การเพิ่ม VARCHAR ไม่ใช่คำตอบถ้า Field นี้ควรเป็น Date จริง

㉘ TIMESTAMP Range ต้องระวัง

MariaDB Documentation ปัจจุบันระบุว่า TIMESTAMP อิง Epoch Seconds และมี Maximum ที่สัมพันธ์กับปี 2106 ในระบบที่รองรับ Range ดังกล่าว.

ถ้า FiveM Resource ต้องเก็บวันที่ไกลมาก เช่น:


9999-12-31

เป็น Sentinel “ไม่หมดอายุ”

TIMESTAMP อาจไม่ใช่ Type ที่เหมาะ

ควรออกแบบ:


DATETIME

หรือ:


NULL

ตาม Business Rule

㉙ อย่าใช้ปี 9999 แบบสุ่ม

ระบบ Ban หรือ Subscription บาง Script ใช้:


9999-12-31

หมายถึง:


ถาวร

แต่หาก Column เป็น TIMESTAMP จะต้องตรวจ Range ก่อน

ทางออกที่สะอาดกว่าอาจเป็น:


expires_at = NULL
permanent = 1

ตาม Data Model ที่ออกแบบไว้

ไม่ควรพึ่ง Magic Date โดยไม่จำเป็น

㉚ Time Zone ทำให้ 1292 ไหม

Time Zone Problems ไม่ใช่สาเหตุเดียวของ 1292 และไม่ควรสรุปทันทีว่า Error Date Format เกิดจาก Time Zone

แต่ TIMESTAMP มี Time-zone-related semantics ต่างจาก DATETIME และ MariaDB มีระบบ Time Zone ของ Database แยกต่างหาก.

ดังนั้นต้องแยก:


Format Error

ออกจาก:


Timezone Interpretation

ให้ชัด

㉛ DATETIME เหมาะกับ Local Wall-clock Time มากกว่าในบางกรณี

MariaDB แยก Semantics ของ DATETIME และ TIMESTAMP รวมถึง Temporal Functions ที่เกี่ยวกับ Current Time.

จึงควรเลือก Type ตามความหมาย เช่น:


เกิดเหตุการณ์ ณ จุดเวลาเดียวทั่วโลก

กับ:


เวลาปฏิทินที่ต้องการเก็บตรงตัว

ไม่ใช่ใช้ Type เดียวทุกระบบ

㉜ Error 1292 หลัง Update Script

ถ้าก่อน Update ใช้งานได้ แต่หลัง Updateเริ่ม Error ให้ตรวจ:


Resource Version
Migration
Date Format ใหม่
Timestamp Unit
Column Type

ตัวอย่าง:


v1
→ Unix seconds

v2
→ ISO datetime string

แต่ Database ยังใช้ Schema/Parsing Logic ของ v1

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

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


created_at = BIGINT

Framework ใหม่ใช้:


created_at = DATETIME

Custom Script ที่ยังส่ง Epoch Integer ตาม Data Model เดิมอาจไม่เข้ากับ Schemaใหม่

ต้อง Migrationทั้ง:


Schema
Data
Code

ไม่ใช่เพียงเปลี่ยน Resource Folder

㉞ Error 1292 หลัง Restore Backup

สมมติ Backup เก่าใช้:


0000-00-00

จำนวนมาก

แต่ Server ใหม่ใช้ SQL Mode ที่ไม่ยอมรับ Zero Date

หลัง Restore/Update อาจเริ่มเห็น Date Errors ได้

MariaDB ระบุว่า NO_ZERO_DATE, NO_ZERO_IN_DATE และ ALLOW_INVALID_DATES มีผลต่อ Temporal Values.

㉟ Error หลังย้าย VPS

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


SELECT VERSION();
SELECT @@sql_mode;

และ:


SHOW CREATE TABLE `table_name`;

จากนั้นเปรียบเทียบกับเครื่องเดิม

อย่าดูเพียง Connection String เพราะ Error 1292 แปลว่า Queryไปไกลถึงขั้น Databaseกำลังตีความ Value แล้ว

㊱ ตรวจ SQL_MODE

MariaDB มี SQL Modes ที่เกี่ยวข้องกับ Invalid/Zero Dates เช่น:


ALLOW_INVALID_DATES
NO_ZERO_DATE
NO_ZERO_IN_DATE

และ Mode เหล่านี้เปลี่ยนวิธีที่ MariaDBยอมรับ Temporal Values.

ดังนั้น:


SELECT @@sql_mode;

เป็น Query ที่ควรตรวจเมื่อ Server ใหม่มี Behavior ต่างจาก Server เดิม

㊲ ไม่ควรปิด Strictness เพื่อแก้ Script

ถ้า Resource ส่ง:


2026-99-99

สิ่งที่ควรแก้คือ:


Resource Date

ไม่ใช่พยายามปรับ Databaseให้รับวันที่ที่ผิด

Error Database ที่ชัดเจนช่วยป้องกัน Invalid Persistent State

㊳ mysql_debug ช่วยหา Query ได้

oxmysql มี Debug Tools โดย Query Speeds และข้อมูล Debug สามารถดูได้ผ่าน Server Console/Debug UI เมื่อเปิด mysql_debug.

เมื่อ Error 1292 เกิด ให้หา:


Resource
Query
Column
Parameter
Timestamp ของ Error

ให้ครบ

㊴ Log Date Value ก่อน Query

ตัวอย่าง:


print(
    'lastSeen:',
    lastSeen,
    'type:',
    type(lastSeen)
)

ถ้าเห็น:


lastSeen = 13/08/2026

แต่ Database ต้องการ DATETIME ก็ได้เบาะแสทันที

㊵ อย่า Debug จาก Error Message อย่างเดียว

เก็บอย่างน้อย:


① Error Code
② Table
③ Column
④ SQL
⑤ Parameter
⑥ Lua Type

เพราะ:


Incorrect datetime value

บอก Column ได้

แต่ไม่ได้บอกเสมอว่า Resourceสร้างค่านั้นมาจาก Functionไหน

㊶ ใช้ Current Database Time เมื่อเหมาะสม

สำหรับ Field เช่น:


created_at
updated_at
last_seen

หาก Requirementคือเวลาที่ Queryเกิด สามารถใช้:


NOW()

เช่น:


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

MariaDB รองรับ NOW()/CURRENT_TIMESTAMP() สำหรับ Current Temporal Values.

㊷ created_at ใช้ DEFAULT ได้ในบาง Design

แทนให้ Resource ส่ง Current Time เองทุกครั้ง Database Schema สามารถออกแบบให้ Default Timestamp/Datetime ตาม Requirement ได้

แต่ต้องใช้ตาม Official Schema ของ Resource ไม่ควร ALTER Production เพียงเพราะต้องการลด Code

㊸ updated_at ต้องวาง Strategy ให้ชัด

อาจเลือก:


Resource Update เวลาเอง

หรือ:


Database Update เวลา

ตาม Data Model

สิ่งสำคัญคืออย่าให้:


Resource A
ใช้ UTC String

แต่:


Resource B
ใช้ Local Date String แบบ DD/MM/YYYY

เขียน Column เดียวกัน

㊹ Date Parsing ควรอยู่จุดเดียว

ถ้าต้องรับ Dateจาก UI ให้ Normalize ที่ Server:


Client Format
↓
Server Validate
↓
Canonical Format
↓
Database

เช่นทุกค่ากลายเป็น:


YYYY-MM-DD

ก่อน SQL

ช่วยลด Resource แต่ละตัว Parse วันเวลาต่างกัน

㊺ Client ไม่ควรส่ง SQL Date โดยไม่มี Validation

Client สามารถส่ง:


hello
9999
31/31/2026

ได้

Server ต้องตรวจ:


Format
Range
Permission
Business Rule

ก่อน Database

Database Error เป็น Safety Layer ไม่ใช่ Frontend Validation

㊻ วันหมดอายุควรตรวจว่ามากกว่าวันเริ่มต้น

ถึง Date Format ถูก:


2026-08-01

ก็ไม่ได้แปลว่า Business Logic ถูก

ตัวอย่าง:


start_at
2026-08-13

expires_at
2026-08-01

Database อาจรับได้

แต่ Logic “หมดอายุก่อนเริ่ม” อาจไม่ถูก

จึงต้องมี Application Validation เพิ่ม

㊼ Error 1292 กับ Error 1366 ต่างกัน

บทความก่อน:


1366
Incorrect value for column

มักเจอกับ Type Mismatch เช่น String ลง Integer

ส่วน:


1292
Truncated incorrect value

พบได้กับ Temporal Parsing และ Conversion Context อื่นๆ. MariaDB แยก Error Codes สองตัวออกจากกัน.

㊽ Error 1292 กับ Error 1265


1265
Data truncated for column

และ:


1292
Truncated incorrect value

ข้อความคล้ายกัน แต่เป็นคนละ Error Code

จึงต้องอ่าน:


1265 หรือ 1292?

ก่อนแก้

㊾ Error 1292 กับ Error 1264

1264 คือ:


Out of range value

ส่วน 1292 เน้น:


Value ไม่สามารถตีความได้ถูกต้อง

ตัวอย่างเช่น Temporal String ผิด

อย่าเปลี่ยน INT เป็น BIGINT หาก Error จริงคือ Incorrect Datetime Value

㊿ Error 1292 กับ Error 1064


1064
SQL Syntax Error

หมายถึง Parser อ่าน SQL Structure ไม่ผ่าน

แต่:

มักหมายถึง SQL Structure ผ่านแล้ว แต่ Value ที่ถูกนำมาประมวลผลไม่ถูกต้อง

ดังนั้น:


comma
parenthesis

ไม่ใช่จุดแรกที่ควรตรวจเมื่อ Error ระบุ Datetime Value ชัดเจน

51. Transaction ช่วยไหม

ถ้า Operation มีหลาย Queries และ Query หนึ่งเกิด Error Date/Datetime ควรให้ Transaction Rollbackทั้ง Business Operation เมื่อทุก Queryจำเป็นต้องสำเร็จพร้อมกัน

แต่ Transaction ไม่สามารถแก้:


2026-13-99

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

Validation ยังต้องทำก่อน SQL

52. SQL Migration ต้องตรวจ Existing Dates

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


VARCHAR
→ DATE

หรือ:


BIGINT
→ DATETIME

ต้องตรวจ Existing Values ก่อน

เพราะข้อมูลเก่าอาจมี:


''
N/A
never
0000-00-00

ซึ่งไม่สามารถ Convertเป็น Dateแบบใหม่ได้ตรงๆ

53. อย่า ALTER VARCHAR เป็น DATE ทันที

สมมติ Column เดิมเก็บ:


2026-08-13
13/08/2026
never
NULL

ปนกัน

ก่อนเปลี่ยนเป็น DATE ต้อง:


Profile Existing Values
Normalize
Backup
Migration
Verify

ไม่อย่างนั้น Migrationเองอาจ Error

54. วิธีหา Format ที่มีอยู่

ตัวอย่าง:


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

ใช้บน Test/Backup เพื่อดู Data Shape ก่อน Migration

หาก Table ใหญ่ควรวาง Query ตาม Performance ที่เหมาะสม

55. Permanent Ban ควรเก็บยังไง

มีหลาย Data Model ที่ถูกต้อง เช่น:


expires_at = NULL
permanent = 1

หรือโครงสร้างอื่นที่ Framework กำหนด

สิ่งที่ควรหลีกเลี่ยงคือใช้:


9999-99-99

เป็น Magic Date ที่ไม่ถูกต้อง

56. Temporary Ban ควรใช้ Type ไหน

ขึ้นกับ Framework

ถ้าใช้ Absolute Datetime:


banned_until DATETIME

ถ้าใช้ Epoch:


banned_until BIGINT

ก็ได้ตาม Architecture

แต่ Code และ Databaseต้องใช้ Model เดียวกัน

อย่าให้ Resourceหนึ่งเขียน Epoch อีก Resourceตีความเป็น DATETIME

57. Date String ควรเป็น Canonical Format

แนะนำเชิง Architecture:


DATE
YYYY-MM-DD

DATETIME
YYYY-MM-DD HH:MM:SS

เพื่อให้ Code อ่านง่ายและไม่กำกวม

ส่วนการแสดงผู้ใช้เป็น:


13/08/2026

สามารถ Format ตอน UI Layer

อย่าใช้ Display Format เป็น Database Contract โดยไม่จำเป็น

58. UI Format กับ Database Format คนละเรื่อง

ผู้เล่นไทยอาจเห็น:


13/08/2026

แต่ Databaseสามารถเก็บ:


2026-08-13

Resourceทำ Conversion ตอน Display

วิธีนี้ช่วยไม่ให้:


DD/MM

กับ:


MM/DD

สับสนใน Database

59. วิธีแก้ Error 1292 แบบ 5 นาที

เมื่อ Console ขึ้น:


Incorrect datetime value

ทำตามนี้:

ยืนยัน Error Code 1292
จด Table
จด Column
จด Value ที่ Error แสดง
SHOW CREATE TABLE
ตรวจ DATE/DATETIME/TIMESTAMP/YEAR
ตรวจ Date Format
ตรวจว่า Date มีจริงหรือไม่
ตรวจ Empty String
ตรวจ Zero Date
ตรวจ Parameter Order
ตรวจ Unix Seconds/Milliseconds
ตรวจ Resource Version
ตรวจ Migration
ตรวจ @@sql_mode
แก้ต้นเหตุ
ทดสอบ Flow เดิม

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

Error:


Incorrect datetime value:
'13/08/2026 19:30'
for column 'last_seen'

Schema:


`last_seen` DATETIME

Resource:


local lastSeen = os.date('%d/%m/%Y %H:%M')

ตรงนี้ Format ที่ Resourceสร้างไม่ใช่ Canonical DATETIME String ที่ Database Logic ตั้งใจใช้

แก้ให้ Resourceส่ง Format ที่ชัดเจน หรือใช้ NOW() ถ้า Requirementคือ Current Database Time.

61. ตัวอย่าง Timestamp Milliseconds

Resource ส่ง:


1786624200000

แต่ Code คิดว่าเป็น Unix Seconds

หากนำไปใช้กับ:


FROM_UNIXTIME(?)

โดยตรง Value อาจอยู่นอก Range ที่รองรับ

MariaDB ระบุว่า FROM_UNIXTIME() มีข้อจำกัดตาม TIMESTAMP Range.

ต้องตรวจ Unit ก่อน Conversion

62. ตัวอย่าง Zero Date

Resourceส่ง:


0000-00-00

Server เดิมรับ

Server ใหม่ Error

ตรวจ:


SELECT @@sql_mode;

เพราะ MariaDB ระบุว่า NO_ZERO_DATE และ Mode ที่เกี่ยวข้องมีผลกับ Zero Date Behavior.

อย่าปิด Modeก่อนตรวจว่า Resourceควรใช้ NULL แทนหรือไม่

63. ตัวอย่างวันที่ไม่มีจริง

Resourceส่ง:


2026-02-31

แทนที่จะเปิด:


ALLOW_INVALID_DATES

ให้แก้ Date Validation

MariaDB ระบุว่า ALLOW_INVALID_DATES สามารถอนุญาต Invalid Calendar Dates บางชนิด แต่ยังเตือนถึงผลของการเปลี่ยน Modeกับข้อมูลที่เก็บไว้.

64. Checklist Error 1292 สำหรับ FiveM

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

Error Code เป็น 1292 หรือไม่
SQLSTATE เป็น 22007 หรือไม่
Table ไหน
Column ไหน
Value อะไร
Resource ไหน
Query อะไร
Parameter ไหน
Column เป็น DATE หรือไม่
DATETIME หรือไม่
TIMESTAMP หรือไม่
YEAR หรือไม่
Value Format คืออะไร
มีวัน/เดือนสลับหรือไม่
Date มีจริงหรือไม่
Empty String หรือไม่
Zero Date หรือไม่
NULL เหมาะกว่าหรือไม่
Unix Timestamp หรือไม่
Seconds หรือ Milliseconds
Parameter Order ถูกหรือไม่
Lua Type คืออะไร
Resource Version ตรงไหม
Schema Version ตรงไหม
Migration ครบไหม
SQL_MODE คืออะไร
NO_ZERO_DATE มีไหม
NO_ZERO_IN_DATE มีไหม
ALLOW_INVALID_DATES มีไหม
Server เพิ่งย้าย VPS หรือไม่
Backup มาจาก Schema เก่าหรือไม่
Existing Date Data สะอาดหรือไม่
Client Input Validate แล้วหรือไม่
Server Normalize Date หรือไม่
Test Flow หลังแก้แล้วหรือไม่

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

เริ่มจากดู Column:


SHOW CREATE TABLE `table_name`;

จากนั้นเปรียบเทียบ:


Value ที่ Resource ส่ง
กับ
Temporal Type ที่ Database ต้องการ

MariaDB Error 1292 ระบุว่า Value ที่ได้รับไม่สามารถตีความอย่างถูกต้องตาม Type/Operation นั้น.

FiveM Error 1292 คืออะไร

คือ MariaDB:


ER_TRUNCATED_WRONG_VALUE

SQLSTATE:

และข้อความหลัก:


Truncated incorrect ... value

FiveM Incorrect Date Value หลัง Update Script แก้อย่างไร

ตรวจ:


Resource Version
Migration
DATE/DATETIME Column
Value Format
Timestamp Unit

หาก Resource Format เปลี่ยน แต่ Schema/Code อื่นยังใช้ Format เดิม ต้อง Migration Data Contract ให้ตรงกัน

FiveM Incorrect Datetime หลังย้าย VPS แก้อย่างไร

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


SELECT VERSION();
SELECT @@sql_mode;

และ:


SHOW CREATE TABLE `table_name`;

โดยเฉพาะ SQL Modes ที่เกี่ยวข้องกับ Invalid/Zero Dates.

FiveM 0000-00-00 Error แก้อย่างไร

ตรวจ SQL_MODE ก่อน

หาก Applicationใช้ Zero Dateแทน “ไม่มีวัน” ให้พิจารณาว่า Data Model ควรเปลี่ยนเป็น:


NULL

หรือ Representation อื่นที่ชัดเจนหรือไม่

MariaDB ระบุว่า NULL ไม่เหมือน Zero Value หรือ Empty String.

FiveM DATE ควรใช้ Format อะไร

รูปแบบ Canonical ที่ควรใช้กับ DATE คือ:


YYYY-MM-DD

เช่น:


2026-08-13

MariaDB DATE Documentation ระบุ Date Representation และ Range ของ Type นี้.

FiveM DATETIME ควรใช้ Format อะไร

รูปแบบทั่วไป:


YYYY-MM-DD HH:MM:SS

เช่น:


2026-08-13 19:30:00

MariaDB มี DATETIME สำหรับ Date+Time Values.

FiveM ใช้ Unix Timestamp หรือ DATETIME ดีกว่า

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

เลือกตาม Data Model

ถ้าใช้ Unix Timestamp:


ทุก Resource ต้องรู้ว่าเป็น Seconds หรือ Milliseconds

ถ้าใช้ DATETIME:


ทุก Resource ต้องส่ง/อ่าน Temporal Format ให้ตรง

ความสม่ำเสมอสำคัญกว่าการเลือกตามกระแส

FiveM ใช้ NOW() ดีไหม

ถ้าต้องการ Current Database Time เช่น:


created_at
updated_at
last_seen

สามารถใช้ NOW()/CURRENT_TIMESTAMP() ตาม Requirementได้.

แต่ไม่ควรใช้แทนวันที่ที่ผู้ใช้หรือระบบภายนอกกำหนดไว้จริง

FiveM STR_TO_DATE ใช้ได้ไหม

ได้ MariaDB STR_TO_DATE() ใช้ Parse String ตาม Format ที่ระบุ แต่ Invalid Values สามารถคืน NULL/Warning หรือ Error ตาม SQL Mode.

สำหรับ Runtime Code ควร Normalize Format ตั้งแต่ Application Layer หากทำได้

FiveM Timestamp Milliseconds แก้อย่างไร

ยืนยันก่อนว่าค่าที่ได้รับคือ:


milliseconds

จริง

หากระบบปลายทางต้องใช้ Epoch Seconds จึงค่อย Convert:


milliseconds / 1000

อย่าหาร 1000 แบบสุ่มเพียงเพราะตัวเลขดูใหญ่

FiveM เปิด ALLOW_INVALID_DATES ดีไหม

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

MariaDB ระบุว่า Mode นี้สามารถยอมรับ Invalid Dates บางแบบ และยังเตือนว่า Data ที่ถูก Insertภายใต้ Mode นี้สามารถมี Behaviorไม่แน่นอนเมื่อเปลี่ยน Modeภายหลัง.

แก้ Input Validation ดีกว่า

FAQ FiveM MariaDB Error 1292

Error 1292 คืออะไร?

MariaDB Error 1292 คือ ER_TRUNCATED_WRONG_VALUE ใช้ SQLSTATE 22007.

Incorrect datetime value เกิดจากอะไร?

มักเกิดจาก Date/Datetime Value ไม่ตรง Format, วันที่ไม่มีจริง, Value คนละ Type, Schema ไม่ตรง Resource หรือ SQL Mode ที่เข้มขึ้น

DATE ใช้ Format อะไร?

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


YYYY-MM-DD

DATETIME ใช้ Format อะไร?

โดยทั่วไปใช้ Date+Time เช่น:


YYYY-MM-DD HH:MM:SS

Empty String ใช้แทนวันที่ว่างได้ไหม?

ไม่ควรถือว่าเหมือน NULL เพราะ MariaDB ระบุว่า NULL, Empty String และ Zero Value เป็นคนละค่า.

0000-00-00 ใช้ได้ไหม?

Behavior ขึ้นกับ SQL Mode โดย NO_ZERO_DATE และ Mode ที่เกี่ยวข้องมีผลต่อ Zero Dates.

วันที่ 2026-02-31 ใช้ได้ไหม?

เป็น Invalid Calendar Date ตามปกติ แม้ ALLOW_INVALID_DATES สามารถเปลี่ยน Behavior บางส่วนได้ แต่ไม่ควรใช้ Mode นี้เพื่อซ่อน Resource Bug.

Unix Timestamp กับ DATETIME เหมือนกันไหม?

ไม่ Unix Timestamp เป็น Numeric Representation ของเวลา ส่วน DATETIME เป็น Temporal Data Type ต้องกำหนด Conversion Strategy ให้ชัด

Seconds กับ Milliseconds ต่างกันไหม?

ต่างกัน 1,000 เท่า จึงเป็นสาเหตุสำคัญของ Timestamp Bugs เมื่อ Library/Resource ใช้หน่วยไม่ตรงกัน

FROM_UNIXTIME ใช้ได้ไหม?

ได้ แต่ค่าอยู่ภายใต้ข้อจำกัดของ Temporal/TIMESTAMP Range ที่ MariaDB รองรับ.

ใช้ NOW() ได้ไหม?

ได้เมื่อ Requirementคือ Current Database Time.

Error หลังย้าย VPS เกิดจาก SQL_MODE ได้ไหม?

ได้ เพราะ SQL Modes มีผลต่อ Invalid Dates และ Zero Dates.

ควรปิด Strict/Date Mode เพื่อแก้ไหม?

ไม่ควรเป็นขั้นแรก ควรแก้ Date Value, Resource Logic และ Schema ให้ตรงก่อน

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

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


Incorrect datetime value

หรือ:


Error 1292
Truncated incorrect datetime value

ให้ใช้สูตรนี้:


1292
↓
ดู Value
↓
ดู Column
↓
ดู DATE / DATETIME / TIMESTAMP / YEAR
↓
ตรวจ Format
↓
ตรวจวันที่มีจริง
↓
ตรวจ NULL / Empty String / Zero Date
↓
ตรวจ Seconds / Milliseconds
↓
ตรวจ Parameters
↓
ตรวจ Migration
↓
ตรวจ SQL_MODE

MariaDB กำหนด Error 1292 เป็น ER_TRUNCATED_WRONG_VALUE และ SQL Modes อย่าง ALLOW_INVALID_DATES, NO_ZERO_DATE และ NO_ZERO_IN_DATE สามารถเปลี่ยนวิธีที่ Server จัดการ Temporal Values ได้.

สำหรับ FiveM Resource ควรทำให้วันเวลามี Format และหน่วยเดียวกันทั้งระบบ โดยเฉพาะอย่าปะปน DD/MM/YYYY, SQL DATETIME, Unix Seconds และ Unix Milliseconds โดยไม่มี Conversion Layer ที่ชัดเจน

สำหรับผู้อ่าน comsiam ให้จำสูตร “1292 → ดูวันที่ที่ส่งจริงก่อนเปลี่ยน Database” และ comsiam แนะนำให้ตรวจ Value + Column Type + Parameter + SQL_MODE พร้อมกัน เพราะ Error วันเวลาจำนวนมากเกิดจาก Resource กับ Database ใช้ Date Contract คนละแบบ ไม่ใช่ MariaDB เสีย