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

August 17, 2026

เวลาเปิด FiveM Server แล้ว Console หรือ MariaDB แจ้ง Error ลักษณะนี้:

ERROR 1292 (22007): Incorrect datetime value

หรือ:

Truncated incorrect datetime value

ปัญหานี้มักเกี่ยวข้องกับ ค่าของวันที่หรือเวลาที่ Script กำลังส่งเข้า MariaDB ไม่ตรงกับชนิด Column, Format หรือเงื่อนไขของ SQL Mode

MariaDB ระบุ Error Code 1292 / SQLSTATE 22007 ไว้ในกลุ่ม ER_TRUNCATED_WRONG_VALUE หรือค่าที่ไม่สามารถตีความให้เข้ากับชนิดข้อมูลตามที่คาดไว้ได้

สำหรับ FiveM ปัญหานี้อาจเกิดขึ้นตอน:

INSERT Character Data
UPDATE Player Data
Save Ban
Save Vehicle
Save House
Save Business
Store Transaction
Save Cooldown
Save Last Login
Save Created Date
Import SQL
Update Resource
Migrate Database

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

Incorrect datetime value: '17/08/2026 14:30'

แต่ Column ต้องการค่าที่สามารถตีความเป็น DATETIME ได้อย่างถูกต้อง

แนวทางที่ปลอดภัยสำหรับระบบ FiveM ส่วนใหญ่คือส่งค่าในรูปแบบมาตรฐาน เช่น:

2026-08-17 14:30:00

แทนการส่งวันที่แบบ:

17/08/2026 14:30

และที่สำคัญ อย่าเริ่มแก้ด้วยการปิด Strict Mode ทันที เพราะการทำเช่นนั้นอาจเพียงซ่อนปัญหาข้อมูลที่ Script ส่งมาผิด Format แทนที่จะแก้ต้นเหตุ

① Error 1292 คืออะไร

MariaDB Error 1292 ใช้กับกรณีที่ระบบพบค่าที่ไม่ถูกต้องหรือไม่สามารถแปลงให้เข้ากับชนิดข้อมูลที่ต้องการได้ โดย Error นี้ไม่ได้จำกัดเฉพาะ DATETIME อย่างเดียว แต่เมื่อข้อความระบุ Incorrect datetime value ก็ควรเริ่มตรวจข้อมูลวันและเวลาเป็นอันดับแรก

② ตัวอย่าง Error ใน FiveM

คุณอาจเห็น:

Error: ER_TRUNCATED_WRONG_VALUE

หรือ:

Incorrect datetime value

หรือ:

Data truncated for column

รายละเอียดจริงขึ้นอยู่กับ Database Driver และ Resource

③ Error 1292 หมายความว่า Database พังไหม

ไม่จำเป็น

ส่วนใหญ่หมายความว่า:

Query → ส่งค่า → MariaDBไม่ยอมรับ

Database Server อาจทำงานปกติ

④ DATETIME คืออะไร

DATETIME เป็นชนิดข้อมูลของ MariaDB สำหรับเก็บ:

วันที่
เวลา

รวมกัน โดย MariaDB มีชนิดข้อมูลวันที่/เวลาหลายชนิด เช่น DATE, DATETIME, TIMESTAMP และ TIME

⑤ DATE คืออะไร

ใช้เก็บ:

YYYY-MM-DD

เช่น:

2026-08-17

MariaDB ระบุรูปแบบมาตรฐานของ DATE เป็นปี-เดือน-วัน

⑥ DATETIME คืออะไร

โดยทั่วไปใช้เก็บทั้งวันและเวลา เช่น:

2026-08-17 15:30:00

เหมาะกับข้อมูลประเภท:

created_at
updated_at
last_login

⑦ TIMESTAMP คืออะไร

เป็นชนิดข้อมูลวันเวลาของ MariaDB อีกประเภทหนึ่ง แต่มีพฤติกรรมและช่วงค่าบางอย่างต่างจาก DATETIME

ดังนั้นอย่าเปลี่ยน:

DATETIME

เป็น:

TIMESTAMP

เพียงเพื่อให้ Error หาย โดยไม่เข้าใจ Schema ก่อน

⑧ Format ที่ปลอดภัยสำหรับ DATETIME

ใน FiveM Script ควรใช้รูปแบบที่ชัดเจน เช่น:

YYYY-MM-DD HH:MM:SS

ตัวอย่าง:

2026-08-17 15:08:00

⑨ ตัวอย่าง Format ที่มักสร้างปัญหา

เช่น:

17/08/2026

08/17/2026

17-08-2026 15:08

August 17 2026

หาก Application ไม่แปลงรูปแบบให้ตรงกับสิ่งที่ Database คาดไว้ก่อน

⑩ ทำไม DD/MM/YYYY จึงเสี่ยง

เพราะ Application กับ Databaseอาจตีความ:

08/09/2026

ไม่เหมือนกันว่าเป็น:

8 กันยายน
9 สิงหาคม

การ Normalize Format ก่อนบันทึกจึงปลอดภัยกว่า

⑪ Error 1292 จาก JavaScript Date

FiveM Resourcesจำนวนมากเขียนด้วย:

JavaScript
TypeScript

Developerอาจส่ง Stringจาก JavaScriptเข้า SQLโดยตรง

เช่น:

new Date().toString()

ซึ่งอาจได้ข้อความที่ไม่เหมาะกับ Column DATETIME

⑫ สิ่งที่ไม่ควรทำ

ไม่ควรเอา:

new Date().toString()

ไป INSERTตรง ๆ โดยหวังว่า MariaDBจะเข้าใจทุกครั้ง

⑬ ควร Normalize Date ก่อน INSERT

แนวคิดคือ:

Application Date
↓
Normalize
↓
YYYY-MM-DD HH:MM:SS
↓
SQL Parameter

⑭ Lua Resource ก็เกิดได้ไหม

ได้

ถ้า Script Luaสร้าง Date Stringที่ Databaseไม่ยอมรับ

ปัญหาไม่ได้ขึ้นกับภาษาอย่างเดียว

⑮ SQL Import ก็เกิดได้ไหม

ได้

โดยเฉพาะ SQLเก่าที่มีค่าประเภท:

0000-00-00

หรือ:

0000-00-00 00:00:00

และ SQL Modeของ MariaDBปัจจุบันไม่อนุญาตค่าดังกล่าว

MariaDB มี SQL modes เช่น NO_ZERO_DATE ที่ส่งผลต่อการยอมรับ zero-date values

⑯ Zero Date คืออะไร

เช่น:

0000-00-00

หรือ:

0000-00-00 00:00:00

⑰ Zero Date ใช้ได้เสมอไหม

ไม่

พฤติกรรมขึ้นอยู่กับ:

SQL Mode
MariaDB Version
Query Context

MariaDB documentation ระบุว่า NO_ZERO_DATE มีผลกับการยอมรับ zero-date values

⑱ Script FiveM เก่าเสี่ยง Zero Date

โดยเฉพาะ Resourceเก่าที่ Schemaกำหนด:

DEFAULT '0000-00-00 00:00:00'

แต่ย้ายมา Database Environmentใหม่

⑲ สิ่งแรกที่ควรดู

อ่านข้อความ Error ให้ครบ

เช่น:

Incorrect datetime value: '0000-00-00 00:00:00'
for column 'last_login'

ตรงนี้บอกได้เกือบทั้งหมดว่า:

ค่าอะไรผิด
Columnไหนผิด

⑳ อย่าดูแค่ Error 1292

ต้องดูข้อความหลัง Errorด้วย

เพราะ 1292สามารถเกี่ยวกับค่าประเภทอื่นได้เช่นกัน

㉑ ตัวอย่าง Query ที่ผิด

INSERT INTO users (last_login)
VALUES ('17/08/2026 15:30');

ถ้า Database/Conversion Pathไม่รองรับ Formatนี้

㉒ ตัวอย่างที่ควร Normalize

INSERT INTO users (last_login)
VALUES ('2026-08-17 15:30:00');

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

ถ้าต้องการเวลาปัจจุบันของ Database Server สามารถใช้:

NOW()

MariaDB มี NOW() สำหรับคืนวันและเวลาปัจจุบัน

㉔ ตัวอย่าง

INSERT INTO users (last_login)
VALUES (NOW());

เหมาะเมื่อไม่จำเป็นต้องใช้ Timestampจาก Client

㉕ ข้อดีของ NOW()

ลดปัญหา Applicationสร้าง Date Stringผิด Format

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

ถ้าเหตุการณ์เกิดจากเวลาเฉพาะที่ Applicationส่งมา เช่น:

Ban Expiration
Scheduled Event

ต้องบันทึกเวลาที่ถูกต้องของ Eventนั้น

㉗ CURRENT_DATE ใช้เมื่อไร

ถ้าต้องการเฉพาะวันที่สามารถใช้:

CURRENT_DATE

หรือ:

CURDATE()

MariaDB ระบุว่า CURDATE() คืนวันที่ปัจจุบัน

㉘ อย่าใช้ DATE เมื่อต้องเก็บเวลา

ถ้า Column:

DATE

จะเน้นข้อมูลวันที่

ถ้าต้องการ:

2026-08-17 15:30:00

ควรตรวจว่า Schemaควรเป็น DATETIME หรือ TIMESTAMP

㉙ ตรวจ Column Type

ใช้:

DESCRIBE users;

หรือ:

SHOW CREATE TABLE users;

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

㉚ สิ่งที่ควรหา

ดู Columnที่ Errorพูดถึง เช่น:

last_login
created_at
updated_at
expires_at
banned_until

㉛ ถ้า Column เป็น DATETIME

ตรวจว่า Scriptส่งค่า:

YYYY-MM-DD HH:MM:SS

หรือค่าที่ MariaDBสามารถ Parseได้ถูกต้อง

㉜ ถ้า Column เป็น DATE

อย่าส่ง Time Stringโดยไม่จำเป็น

㉝ ถ้า Column เป็น INT แต่ Scriptส่ง Date

นี่อาจเป็น Schema mismatch

เช่น Scriptคาดว่า:

UNIX Timestamp

แต่ Databaseถูกแก้เป็น:

DATETIME

㉞ Unix Timestamp คืออะไร

ค่าจำนวนเต็มแทนเวลา เช่น:

1723900000

เป็นคนละรูปแบบกับ:

2026-08-17 15:30:00

㉟ อย่าสลับ Unix Timestamp กับ DATETIME

Scriptกับ Schemaต้องตกลงกันว่าใช้รูปแบบไหน

㊱ FiveM Resource Update อาจทำ Schema เปลี่ยน

ตัวอย่าง:

Resource Versionเก่า:

expires = INT

Versionใหม่:

expires_at = DATETIME

ถ้าอัปเดต Scriptแต่ไม่ Run Migration:

Errorเกิดได้

㊲ Migration คืออะไร

การปรับ Database Schemaให้ตรงกับ Resource Versionใหม่

㊳ อัปเดต Resource แต่ไม่ Import SQL ใหม่

เป็นสาเหตุสำคัญของ Database Errorหลายประเภท

㊴ ตรวจ README ของ Resource

ดูว่า Versionใหม่ต้อง:

ALTER TABLE
ADD COLUMN
MODIFY COLUMN

หรือไม่

㊵ อย่า Import SQL ใหม่ทับ Databaseทันที

เพราะอาจ:

ลบข้อมูล
Duplicate Columns
เปลี่ยน Schemaผิด

ควร Backupก่อน

㊶ Backup Database ก่อนแก้

สำคัญมาก

ก่อนใช้:

ALTER TABLE

หรือ Updateข้อมูลจำนวนมาก

ควร Backupก่อน

㊷ Errorเกิดหลัง Update Resource

ให้สงสัย:

Schemaไม่ตรง
Migrationไม่ได้ Run
Configเปลี่ยน
Date Formatเปลี่ยน

㊸ Errorเกิดหลัง Update MariaDB

ให้ตรวจ:

SQL Mode
Version Compatibility
Old Schema

เพราะ Environmentใหม่อาจเข้มงวดกับข้อมูลที่ Environmentเก่าเคยปล่อยผ่าน

㊹ SQL_MODE คืออะไร

SQL_MODE เป็นการตั้งค่าที่เปลี่ยนพฤติกรรมของ MariaDBในการตรวจและจัดการ SQL/input data หลายประเภท

㊺ ดู SQL Mode อย่างไร

ใช้:

SELECT @@sql_mode;

㊻ ดู Session SQL Mode

SELECT @@SESSION.sql_mode;

㊼ ดู Global SQL Mode

SELECT @@GLOBAL.sql_mode;

㊽ Session กับ Global ต่างกันอย่างไร

Session:

Connectionปัจจุบัน

Global:

ค่า Defaultสำหรับ Connectionsใหม่

MariaDBรองรับ SQL Modeในระดับ Sessionและ Global

㊾ Strict Mode คืออะไร

เมื่อ Strict Modeทำงาน MariaDBจะปฏิเสธข้อมูลบางชนิดที่ไม่ถูกต้องแทนการปรับค่า/เตือนแล้วบันทึกต่อในบางกรณี

㊿ STRICT_TRANS_TABLES คืออะไร

เป็นหนึ่งใน SQL Modesที่ใช้พฤติกรรมแบบ Strictสำหรับ Transactional Tables

MariaDB documentationอธิบายว่า Strict Modeเปลี่ยนข้อมูลที่ไม่ถูกต้องบางประเภทจาก Warningให้เป็น Error

51. Strict Mode เป็นตัวร้ายไหม

ไม่

Strict Modeช่วยป้องกันข้อมูลผิดเข้าฐานข้อมูล

52. ทำไมบาง Tutorial บอกให้ปิด Strict Mode

เพราะ Resourceเก่าบางตัวเขียนมาโดยสมมติว่า Databaseยอม:

Invalid Dates
Truncated Values

แต่การปิด Strict Modeอาจเพียงทำให้ Errorเงียบลง

53. ควรปิด Strict Mode ไหม

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

ควรแก้:

Date Format
Schema
Query

ให้ถูกก่อน

54. ปิด Strict Mode มีความเสี่ยงอะไร

Databaseอาจ:

ปรับค่าผิด
บันทึกค่าที่ Applicationไม่คาดคิด
ซ่อน Bug

MariaDBระบุว่าเมื่อไม่ได้ใช้ Strict Mode ค่าที่ผิดบางประเภทอาจถูกปรับและเกิด Warningแทน Error

55. แนวคิดที่ดีกว่า

แทน:

Error → ปิด Strict Mode

ควรเป็น:

Error
↓
ดู Column
↓
ดู Value
↓
ดู Schema
↓
ดู Query
↓
แก้ Format/Type

56. NO_ZERO_DATE คืออะไร

SQL Modeที่เกี่ยวกับการยอมรับวันที่แบบ:

0000-00-00

MariaDB documentationระบุผลของ Modeนี้ต่อ zero-date values

57. ALLOW_INVALID_DATES คืออะไร

MariaDBมี SQL Modeสำหรับอนุญาตวันบางแบบที่ปกติถือว่าไม่ถูกต้อง แต่ไม่ควรเปิดเพียงเพื่อแก้ FiveM Resourceที่ส่ง Dateผิดโดยไม่เข้าใจผลกระทบ

58. ตัวอย่างวันที่ผิดจริง

2026-02-31

เพราะไม่มีวันที่ 31 กุมภาพันธ์

59. ตัวอย่างเดือนผิด

2026-13-01

เดือน 13ไม่ใช่เดือนปกติ

60. ตัวอย่างวันเป็นศูนย์

2026-08-00

พฤติกรรมอาจสัมพันธ์กับ SQL Mode

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

0000-00-00

ควรหลีกเลี่ยงในการออกแบบใหม่

62. ใช้ NULL แทน Zero Date ดีไหม

ถ้าความหมายคือ:

“ยังไม่มีวันที่”

การออกแบบ Columnให้รองรับ:

NULL

มักสื่อความหมายได้ชัดกว่า Zero Date

แต่ต้องตรวจ Applicationว่า Handle NULL ได้

63. ตัวอย่าง

แทน:

last_login = '0000-00-00 00:00:00'

อาจออกแบบเป็น:

last_login = NULL

จนกว่า Characterจะ Loginครั้งแรก

64. แต่เปลี่ยนเป็น NULLเองได้เลยไหม

ไม่

ต้องตรวจ:

Script
Queries
ORM
Column Constraint

ก่อน

65. NOT NULL คืออะไร

Columnที่ไม่อนุญาตค่า:

NULL

MariaDBจะตรวจ Constraintตาม SQL Modeและ Statement Context

66. ถ้าต้องการ NULL

Schemaอาจต้องเป็น:

DATETIME NULL

แต่ต้องตรวจ Resource Compatibility

67. DEFAULT NULL คืออะไร

ถ้าไม่มีค่าถูกส่งมา:

NULL

สามารถเป็น Defaultได้ถ้า Columnรองรับ

68. DEFAULT CURRENT_TIMESTAMP คืออะไร

บาง Schemaใช้เวลาปัจจุบันเป็น Default

แต่ต้องตรวจว่า Logicของ Resourceต้องการแบบนั้นจริงหรือไม่

69. created_at เหมาะกับ Current Timestamp ไหม

หลายระบบใช้เวลาปัจจุบันตอนสร้าง Record

แต่ FiveM Resourceแต่ละตัวอาจจัดการเอง

70. updated_at ล่ะ

อาจ Update:

Application Side
Database Side

ขึ้นกับ Schema

71. last_login ไม่ควร Defaultเป็นเวลาปัจจุบันทุกกรณี

เพราะอาจทำให้ความหมายว่า:

“เคย Loginแล้ว”

ทั้งที่ Characterเพิ่งถูกสร้าง

ต้องออกแบบตาม Logic

72. STR_TO_DATE() คืออะไร

MariaDBมีฟังก์ชัน STR_TO_DATE() สำหรับแปลง Stringตาม Formatที่ระบุให้เป็น DATE, TIME หรือ DATETIMEตามส่วนประกอบของ Format

73. ตัวอย่าง STR_TO_DATE

ถ้ามีข้อมูล:

17/08/2026 15:30:00

สามารถ Parseด้วยแนวคิด:

STR_TO_DATE('17/08/2026 15:30:00', '%d/%m/%Y %H:%i:%s')

STR_TO_DATE() ใช้ Format Stringในการตีความค่าที่รับเข้ามา

74. `%Y` หมายถึงอะไร

ใช้แทนปีแบบ 4หลักใน Date Format Function

75. `%m`

เดือนแบบตัวเลข

76. `%d`

วันของเดือน

77. `%H`

ชั่วโมงแบบ 24 ชั่วโมง

78. `%i`

นาที

79. `%s`

วินาที

MariaDBระบุชุด Format Optionsสำหรับ DATE_FORMAT() และ STR_TO_DATE() ไว้ใน documentation

80. ควรใช้ STR_TO_DATEทุก INSERTไหม

ไม่จำเป็น

ถ้า Applicationสามารถสร้าง:

YYYY-MM-DD HH:MM:SS

ที่ถูกต้องตั้งแต่ต้น จะง่ายกว่า

81. STR_TO_DATEเหมาะกับอะไร

เหมาะกับ:

Import
Migration
Legacy Data

ที่ Date Stringมี Formatเฉพาะ

82. แก้ที่ Application ดีกว่า Databaseไหม

ถ้า Resourceเป็นต้นกำเนิดค่าผิด:

แก้ Resourceมักตรงจุดกว่า

83. ตัวอย่าง FiveM Resource

สมมติ Resourceส่ง:

const date = "17/08/2026 15:30";

แล้ว Query:

INSERT INTO bans (expires_at) VALUES (?)

Column:

DATETIME

นี่ควร Normalizeก่อนส่ง

84. Prepared Statement ช่วยอะไร

ควรใช้ Parameterized Queryแทนการต่อ SQL Stringด้วยค่าจาก Player

เช่นแนวคิด:

INSERT ... VALUES (?)

แล้วส่ง Parametersแยก

85. Prepared Statement แก้ Date Formatเองไหม

ไม่

ถ้าค่า Dateผิด:

ยังผิด

Prepared Statementช่วยเรื่องการส่ง Parameterและ Security แต่ไม่เปลี่ยน Invalid Dateให้ถูก

86. oxmysql เกี่ยวไหม

FiveM Serverจำนวนหนึ่งใช้ Database Resourceเพื่อส่ง Queryไป MySQL/MariaDB

แต่เมื่อ MariaDBแจ้ง Error 1292 ต้นเหตุสำคัญยังคือ:

Query
Value
Schema

87. mysql-async เกี่ยวไหม

Resource Database Driverอาจเป็นผู้แสดง Error

แต่ Driverไม่จำเป็นต้องเป็นต้นเหตุ

88. Database Wrapper ไม่ควรถูกโทษทันที

ดู Queryจริงก่อน

89. Query Debug สำคัญ

ต้องรู้ว่า Resourceกำลังส่งอะไร เช่น:

expires_at = ?

Parameterจริงคือ:

17/08/2026

ตรงนี้จะช่วยหา Root Causeได้เร็ว

90. Root Cause คืออะไร

สาเหตุจริงของ Error

ไม่ใช่เพียงจุดที่ Errorถูกแสดง

91. Error Stack ช่วยอะไร

อาจบอก:

Resource
File
Function
Query

ที่เรียก Database

92. Resource Name สำคัญ

ถ้า Consoleบอก:

@my_resource/server.lua

ให้เริ่มตรวจ Resourceนั้น

93. Line Number สำคัญ

ถ้ามี:

server.lua:150

ตรวจ Queryบริเวณนั้น

94. Search คำว่า Column Name

ถ้า Errorพูด:

expires_at

ค้นใน Resource:

expires_at

เพื่อหา INSERT/UPDATE

95. Search SQL Files ด้วย

Columnอาจอยู่ใน:

install.sql
schema.sql
migration.sql

96. ตรวจ Schemaจาก Databaseจริง

อย่าเชื่อ SQL Fileอย่างเดียว

เพราะ Databaseที่ Runningอยู่จริงอาจถูกแก้จาก Versionเก่า

97. SHOW CREATE TABLE ช่วยมาก

เช่น:

SHOW CREATE TABLE bans;

คุณจะเห็น Definitionจริง

98. ตรวจ Migration History

ถ้า Resourceมีหลาย Version:

v1
v2
v3

อาจต้อง Run Migrationตามลำดับ

99. อย่าข้าม Migration

เพราะ Column Typeอาจเปลี่ยนหลายขั้น

100. Error 1292 หลังย้าย Hosting

สาเหตุอาจเป็น Environmentใหม่มี:

MariaDB Versionต่าง
SQL Modeต่าง
Timezoneต่าง

แต่ต้องตรวจจริงก่อนสรุป

101. Timezone เป็นสาเหตุหลักของ Incorrect Format ไหม

ไม่เสมอไป

Timezoneกับ Formatเป็นคนละเรื่อง

102. Timezone คืออะไร

กำหนดบริบทว่าเวลาหนึ่งอยู่ใน Zoneใด

103. Timezoneผิดอาจทำให้เวลาเหลื่อม

เช่น:

Server Time
Database Time
Application Time

ไม่ตรงกัน

104. แต่ Timezoneผิดไม่เท่ากับ Formatผิด

2026-08-17 15:00:00

อาจเป็น Formatถูก

แต่เวลาผิด Zone

105. ต้องแยกสองปัญหา

Format Problem

Databaseอ่านค่าไม่ได้

Timezone Problem

Databaseอ่านได้ แต่เวลาที่บันทึกไม่ตรงสิ่งที่ต้องการ

106. NOW() ใช้ Timezoneอะไร

ผลลัพธ์ขึ้นกับเวลาของ Database Session/Server Context

ดังนั้นระบบที่ต้องการมาตรฐานเวลาอาจต้องวาง Timezone Strategyให้ชัด

107. UTC คืออะไร

ระบบจำนวนมากเลือกเก็บเวลาใน:

แล้วแปลงเป็น Local Timeตอนแสดงผล

108. FiveMต้องใช้ UTCไหม

ไม่บังคับ

แต่ควรใช้ Strategyเดียวกันทั้ง:

Application
Database
UI

109. ปัญหาเกิดเมื่อบางส่วนใช้ UTC บางส่วนใช้ Local โดยไม่แปลง

อาจทำให้:

Banหมดผิดเวลา
Cooldownผิด
Logsเหลื่อม

แม้ไม่เกิด Error 1292

110. Timestamp milliseconds คืออะไร

JavaScriptบาง APIใช้เวลาเป็น:

milliseconds

นับจาก Unix Epoch

111. Unix Timestampในหลายระบบอาจเป็น seconds

เช่น:

1723900000

112. JavaScript Timestampมักมีหลักมากกว่า

เช่น:

1723900000000

เพราะเป็น milliseconds

113. ส่ง millisecondsเข้า DATETIMEตรง ๆ ได้ไหม

ไม่ควร

ต้อง Convertให้ถูกชนิดก่อน

114. ส่ง Unix secondsเข้า DATEก็ผิดแนวคิด

ต้องรู้ Schemaก่อน

115. Resourceหนึ่งใช้ INT Timestamp

ตัวอย่าง:

expires BIGINT

Scriptอาจบันทึก Unix Time

116. Resourceอีกตัวใช้ DATETIME

expires_at DATETIME

Scriptอาจบันทึก Date String

สองแบบใช้แทนกันไม่ได้โดยตรง

117. วิธีรู้ว่า Resourceต้องการอะไร

ดู:

SQL Schema
Source Code
Documentation
Migration

118. อย่าเปลี่ยน Columnตาม Error Messageอย่างเดียว

เช่น Error DATETIMEแล้วเปลี่ยน:

DATETIME → VARCHAR

เพื่อให้รับทุก String

นี่อาจทำให้ Queryเวลาในอนาคตพัง

119. VARCHARแก้ Errorได้แต่สร้างTechnical Debt

เพราะ Dateจะกลายเป็นข้อความ

การ:

Sort
Compare
Calculate Expiry

ทำได้ยุ่งขึ้น

120. ถ้าเป็น Dateจริงควรใช้ Date Typeให้เหมาะ

เช่น:

DATE
DATETIME
TIMESTAMP

ตาม Requirement

121. อย่าเก็บ Dateหลาย Formatใน Columnเดียว

เช่น:

2026-08-17
17/08/2026
Aug 17

จะทำให้ Data Cleanupยากมาก

122. Normalize Data คืออะไร

ทำให้ข้อมูลอยู่ในรูปแบบเดียวกันก่อนบันทึก

123. Data Validation คืออะไร

ตรวจค่าก่อนส่ง Database

เช่น:

Dateมีจริงไหม
Typeถูกไหม

124. Validate Ban Expiration

ถ้า Playerเลือก Ban Length แล้วระบบคำนวณ:

expires_at

ควร Validateก่อน Query

125. Invalid InputควรถูกRejectก่อนถึง SQL

Applicationควรไม่ส่ง:

Invalid Date

ลง Database

126. JavaScript Invalid Date คืออะไร

เกิดเมื่อ Date Parserไม่สามารถสร้าง Dateจาก Input

ถ้า Convertต่อโดยไม่ตรวจอาจได้ Stringผิดปกติ

127. Lua os.date ใช้ได้ไหม

ได้สำหรับ Formatวันที่ตามที่ Developerกำหนด

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

Local/UTC
Format

128. ตัวอย่าง Formatแนวคิดใน Lua

สามารถสร้าง Stringที่มีรูปแบบ:

YYYY-MM-DD HH:MM:SS

ก่อน Query

129. อย่าคัดลอก CodeจากTutorialแบบไม่รู้ Timezone

เพราะ Ban/Cooldownอาจคลาดเคลื่อน

130. Errorจาก Empty String

บาง Scriptอาจส่ง:

''

เข้า DATETIME

แทน:

NULL

หรือ Dateที่ถูกต้อง

131. Empty Stringไม่ใช่ Date

ถ้า Columnเป็น DATETIME อย่าใช้ Empty Stringเพื่อแทน:

ไม่มีข้อมูล

132. ถ้าไม่มีวันที่ควรทำอย่างไร

ออกแบบ Logicให้ใช้:

NULL

ถ้า Resourceรองรับ

133. ตัวอย่าง Bug

expiresAt = ""

แล้วส่งเข้า:

expires_at DATETIME

อาจทำให้ Error

134. Optional Date Fieldต้อง Handleให้ดี

เช่น Banถาวรอาจไม่มี:

Expiry Date

Applicationต้องกำหนด Representationชัดเจน

135. Permanent Banเก็บอย่างไร

มีหลาย Design เช่น:

NULL expires_at
Boolean permanent
Sentinel value

แต่ Resourceกับ Schemaต้องตรงกัน

136. Sentinel Date คืออะไร

ใช้วันที่พิเศษแทน Stateหนึ่ง เช่น:

2099-12-31

แต่ควรใช้เฉพาะถ้า Applicationออกแบบมาแบบนั้นจริง

137. อย่าสุ่มเปลี่ยน Permanent Ban Date

อาจทำให้:

Unban Logic
Comparison

ผิด

138. Expiry Query มักใช้ Comparison

เช่นแนวคิด:

WHERE expires_at > NOW()

จึงควรเก็บเป็น Date Typeที่ถูกต้อง

139. VARCHAR Dateทำ Comparisonยุ่ง

String Sortingอาจไม่เท่ากับ Chronological Sortingถ้า Formatไม่เป็นมาตรฐาน

140. ISO-like orderingช่วยอะไร

Format:

YYYY-MM-DD HH:MM:SS

เรียงจาก:

ปี
เดือน
วัน
เวลา

และสอดคล้องกับการใช้งาน Date/Datetimeทั่วไปของ MariaDB

141. Errorหลัง Import Player Dataเก่า

ตรวจข้อมูลที่มีอยู่แล้ว

เช่น:

SELECT last_login
FROM users;

หา Rowsผิดปกติ

142. Backupก่อน Updateข้อมูลเก่า

สำคัญมาก

143. อย่า UPDATEทั้งTableโดยไม่มี WHERE

ตัวอย่างอันตราย:

UPDATE users SET last_login = NULL;

จะเปลี่ยนทุก Character

144. ทดสอบ SELECT ก่อน

ก่อน Updateใช้:

SELECT ...
WHERE ...

เพื่อดู Rowsที่จะได้รับผล

145. ใช้ Transactionได้ไหม

สำหรับการแก้ข้อมูลบางประเภทสามารถใช้ Transactionถ้า Engine/Operationรองรับ

ช่วยให้ Rollbackได้ก่อน Commit

146. Production Databaseไม่ควรทดลองสด

ถ้าเป็นไปได้:

Backup
Test Copy
Staging

ก่อน

147. phpMyAdminใช้แก้ได้ไหม

ได้ถ้า Hostingมี

แต่ Toolไม่ได้เปลี่ยนหลักการ:

ต้องรู้ Schema
ต้อง Backup

148. HeidiSQLใช้ได้ไหม

เป็น Database Clientหนึ่ง

แต่ Errorเกิดจาก MariaDB/Query ไม่ได้เกิดเพราะใช้ Clientใดโดยตรง

149. Adminerใช้ได้ไหม

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

เป็นเพียง UIสำหรับจัดการ Database

150. Command Lineดีที่สุดไหม

ไม่จำเป็นสำหรับทุกคน

Toolไหนก็ได้ตราบใดที่:

เห็น Schema
Run Queryอย่างระวัง

151. Errorเกิดเฉพาะ Characterหนึ่ง

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

Rowนั้นมีข้อมูลผิด

มากกว่า Schemaทั้งหมด

152. Errorเกิดกับ Characterใหม่ทุกคน

น่าสงสัย:

INSERT Query
Default Value
Schema

153. Errorเกิดตอน Server Start

อาจเป็น:

Migration
Resource Init
Cleanup Query

154. Errorเกิดตอน Player Disconnect

อาจ Resourceกำลัง Save:

last_seen
logout_time

ด้วย Formatผิด

155. Errorเกิดตอน Login

ตรวจ:

last_login
created_at
ban expiration

156. Errorเกิดตอน Ban Player

ตรวจ:

banned_until
expires_at

157. Errorเกิดตอน Garage

ตรวจ Columnประเภท:

impound_time
stored_at

ถ้า Resourceมี

158. Errorเกิดตอน Housing

ตรวจ:

purchased_at
rent_due
last_payment

ถ้ามี

159. Errorเกิดตอน Business

ตรวจ:

created_at
payroll_time
transaction_time

ตาม Schema

160. Errorเกิดตอน Cooldown

ระบบอาจ Save:

expiration timestamp

ผิด Type

161. Errorเกิดหลัง Copy Databaseจาก MySQLไปMariaDB

ถึง Syntaxจำนวนมากจะคล้ายกัน แต่ควรตรวจ:

SQL Modes
Schema
Date Defaults

แทนคิดว่า Environmentเหมือนกัน 100%

MariaDB documentationแยก SQL modesและ data type behaviorของตัวเองไว้อย่างชัดเจน

162. Errorเกิดหลัง Restore Backup

Backupอาจมี:

Zero Dates
Legacy Defaults

ที่ Environmentใหม่ไม่ยอมรับ

163. ตรวจ Dump File

ค้น:

0000-00-00

หรือ:

00/00/0000

ถ้า Errorเกี่ยวกับ Date

164. อย่า Search & Replaceทั้ง Dumpแบบสุ่ม

เพราะบาง Stringอาจอยู่ใน:

JSON
Notes
Other Data

และไม่ได้เป็น Date Column

165. Migration Dataควรทำตาม Column

รู้ก่อนว่า:

Table
Column
Expected Type

166. JSON Columnก็มี Date Stringได้

แต่ JSON Stringไม่จำเป็นต้องถูกตรวจเป็น DATETIMEจน Applicationนำไปใช้

167. Errorบอก Columnตรง ๆ

ใช้ข้อมูลนั้นนำทางก่อน

168. WarningกับErrorต่างกัน

บาง SQL Mode/Statementอาจทำให้ Invalid Dataกลายเป็น Warningแทน Error แต่ไม่ควรถือว่า Warningคือข้อมูลถูกต้องเสมอ

169. SHOW WARNINGSช่วยได้ไหม

หลัง Statementบางประเภทสามารถตรวจ Warningได้

เหมาะกับ Debug SQL

170. Strict Modeช่วยจับBugเร็ว

เพราะ Resourceไม่สามารถแอบบันทึกข้อมูลที่ผิดบางประเภทแล้วเดินต่อเงียบ ๆ

171. Production FiveMควรแก้Root Cause

ดีที่สุดคือ:

Scriptส่งค่าถูก
Schemaตรง
Migrationครบ

172. วิธีแก้แบบที่ 1 — แก้ Date Format

จาก:

17/08/2026 15:30

เป็น:

2026-08-17 15:30:00

173. วิธีแก้แบบที่ 2 — ใช้ NOW()

ถ้าต้องการเวลาปัจจุบัน:

NOW()

174. วิธีแก้แบบที่ 3 — ใช้ STR_TO_DATE

ถ้า Import Legacy String:

STR_TO_DATE(...)

ตาม Formatจริง

175. วิธีแก้แบบที่ 4 — ใช้ NULLอย่างถูกต้อง

สำหรับ Optional Date

แต่ Schemaและ Resourceต้องรองรับ

176. วิธีแก้แบบที่ 5 — แก้ Column Type

ทำเฉพาะเมื่อพิสูจน์แล้วว่า Schemaไม่ตรง Resource Version

MariaDBรองรับการเปลี่ยน Columnผ่าน ALTER TABLE แต่ควรทำหลัง Backupและตรวจ Migrationให้ถูกต้อง

177. วิธีแก้แบบที่ 6 — Run Migration

ถ้า Resource Documentationระบุว่าต้อง Update Database

178. วิธีแก้แบบที่ 7 — ล้าง Legacy Zero Dates

ทำหลัง Backupและรู้ความหมายของ Column

179. วิธีแก้แบบที่ 8 — ตรวจ SQL Mode

เพื่อเข้าใจว่าทำไม Serverเก่าใช้ได้แต่ Serverใหม่ Error

180. วิธีที่ไม่ควรทำก่อน — ปิด Strict Modeทั้งหมด

เพราะอาจกระทบ:

Resourcesอื่น
Data Integrity

181. วิธีที่ไม่ควรทำ — เปลี่ยน DATETIMEเป็นTEXT

เพียงเพื่อให้ INSERTผ่าน

182. วิธีที่ไม่ควรทำ — ใส่ DEFAULTมั่ว

เช่น:

1970-01-01

โดยไม่รู้ Application Logic

183. วิธีที่ไม่ควรทำ — ลบ Column

Resourceอาจ Query Columnนั้นทุกครั้ง

184. วิธีที่ไม่ควรทำ — Import SQLซ้ำทั้งไฟล์

โดยไม่อ่านว่า Scriptใช้:

CREATE
ALTER
DROP

อะไร

185. วิธีที่ไม่ควรทำ — ลบ Databaseสร้างใหม่

Error 1292ส่วนใหญ่ไม่จำเป็นต้องแก้แรงขนาดนั้น

186. Production Dataอาจหายทั้งหมด

ถ้าลบ:

users
owned_vehicles
properties

โดยไม่ Backup

187. Checklist แก้ Error 1292 แบบเร็ว

อ่าน Errorเต็ม
หา Table/Column
ดู Valueที่ผิด
ดู Column Type
ดู Query
ตรวจ Resource Version
ตรวจ SQL Mode
Backup
แก้ Root Cause
Testใหม่

188. Checklist ถ้า Error บอก Incorrect datetime value

ดูว่า Valueเป็น:

DD/MM/YYYY

หรือ:

Invalid Date

หรือ:

0000-00-00

หรือ:

Empty String

189. Checklist Schema

ตรวจ:

SHOW CREATE TABLE table_name;

190. Checklist SQL Mode

ตรวจ:

SELECT @@sql_mode;

MariaDBใช้ sql_modeในการกำหนดพฤติกรรมหลายอย่างที่เกี่ยวกับ validationของข้อมูล

191. Checklist Resource

ค้น:

Column Name
INSERT
UPDATE

192. Checklist Migration

ดู:

README
Changelog
SQL Folder

193. Checklist Data

ตรวจ Existing Rowsก่อนแก้ทั้งหมด

194. Checklist Timezone

ทำหลังจาก Formatถูกแล้ว

ถามว่า:

Store UTC?
Store Local?
Convertตรงไหน?

195. ตัวอย่างสถานการณ์ที่ 1

Error:

Incorrect datetime value: '17/08/2026'
for column 'created_at'

สาเหตุมีแนวโน้มว่า Applicationส่ง Date Formatไม่ตรงกับสิ่งที่ Query/Columnคาดไว้

196. วิธีคิด

อย่าเปลี่ยน SQL Modeก่อน

แก้ Sourceให้ส่ง:

2026-08-17 00:00:00

ถ้า created_at เป็น DATETIME

197. ตัวอย่างสถานการณ์ที่ 2

Incorrect datetime value: ''
for column 'expires_at'

ตรวจว่า Permanent Recordควรใช้:

NULL

หรือ Representationอื่นตาม Resource

198. ตัวอย่างสถานการณ์ที่ 3

Incorrect datetime value: '0000-00-00 00:00:00'

ตรวจ:

SQL Mode
Legacy Schema
Default

โดยเฉพาะ zero-date behavior

199. ตัวอย่างสถานการณ์ที่ 4

Resourceส่ง:

1723900000

แต่ Columnเป็น:

DATETIME

อาจเป็น Version/Schema mismatch

200. ตัวอย่างสถานการณ์ที่ 5

Resourceส่ง:

2026-08-17T15:30:00.000Z

แต่ Query/Database Layerไม่ได้ Convertให้เข้ากับ Columnตามที่ Resourceออกแบบ

ควร Normalizeหรือใช้ Driver/APIที่ Resourceคาดไว้

201. ISO 8601 คืออะไร

Application APIsมักใช้รูปแบบเช่น:

2026-08-17T15:30:00Z

แต่ไม่ควรสมมติว่า SQL Columnจะรับ Application Stringทุกแบบโดยตรง

202. Application Layerควร Convert

แนวคิด:

ISO/API Date
↓
Application
↓
Database Date Value

203. อย่า Convertหลายรอบ

Timezone Bugมักเกิดเมื่อ:

UTC
→ Local
→ UTC
→ Local

โดยไม่รู้ว่าค่าปัจจุบันอยู่ Zoneไหน

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

ทำ Helper Functionกลางช่วยลด Formatไม่一致

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

function toSqlDate(date) {
  // validate and return YYYY-MM-DD HH:MM:SS
}

ควรใช้ Library/Implementationที่ตรวจ DateและTimezoneอย่างถูกต้อง

206. อย่าตัด Stringมั่ว

เช่น:

date.toISOString().slice(...)

โดยไม่เข้าใจว่า:

ISOเป็น UTC
Databaseต้องการ Timezoneอะไร

207. Ban Expirationต้องระวังมาก

ถ้าเวลาเหลื่อม:

Banอาจหมดเร็ว
Banอาจหมดช้า

208. Cooldownก็เหมือนกัน

Formatถูกแต่ Timezoneผิดยังสร้าง Gameplay Bugได้

209. Logsต้องใช้เวลา Consistent

เพื่อให้ Staffตรวจ Incidentได้ง่าย

210. created_atควรมีConsistency

Recordsทั้งหมดควรใช้ Strategyเดียวกัน

211. Database TimeกับServer OS Time

ไม่ควรสมมติว่าเหมือนกันโดยไม่ตรวจ

212. Container/Docker Environmentก็มีTimezoneของตัวเองได้

ถ้า Hostingใช้ Containerized Services

แต่แก้ Error 1292ให้เริ่มจาก Value/Schemaก่อน

213. SQL Modeเปลี่ยนถาวรอย่างไร

MariaDBสามารถกำหนด System Variablesผ่าน Configurationหรือ Runtimeตาม Scopeของ Variable และการเปลี่ยน Runtimeบางแบบอาจไม่คงอยู่หลัง Restart

214. อย่าแก้ Global SQL Modeบน Shared Hostingโดยไม่รู้ผล

อาจกระทบ:

Websites
Apps
Other Databases

ที่ใช้ MariaDB Instanceเดียวกัน

215. Session SQL Modeปลอดภัยกว่าหรือไม่

ผลกระทบจำกัดกว่า Globalในแง่ Scope

แต่ก็ไม่ใช่คำตอบถ้า Resourceส่ง Invalid Data

216. Resourceสร้างConnectionใหม่

Session Settingเดิมอาจ:

ไม่ติด Connectionใหม่

จึงไม่ควรใช้เป็น Patchชั่วคราวโดยไม่เข้าใจ

217. Config Databaseควร Version Controlไหม

สำหรับ Server Dev:

ควรเก็บ Schema/Migrations

เพื่อรู้ว่า Productionอยู่ Versionไหน

218. Migration Fileช่วยอะไร

เปลี่ยน Databaseจาก:

Version A
Version B

อย่างมีขั้นตอน

219. ALTER TABLEแบบสุ่มเสี่ยงที่สุดอย่างหนึ่ง

เพราะคุณอาจทำให้ Resourceอื่นที่ใช้ Tableเดียวกันพัง

220. Shared Tablesต้องระวัง

Framework/Resourcesหลายตัวอาจใช้:

users
players
owned_vehicles

ร่วมกัน

221. ก่อน Modify Columnควร Searchทั้งResources

ดูว่ามี Scriptใด Query Columnนั้นบ้าง

222. Column Renameเสี่ยง

ถ้า Scriptยัง Queryชื่อเก่า:

Unknown column

จะเกิด Errorใหม่แทน

223. Date Errorแก้แล้วอาจเจอ Errorถัดไป

เป็นไปได้ถ้า Database Migrationขาดหลายจุด

224. แก้ทีละ Error

ดีที่สุด

อย่าเปลี่ยน Schemaสิบอย่างพร้อมกัน

225. Testหลังแก้

ทำ Actionที่เคยทำให้ Error เช่น:

Login
Ban
Save Vehicle

แล้วตรวจ Console

226. ตรวจ Dataหลัง Testด้วย

อย่าดูแค่ Consoleไม่มี Error

ตรวจว่า Dateที่บันทึก:

ถูกจริง
เวลาไม่เหลื่อม

227. Example Verification

SELECT created_at
FROM users
ORDER BY created_at DESC;

เพื่อดู Recent Values

228. Queryต้องเปลี่ยน Tableตาม Serverจริง

อย่าคัดลอกชื่อ users ถ้า Resourceใช้ Tableอื่น

229. อย่ารัน SQLจากบทความแบบ Blind Copy

โดยเฉพาะ:

UPDATE
ALTER
DELETE

ควรเปลี่ยนให้ตรง Schema

230. SELECTปลอดภัยกว่าสำหรับตรวจเบื้องต้น

เพราะไม่เปลี่ยนข้อมูล

231. DELETEไม่ใช่วิธีแก้ Date Error

ลบ Rowอาจทำให้ Errorหายเฉพาะคน แต่ Root Causeยังอยู่

232. Characterใหม่อาจ Errorอีก

ถ้า INSERT Queryยังผิด

233. Temporary FixกับPermanent Fixต่างกัน

Temporary:

แก้ Rowหนึ่ง

Permanent:

แก้ Query/Schemaที่สร้าง Rowผิด

234. ถ้า Errorเกิดจาก Imported Legacy Data

Permanent Fixอาจต้อง:

Clean Dataเก่า
แก้ Import Process
Prevent Invalid Dataใหม่

235. ถ้า Errorเกิดจาก Resource Bug

ควร:

Update Resource
Patch Code

ไม่ใช่แก้ Databaseทุกครั้งที่ Playerเข้า

236. ถ้า Errorเกิดจาก Custom Code

เพิ่ม:

Validation
Logging

ก่อน Query

237. Log Valueก่อน Database

ตอน Debugอาจ Log:

created_at value = ...

แต่ระวังอย่า Log:

Password
Sensitive Tokens

238. Date Debugไม่จำเป็นต้องเปิดVerbose Loggingถาวร

เพราะ Logsอาจโตมาก

239. Production Loggingควรพอดี

บันทึก:

Error
Resource
Query Context

โดยไม่เปิดเผยข้อมูลลับ

240. Error 1292 ทำ Server Crashไหม

โดยทั่วไป Queryนั้นอาจ Fail

Resourceจะ Crashหรือไม่ขึ้นกับการ Handle Errorของ Code

241. Promise RejectionอาจทำResourceมีปัญหา

ถ้า JavaScriptไม่ Handle Database Error

แต่ไม่ใช่ MariaDB Errorทุกครั้งจะทำ Serverทั้งเครื่องล่ม

242. Lua Callbackอาจไม่ได้ Data

เมื่อ Query Fail

Resourceต้อง Handleกรณี Error

243. Fail-safe สำคัญ

เช่น Save Characterล้มเหลวไม่ควร:

Delete Data
Give Duplicate Reward

244. Transactionสำคัญกับหลาย Query

ถ้า Operationมี:

หักเงิน
เพิ่ม Asset
บันทึก Date

แล้วขั้น 3 Fail

อาจเกิด Partial Stateถ้าออกแบบไม่ดี

245. Date Errorอาจกระทบ Economyได้

ถ้า Transactionเกี่ยวกับ:

Purchase
Business
Vehicle

246. อย่ามอง Error 1292ว่าเป็นแค่ข้อความแดง

ต้องดูว่า Queryที่ Failทำหน้าที่อะไร

247. Errorใน Logging Tableอาจไม่กระทบ Gameplayมาก

แต่ Errorใน:

ownership
transactions
bans

อาจสำคัญมาก

248. Errorตอน Save Ban

อาจทำให้ Banไม่ได้ถูกบันทึก

ต้อง Verify

249. Errorตอน Save Purchase

อาจทำให้:

เงินหัก
Assetไม่เข้า

ถ้า Resourceไม่มี Transaction Protection

250. Errorตอน Save Cooldown

Playerอาจทำ Activityซ้ำได้โดยไม่ตั้งใจ

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

251. Errorตอน Save Last Login

อาจดูเล็ก แต่ Staff Logs/Activity Trackingผิด

252. Errorตอน Character Creation

อาจทำให้ Characterสร้างไม่เสร็จ

253. Errorตอน Registration

ตรวจ Default Date Columnsทั้งหมดใน Table

254. Errorหลังเพิ่ม Columnใหม่

ถ้า Column:

NOT NULL

แต่ Existing Rowsไม่มีค่าที่เหมาะสม

Migrationอาจ Fail

255. ADD COLUMNควรคิด Existing Data

ไม่ใช่แค่ New Records

256. Existing Rowsต้องได้ Defaultอะไร

ต้องขึ้นกับ Business Logic

257. Migrationที่ดีควรกำหนด Conversion

เช่น:

old value
new value

อย่างชัดเจน

258. Date Migrationควร Testกับหลาย Cases

Valid Date
NULL
Legacy Zero Date
Empty Value

259. ไม่ควร Testแค่ Rowเดียว

Production Dataมักมี Edge Cases

260. Edge Case คืออะไร

ข้อมูลที่ไม่ใช่ Caseปกติ เช่น:

Never Logged In
Permanent Ban
Old Account

261. Old Characterมักเป็นคนเปิดเผย Migration Bug

เพราะ Dataสร้างจาก Schemaเก่า

262. New Characterใช้ได้แต่Old Character Error

ให้ตรวจ Legacy Data

263. Old Characterใช้ได้แต่New Character Error

ให้ตรวจ:

New INSERT Query
Defaults

264. Errorเฉพาะหลัง Restart

อาจเกี่ยวกับ:

Resource Init
SQL Mode Session
Migration Script

265. SQL Mode Sessionอาจต่างหลังReconnect

ถ้า Applicationตั้ง Session Modeเอง

จึงต้องดู Connection Startup

266. Global SQL Modeเปลี่ยนแล้ว Existing Connectionอาจไม่ใช้ค่าใหม่ทันที

เพราะ Sessionมี Scopeของตัวเองตามการเชื่อมต่อ

267. อย่า Restart MariaDBบนProductionโดยไม่จำเป็น

Players/Applicationsอื่นอาจ Disconnect

268. Restart FiveM Resourceก่อน Database Server

ถ้าแก้เฉพาะ Code:

Resource Restartอาจพอ

แต่ทำเฉพาะเมื่อไม่กระทบ Active RPตาม Server Operation

269. Production Changeควรทำช่วงMaintenance

โดยเฉพาะ:

Schema Migration
Bulk Data Cleanup

270. Backupก่อน Maintenance

จำเป็นอย่างยิ่ง

271. Backupต้อง Restoreได้ด้วย

Backupที่ไม่เคยทดสอบ Restoreอาจไม่ช่วยเมื่อเกิดปัญหา

272. Export SQLก่อนแก้

สามารถทำผ่าน Toolที่ Hostingรองรับ

273. Backupเฉพาะ Tableได้ไหม

ได้

ถ้ารู้ว่าแก้ Tableใด

แต่ Full Backupอาจเหมาะกับ Migrationใหญ่

274. อย่าเก็บ Backupไว้ใน Public Web Folder

Database Dumpอาจมี:

User Data
Credentials/Identifiers

275. FiveM Databaseมีข้อมูลสำคัญ

จึงควรปกป้อง Backupเหมือน Production Data

276. Root Passwordไม่เกี่ยวกับ Error 1292

ถ้า Queryเชื่อม Databaseได้และได้รับ Error 1292:

Authenticationผ่านแล้ว

ปัญหาอยู่ระดับ SQL/Dataมากกว่า

277. Connection Refusedไม่ใช่ Error 1292

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

278. Access Deniedไม่ใช่ Error 1292

เป็น Credentials/Permissions

279. Unknown Columnไม่ใช่ Error 1292

เป็น Schema/Query Name

280. Duplicate Entryไม่ใช่ Error 1292

เกี่ยวกับ Unique Constraint

281. Incorrect datetime value = มุ่ง Date Valueก่อน

ทำให้ Troubleshootingเร็วขึ้นมาก

282. Flow แก้ปัญหาแบบมืออาชีพ

Read error
↓
Identify resource
↓
Identify query
↓
Identify column
↓
Inspect schema
↓
Inspect actual value
↓
Check migration/version
↓
Fix source
↓
Test
↓
Verify stored data

283. ถ้า Valueผิดให้แก้ Source

นี่มักเป็น Fixดีที่สุด

284. ถ้า Schemaผิดให้ Migration

อย่า Hardcode Workaroundใน Codeถ้า Schemaจริงผิด Version

285. ถ้า Existing Dataผิดให้ Data Migration

อย่าเปลี่ยน Applicationเพื่อรองรับข้อมูลเสียตลอดไป

286. ถ้า SQL Modeต่างให้เข้าใจสาเหตุ

อย่าปิด Modesทันที

287. ถ้าเป็น Third-party Resource

ตรวจ Versionที่ตรงกับ:

Framework
Database
Dependencies

288. Resourceเก่าอาจไม่ได้ออกแบบกับ Environmentใหม่

จำเป็นต้อง:

Update
Patch

289. อย่าดาวน์เกรด MariaDBทันที

เพียงเพราะ Resourceหนึ่ง Error

แก้ Compatibilityที่ Resource/Schemaมักยั่งยืนกว่า

290. Downgradeมี Risk

อาจกระทบ:

Security
Other Applications
Data Compatibility

291. ถ้า Resourceถูกเลิกพัฒนา

อาจต้อง:

Patchเอง
Replace Resource

แทนลดมาตรฐาน Databaseทั้งหมด

292. Custom Patchควร Document

บันทึก:

File
Line
Reason

เพราะ Updateครั้งหน้าอาจเขียนทับ

293. Gitช่วยได้ไหม

สำหรับ Server Developer:

ใช่

ช่วยติดตาม Code Changes

294. Database Migrationควรเก็บในRepository

ทำให้รู้ว่า Serverแต่ละ Environmentใช้ Schemaใด

295. ProductionกับDevelopmentควร Schemaตรงกัน

ไม่เช่นนั้น:

Devผ่าน
Production Error

ได้

296. Test Resourceก่อน Updateจริง

โดยเฉพาะ Resourceที่แตะ:

Players
Banking
Vehicles

297. Query Testควรใช้ Copy Database

ไม่ควรใช้ข้อมูล Productionจริงถ้าไม่จำเป็น

298. MariaDB Error 1292 เป็นปัญหาแก้ได้

ส่วนใหญ่ไม่ต้อง:

ลง FiveMใหม่
ลง GTAใหม่

เพราะปัญหาอยู่ฝั่ง Database/Resource

299. ล้าง FiveM Cacheช่วยไหม

สำหรับ Error SQL Incorrect datetime value:

โดยทั่วไปไม่ใช่จุดแรกที่ควรแก้

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

300. Restart PCช่วยไหม

ไม่แก้ Root Causeของ:

Invalid Date
Wrong Schema

301. Restart Serverช่วยไหม

อาจทำให้ Errorหายชั่วคราวถ้า Stateเปลี่ยน

แต่ถ้า Queryเดิมส่งค่าผิด:

Errorจะกลับมา

302. Reinstall Databaseช่วยไหม

ไม่ควรทำ

เพราะ Errorไม่ได้หมายความว่า MariaDBติดตั้งเสีย

303. เปลี่ยนHostช่วยไหม

ไม่ใช่คำตอบแรก

Environmentใหม่อาจยัง Errorถ้า Resourceส่งค่าเดิม

304. วิธีแก้ที่ดีที่สุด

ทำให้ Code, Schema และ Data ตรงกัน

305. หลัก 3 อย่าง

Code

ส่งค่าอะไร

Schema

คาดหวังค่าอะไร

Data

ค่าจริงคืออะไร

306. ถ้าสามอย่างตรงกัน Errorมักหาย

นี่คือ Coreของ Troubleshootingประเภทนี้

307. ตารางสรุปสาเหตุ

อาการ	ควรตรวจ
DD/MM/YYYY เข้า DATETIME	Date Format
`0000-00-00` Error	SQL Mode / Legacy Data
Empty String Error	NULL / Application Logic
Unix Timestampเข้า DATETIME	Schema / Conversion
Errorหลัง Resource Update	Migration
Errorเฉพาะ Old Character	Legacy Data
Errorทุก New Character	INSERT / Default
เวลาไม่ตรงแต่ไม่มี Error	Timezone

308. ตารางสรุปสิ่งที่ไม่ควรรีบทำ

วิธี	ปัญหา
ปิด Strict Mode	อาจซ่อน Invalid Data
DATETIME → VARCHAR	ทำ Date Logicยุ่ง
ลบ Table	เสี่ยงข้อมูลหาย
Import SQLทับ	เสี่ยง Schema/Dataเสีย
Delete Character	ไม่แก้ Root Cause
Clear FiveM Cache	ไม่ตรงจุดใน SQL Error

309. Quick Fixสำหรับ Developer

ถ้า Errorชัดว่า Codeส่ง Formatผิด:

แก้ Formattingที่ Code

ก่อนคิดถึง Database Config

310. Quick Fixสำหรับ Server Owner

ถ้าไม่ได้เขียน Resourceเอง:

Backup
ตรวจ Resource Version
ตรวจ SQL Migration
ตรวจ Issue/Documentationของ Resource
Update Resourceถ้ามี Fix

311. Quick Fixสำหรับ Legacy Database

Backup
หา Invalid Rows
Determine Correct Meaning
Convertเฉพาะ Rows
Fix Applicationไม่ให้สร้างใหม่

312. Quick Fixสำหรับ Zero Date

อย่าเปลี่ยน Zero Dateเป็น Dateสุ่ม

ต้องถามว่า:

จริง ๆ แล้ว Fieldนี้หมายถึง “ไม่มีวันที่” หรือ “มีวันที่แต่ข้อมูลหาย”?

313. ถ้าหมายถึงไม่มีวันที่

NULLอาจเหมาะกว่า หาก Schema/Applicationรองรับ

314. ถ้าข้อมูลควรมีวันที่จริง

ต้อง Recoverจาก Sourceอื่นถ้ามี

ไม่ควรสร้างค่าปลอมเพื่อให้ Queryผ่าน

315. Data Integrity คืออะไร

ความถูกต้องและสอดคล้องของข้อมูล

Errorจาก Strict Modeบางครั้งกำลังช่วยบอกว่า Data Integrityมีปัญหา

316. Errorไม่ใช่สิ่งที่ควรซ่อนทุกครั้ง

บาง Errorมีประโยชน์เพราะหยุดข้อมูลเสียก่อนถูก Save

317. FiveM Economyต้องการ Data Integrityสูง

โดยเฉพาะ:

Bank
Vehicles
Businesses

318. Ban Systemก็เช่นกัน

วันหมด Banผิดเพียงไม่กี่ชั่วโมงอาจสร้างปัญหากับ Moderation

319. Logsก็สำคัญ

Timestampผิดทำให้การเรียง Incidentผิด

320. Date Errorจึงควรแก้ให้ถูก

ไม่ใช่เพียงทำให้ Consoleหยุดแดง

321. FAQ — FiveM Error 1292 คืออะไร

คือ MariaDB Errorเกี่ยวกับค่าที่ไม่ถูกต้อง/ไม่สามารถตีความตามชนิดที่คาดไว้ โดย Code 1292 มี SQLSTATE 22007 และข้อความสามารถระบุค่าที่ผิดได้

322. Incorrect datetime value คืออะไร

หมายถึง MariaDBไม่สามารถยอมรับ Date/Time Valueในบริบทที่ Queryกำลังใช้ได้

323. Errorนี้เกิดจาก FiveM หรือ MariaDB

MariaDBเป็นฝ่ายรายงาน Error แต่ต้นเหตุอาจมาจาก:

FiveM Resource
SQL Schema
Existing Data
SQL Mode

324. Format DATETIMEควรเป็นอะไร

รูปแบบที่ชัดเจนและใช้กันทั่วไปคือ:

YYYY-MM-DD HH:MM:SS

โดย MariaDBมีชนิด DATETIME สำหรับเก็บข้อมูลวันและเวลา

325. DD/MM/YYYY ใช้ได้ไหม

อย่าพึ่งพาการ Parseรูปแบบ Local Dateใน Queryตรง ๆ

ควร Normalizeก่อนบันทึก

326. `0000-00-00` ทำไม Error

SQL Mode เช่น NO_ZERO_DATE สามารถส่งผลต่อการยอมรับ zero-date valuesได้

327. ปิด Strict Modeแล้วหายไหม

อาจทำให้ Behaviorเปลี่ยนในบางกรณี แต่ไม่ใช่ Fixที่แนะนำเป็นอันดับแรก เพราะ Non-strict Modeอาจปรับ Invalid Valuesและสร้าง Warningแทน Errorได้

328. ควรปิด STRICT_TRANS_TABLESไหม

ไม่ควรทำเพียงเพื่อซ่อน Error

ควรแก้:

Data
Query
Schema

ก่อน

329. `STR_TO_DATE()` ช่วยได้ไหม

ได้เมื่อคุณมี String Dateที่รู้ Formatชัดเจน เพราะฟังก์ชันนี้ใช้ Format Stringในการ Parseเป็น DATE/TIME/DATETIME

330. `NOW()` ช่วยได้ไหม

ได้ถ้า Fieldต้องการเวลาปัจจุบันของ Database:

NOW()

331. NULL ใช้แทนวันที่ว่างได้ไหม

ได้ถ้า:

Columnอนุญาต
Resourceรองรับ

และความหมายจริงคือไม่มีค่า

332. เปลี่ยน DATETIMEเป็นVARCHARได้ไหม

ทาง Technicalอาจทำได้ แต่ไม่ควรใช้เป็น Fixทั่วไปเพราะ Date Logicในอนาคตจะซับซ้อนขึ้น

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

ตรวจ:

Migration
New SQL Schema
Changelog

ก่อน

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

ตรวจ:

SQL Mode
Legacy Data
Schema Compatibility

335. Errorเกิดเฉพาะ Playerคนเดียวทำอย่างไร

ตรวจ Rowของ Characterนั้นว่ามี:

Invalid Date
Legacy Value

หรือไม่

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

ตรวจ:

Query
Defaults
Schema

เป็นอันดับแรก

337. Clear FiveM Cacheช่วยไหม

โดยทั่วไปไม่ใช่ Fixหลักของ MariaDB Incorrect Datetime Value

338. Restart FiveMช่วยไหม

ถ้า Queryยังผิด:

Errorจะเกิดอีก

339. ต้องลง MariaDBใหม่ไหม

ส่วนใหญ่ไม่จำเป็น

340. Databaseจะเสียไหม

Error 1292ไม่ได้แปลว่า Database Corrupt

341. ควร Backupก่อนแก้ไหม

ควรอย่างยิ่ง โดยเฉพาะก่อน:

ALTER
UPDATE
Migration

342. วิธีเช็ก SQL Mode

SELECT @@sql_mode;

MariaDB documentationกำหนด sql_modeเป็นกลไกควบคุมพฤติกรรม SQLหลายประเภท

343. วิธีเช็ก Table

SHOW CREATE TABLE your_table;

344. วิธีเช็ก Column

DESCRIBE your_table;

345. วิธีหา Root Causeเร็วที่สุด

ใช้ข้อความ Errorระบุ:

Resource → Query → Column → Actual Value

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

346. Error 1292 ควรแก้ตรงไหนก่อน

ถ้า Errorระบุ Date Valueผิดอย่างชัดเจน:

แก้ค่าที่ Applicationส่งก่อน

347. ปัญหาสำคัญที่สุดที่ต้องหลีกเลี่ยง

อย่าทำ:

Invalid Date
↓
Disable Validation
↓
Save Anyway

ควรทำ:

Invalid Date
↓
Fix/Reject Value
↓
Save Correct Data

สรุป FiveM MariaDB Incorrect Date/Datetime Value Error 1292

FiveM MariaDB Error 1292: Incorrect Date/Datetime Value เกิดเมื่อ Query ส่งค่าที่ MariaDB ไม่สามารถยอมรับตามชนิดข้อมูลหรือเงื่อนไขที่กำหนด โดยสาเหตุที่พบบ่อยคือ Date Format ผิด, Zero Date, Empty String, Unix Timestamp กับ DATETIME ไม่ตรงกัน, Schema ของ Resource คนละ Version หรือ SQL Mode ทำให้ข้อมูลที่ไม่ถูกต้องถูก Reject

MariaDBระบุ Error 1292เป็น ER_TRUNCATED_WRONG_VALUE พร้อม SQLSTATE 22007 และมี SQL Modeหลายแบบที่ส่งผลต่อการตรวจข้อมูลวันเวลา เช่น Strict Modeและ zero-date handling

แนวทางแก้ที่ควรจำคือ:

อ่านข้อความ Error → หา Column → ตรวจ Actual Value → ตรวจ Column Type → ตรวจ Query → ตรวจ Resource Migration → ตรวจ SQL Mode → Backup → แก้ต้นเหตุ → Testใหม่

สิ่งที่ comsiam แนะนำมากที่สุดคือ อย่าเริ่มจากการปิด Strict Modeหรือเปลี่ยน DATETIMEเป็น VARCHARเพียงเพื่อทำให้ข้อความ Errorหาย เพราะสิ่งที่ควรแก้จริงคือความสัมพันธ์ระหว่าง Code, Schema และ Data ให้ตรงกัน หาก Resourceต้องการ DATETIME ก็ควรส่ง Date Valueที่ถูกต้องเข้าสู่ Database

อีกหลักที่ comsiam แนะนำสำหรับ FiveM Server Production คือก่อนใช้ ALTER TABLE, Bulk UPDATE หรือ Clean Legacy Dates ให้ Backup Databaseก่อนเสมอ และหลังแก้ต้องตรวจทั้ง Consoleและข้อมูลที่ถูกบันทึกจริง เพราะการไม่มี Errorไม่ได้รับประกันว่า Timezone, Expiration หรือ Timestampที่เก็บอยู่ถูกต้องตาม Logicของ Resource