FiveM MySQL Out of Range Value for Column Error 1264 แก้อย่างไร? ตรวจ INT, BIGINT, UNSIGNED และค่าตัวเลขเกินช่วง

August 17, 2026

ปัญหา FiveM MySQL/MariaDB ขึ้น Out of range value for column หรือ Error 1264 เกิดเมื่อ Resource ส่งค่าตัวเลขที่ ใหญ่เกินหรือเล็กเกินช่วงที่ Data Type ของ Column สามารถเก็บได้

ตัวอย่าง Error:

ERROR 1264 (22003): Out of range value for column 'money' at row 1

Out of range value for column 'amount'

Out of range value for column 'price'

Out of range value for column 'state'

Out of range value for column 'expires'

MariaDB ระบุ Error 1264 สำหรับกรณี Out of range value for column และ Numeric Types แต่ละชนิดมีช่วงค่าที่รองรับแตกต่างกัน.

ใน FiveM ปัญหานี้มักเกี่ยวกับข้อมูล เช่น:

เงินผู้เล่น
Bank Balance
Society Money
Vehicle Price
Item Price
Invoice Amount
Salary
Quantity
XP
Reputation
Job Grade
Vehicle State
Timestamp
Cooldown
Character ID
Transaction ID

หลักสำคัญคือ:

อย่าเห็น Error 1264 แล้วเปลี่ยนทุก Column เป็น BIGINT ทันที

เพราะบางครั้งค่าที่ใหญ่ผิดปกติเกิดจาก:

Script คำนวณผิด
seconds กับ milliseconds สลับกัน
คูณค่าซ้ำ
Economy Exploit
Negative Value เข้า UNSIGNED
Resource Version ไม่ตรง Schema

① Error 1264 คืออะไร

หมายถึงค่าตัวเลขที่ Database กำลังจะเก็บอยู่นอก Range ของ Column นั้น

เช่น:

Column รับสูงสุด = 100
ค่าที่ส่ง = 150

Database จึงไม่สามารถบันทึกค่าตาม Type เดิมได้อย่างถูกต้อง

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

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

Error 1366

ค่าที่ส่ง ไม่ใช่ตัวเลขที่เหมาะสม

เช่น:

grade = "boss"

แต่ Column เป็น INT

Error 1264

ค่าที่ส่งเป็นตัวเลขได้ แต่:

ใหญ่หรือเล็กเกิน Range

③ ตัวอย่าง

Column:

age TINYINT

แต่ Resource ส่งค่าที่เกิน Range ของ TINYINT

อาจเกิด Error 1264

④ Numeric Type มีหลายชนิด

MariaDB มี Integer Types หลายระดับ เช่น:

TINYINT
SMALLINT
MEDIUMINT
INT
BIGINT

แต่ละชนิดใช้พื้นที่และมีช่วงค่าต่างกัน.

⑤ INT คืออะไร

INT เป็น Integer Type แบบ 4-byte ใน MariaDB และมีช่วงค่าที่จำกัด ไม่ได้รองรับจำนวนเต็มทุกค่าที่ Application สามารถสร้างได้.

⑥ INT SIGNED รองรับเท่าไร

โดยทั่วไป INT แบบ Signed รองรับตั้งแต่ประมาณ:

-2,147,483,648

ถึง:

2,147,483,647

ส่วน UNSIGNED ใช้ช่วงที่ไม่ติดลบและขยายฝั่งบวกได้สูงกว่า.

⑦ UNSIGNED คืออะไร

UNSIGNED หมายถึง Numeric Column ที่ไม่ใช้ช่วงค่าติดลบ

เช่น:

money INT UNSIGNED

จึงไม่ควรเก็บ:

-100

⑧ Negative Value เข้า UNSIGNED

เป็นหนึ่งในสาเหตุสำคัญของ Out-of-range

ตัวอย่าง:

balance = -500

แต่ Column:

UNSIGNED

⑨ นี่ไม่ได้หมายความว่าต้องเอา UNSIGNED ออกทันที

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

Balance ควรติดลบได้ตามระบบจริงหรือไม่?

⑩ ถ้า Economy ไม่อนุญาตเงินติดลบ

การเกิด -500 อาจเป็น Bug ใน Logic

ควรแก้:

Calculation
Transaction Validation

มากกว่า Schema

⑪ BIGINT คืออะไร

BIGINT เป็น Integer Type 8-byte ที่รองรับช่วงตัวเลขกว้างกว่า INT อย่างมาก.

⑫ BIGINT Signed

MariaDB ระบุช่วง Signed BIGINT ตั้งแต่:

-9,223,372,036,854,775,808

ถึง:

9,223,372,036,854,775,807

และ Unsigned รองรับค่าบวกได้สูงขึ้นอีก.

⑬ เปลี่ยน INT เป็น BIGINT แก้ได้ไหม

ได้เฉพาะเมื่อ Business Requirement ต้องเก็บค่าที่ใหญ่จริง

ไม่ใช่ใช้ BIGINT เพื่อซ่อนค่าที่ผิดปกติจาก Bug

⑭ ตัวอย่างเงิน

ถ้า Resource ตั้งใจรองรับ Economy จำนวนมหาศาล:

5,000,000,000

อาจเกิน Signed INT

ในกรณีนี้ Schema Design อาจต้องรองรับ Range ที่กว้างกว่า

⑮ แต่ถ้าผู้เล่นควรมีเงินสูงสุดไม่ถึง 100 ล้าน

แล้ว Database ได้:

8,500,000,000,000

ควรสงสัย:

Bug
Exploit
Calculation Error

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

⑯ Society Balance ก็เหมือนกัน

Server ที่มี Business Economy อาจสะสมเงินจำนวนมาก

แต่ต้องกำหนด Range ที่สมเหตุสมผล

⑰ Vehicle Price

หาก Vehicle Price อยู่ใน:

INT

แต่ Config ใส่จำนวนมหาศาล:

Errorได้

⑱ Item Price

Item Shop Configอาจถูกพิมพ์ผิด

จาก:

เป็น:

50000000000

⑲ อย่าแก้ Databaseเพื่อรองรับ Typo

แก้ Configก่อน

⑳ Salary

Job Salary Configอาจถูกคูณผิด

เช่น:

salary × multiplier × multiplier

จน Valueโตเกิน

㉑ Error amountใน Banking

ถ้า Transfer Amount สูงเกิน Column Range:

Databaseอาจ Reject Transaction

㉒ Serverควร Validate Amountก่อน Database

เช่น:

มากกว่า 0
ไม่เกิน Balance
ไม่เกิน Limitที่ระบบกำหนด

㉓ Database Rangeไม่ใช่ Gameplay Limit

ตัวอย่าง:

Databaseรับได้ถึง:

2,147,483,647

ไม่ได้หมายความว่าควรให้ Playerโอนเงินได้สูงถึงจำนวนนี้

㉔ Gameplay Limitควรอยู่ใน Application

Database Typeเป็น Protectionอีกชั้น

㉕ Error Quantity

Inventory Quantityอาจถูกส่งเป็นจำนวนมหาศาลจาก:

Bug
Invalid Input
Resource Logic

㉖ อย่าเพิ่ม Quantity Columnเป็น BIGINTก่อนตรวจ

เพราะอาจเปิดทางให้ Inventory Stateผิดปกติยิ่งขึ้น

㉗ Item Stack Limit

ควร Validateตาม Inventory Resource

ไม่ใช่ Database Rangeอย่างเดียว

㉘ Error XP

XP Systemอาจสะสมค่าเกิน INTเมื่อ Serverเปิดมานานหรือ Formulaผิด

㉙ Reputationก็เช่นกัน

ต้องถามว่า:

XPควรมี Maxไหม
Level Formulaถูกไหม

㉚ Error Level

ถ้า Levelถูกคำนวณผิดจนกลายเป็นค่ามหาศาล:

การเพิ่ม Columnไม่แก้ Formula

㉛ Error Transaction ID

ถ้า IDถูกสร้างต่อเนื่องจำนวนมาก INT อาจถึง Limitในระบบขนาดใหญ่มาก

กรณีเช่นนี้ BIGINT อาจเหมาะกว่าตั้งแต่การออกแบบ Schema

㉜ AUTO_INCREMENTเต็มได้ไหม

ได้ในหลักการ เพราะ AUTO_INCREMENTยังอาศัย Data Typeของ Column

เมื่อ Rangeของ Typeหมดก็ไม่สามารถสร้างค่าใหม่ได้อย่างไม่มีขอบเขต

㉝ Log Tableมีโอกาสถึง Limitมากกว่า Players Table

เพราะ Logs/Transactionsสร้าง Rowsจำนวนมากต่อวัน

㉞ Player IDกับTransaction IDจึงอาจใช้ Typeต่างกัน

ไม่จำเป็นต้องใช้ INTเหมือนกันทุก Table

㉟ Error Timestamp

นี่เป็น Caseสำคัญมากใน FiveM

บาง Resourceเก็บเวลาเป็น:

Unix Seconds
Unix Milliseconds
DATETIME

㊱ Unix Seconds

ตัวเลข Timestampทั่วไปในระดับวินาทีมีจำนวนหลักน้อยกว่า Milliseconds

㊲ Unix Milliseconds

JavaScriptมักใช้เวลาเป็น Milliseconds

เช่นค่าลักษณะ:

17xxxxxxxxxxx

ที่ใหญ่กว่าค่า Secondsอย่างมาก

㊳ ส่ง Millisecondsเข้า INTอาจเกิน Range

ถ้า Columnถูกออกแบบเก็บ Unix Secondsเป็น INT

แต่ Codeใหม่ส่ง Milliseconds:

Error 1264อาจเกิด

㊴ อย่าเปลี่ยนเป็น BIGINTทันที

ก่อนถามว่า Resourceควรเก็บ:

seconds หรือ milliseconds

㊵ ตัวอย่าง Logic Bug

Schemaคาด:

seconds

Codeส่ง:

Date.now()

ซึ่งใน JavaScriptใช้ Milliseconds

นี่คือ Unit Mismatch

㊶ Fixที่ถูกอาจเป็น Conversion

ไม่ใช่ Schema

㊷ Ban Expiration ต้องระวัง

ถ้า Ban Resourceเก็บ:

expires

เป็น Unix Timestamp

ต้องรู้ Unitให้ถูก

㊸ Cooldownก็เหมือนกัน

Cooldown:

5 นาที

อาจถูกแปลงผิดเป็น:

milliseconds × 1000อีกครั้ง

ทำให้ Valueโตเกิน

㊹ Multiplication Bug

เช่น Codeมี:

duration * 1000 * 1000

แทน:

duration * 1000

Valueสามารถโตเร็วมาก

㊺ Error after JavaScript rewrite

Resourceเดิม Luaอาจใช้ Seconds

Resourceใหม่ JavaScriptใช้ Milliseconds

Databaseเดิมจึงไม่เข้ากัน

㊻ ตรวจ Resource Migration

Developerอาจเปลี่ยน Columnเป็น BIGINTใน Versionใหม่

ถ้าคุณ Update Codeแต่ไม่ได้ Migration:

Errorเกิดได้

㊼ Actual Schema vs Expected Schema

ใช้หลักเดิม:

Actual

Database Production

Expected

Schemaจาก Resource Versionที่กำลังใช้งาน

㊽ ตรวจ Schema

ใช้:

DESCRIBE your_table;

㊾ หรือ:

SHOW CREATE TABLE your_table;

㊿ หา Columnที่ Error

เช่น:

expires INT

จากนั้นดู Official SQLว่า Resourceต้องการ:

INT

หรือ:

BIGINT

51. ถ้า Official Schemaเป็น BIGINT

แต่ Productionเป็น INT:

Migrationอาจขาด

52. ถ้า Official Schemaเป็น INT

แต่ Resourceส่งค่าหลายล้านล้าน:

Code/Dataอาจผิด

53. นี่คือการแยก Root Causeที่สำคัญ

อย่า ALTERก่อนทำขั้นนี้

54. Error Signed vs Unsigned

ตัวอย่าง:

money INT UNSIGNED

รับค่าติดลบไม่ได้

55. Signed Column

สามารถรับค่าติดลบใน Rangeของ Type

แต่ถ้า Business Logicไม่ควรติดลบก็ยังต้อง Validate

56. Bank Overdraft

บาง Serverอาจอนุญาต:

ยอดติดลบ

บาง Serverไม่อนุญาต

นี่เป็น Gameplay Design

57. Schemaต้องสะท้อน Design

ถ้าต้องติดลบจริง:

UNSIGNEDอาจไม่เหมาะ

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

58. Cashมักไม่ควรติดลบในหลายระบบ

แต่ไม่ใช่กฎ FiveMสากล

59. Player Loan System

อาจแยก:

Balance
Debt

ออกจากกัน

แทนใช้ Negative Balance

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

60. อย่าปรับ Schemaตามความรู้สึก

ใช้ Resource Designจริง

61. SMALLINTคืออะไร

SMALLINT รองรับช่วงค่าที่เล็กกว่า INT และ MariaDBระบุว่าค่าเกิน Rangeภายใต้ Strict Modeจะเกิด Error.

62. SMALLINTเหมาะกับอะไร

ค่าที่รู้ว่ามีช่วงไม่ใหญ่ เช่นบาง Status/Level

แต่ต้องออกแบบตาม Requirement

63. TINYINT

ใช้พื้นที่น้อยกว่าและมี Rangeเล็กกว่า

เหมาะกับ Statesขนาดเล็กในหลาย Design

64. Vehicle Stateอาจใช้ TINYINT

เช่น Resourceบางตัวใช้ตัวเลขสถานะเพียงไม่กี่ค่า

65. แต่ถ้า Scriptส่ง 500เข้า TINYINT

อาจเกินช่วง

66. นี่ควรแก้ State Mapping

ไม่ใช่เปลี่ยน TINYINT→BIGINT

67. Stateควรมี Valuesจำกัด

เช่น:

stored
out
impounded

จำนวน Statesไม่ได้ต้องการตัวเลขหลายพันล้าน

68. Error Stateจึงมักบอก Mapping Bug

มากกว่าความต้องการ Rangeใหญ่

69. Job Gradeก็เช่นกัน

ถ้า Gradeปกติมี:

0–10

แต่ Databaseได้รับ:

ไม่ควรขยาย Typeเพื่อรองรับ

70. Server Validationควรเช็ก Allowed Range

เช่น:

grade >= minimum
grade <= maximum

ตาม Job Configจริง

71. Error Player Age

Character Age/Birth-year Systemsอาจใช้ Numeric Field

ถ้าค่าเกิน Range:

ตรวจ Character Creator Validation

72. Negative Ageคือ Bug

ไม่ควรแก้ด้วย Signed BIGINT

73. Error Hunger/Thirst

ถ้า Resourceใช้ Numeric Stateเช่น:

0–100

แต่ Calculationออก:

Formulaอาจผิด

74. Metadata Valuesอาจอยู่ JSON

ถ้าเก็บ JSONจะไม่เกิด Numeric Column Rangeใน Fieldย่อยโดยตรงจน Resourceแยกค่าไปใช้ SQLอื่น

75. Dedicated Numeric Columns

จะถูก Databaseตรวจ Rangeโดยตรง

76. Error Health/Armor

Custom Statistics Resourceอาจเก็บเป็น Numeric

ตรวจ Allowed Maximum

77. Error Weight

Inventory Weightอาจใช้ Integer

ถ้าน้ำหนักคำนวณรวมมหาศาล:

Item Configอาจผิด

78. Item Weight Typo

จาก:

เป็น:

100000000

สามารถทำ Total Weightโตเกิน

79. Error Mileage

Vehicle Mileageอาจเพิ่มไปเรื่อย ๆ

Serverระยะยาวควรเลือก Numeric Typeที่รองรับค่าที่คาดว่าจะเกิดจริง

80. Mileage Decimal

บาง Resourceใช้ Decimal/Floating Type

ดังนั้นอย่าเปลี่ยนจาก INTโดยไม่ดู Official Schema

81. Error Fuel

Fuel Valueมักอยู่ใน Rangeเล็ก

ถ้าได้ค่ามหาศาล:

Calculation/Sync Bugน่าสงสัย

82. Error Invoice ID

ระบบ Billingที่สร้าง Recordsจำนวนมากอาจต้องวาง ID Rangeเผื่อ Growth

83. Error Log ID

ยิ่งต้องคิดระยะยาว

เพราะ Serverอาจสร้าง Logsหลายล้าน Rows

84. BIGINTเหมาะกับ High-volume IDs

ในหลาย Architecture

แต่ต้อง Migrationอย่างถูกต้อง

85. Changing Primary Key INT→BIGINT

ไม่ใช่แค่เปลี่ยนหนึ่ง Columnเสมอไป

ถ้า Tablesอื่นอ้าง IDนั้น:

Foreign/reference Columnsอาจต้องรองรับ Typeเดียวกัน

86. อย่า ALTER Primary Keyโดด ๆ

โดยไม่ตรวจ Relations

87. Character ID Type Change

อาจกระทบ:

Vehicles
Housing
Phone
Banking

ถ้า Tablesเหล่านี้เก็บ IDเดียวกัน

88. Database Relationshipสำคัญ

Schema Migrationต้องมองทั้งระบบ

89. Backupก่อน ALTER

จำเป็นมากสำหรับ Numeric Type Migration

90. Tableใหญ่ ALTERอาจใช้เวลา

โดยเฉพาะ:

Logs
Transactions

ควรทำใน Maintenance Window

91. Production Playersไม่ควรทำ Transactionsระหว่าง Schema Migrationใหญ่

ลดความเสี่ยง Stateไม่ตรง

92. Errorหลัง Import Data

Source Databaseอาจใช้ BIGINT

Destinationใช้ INT

ข้อมูลบาง Rowsจึงไม่พอดี

93. Example

Source ID:

3000000000

Destination:

INT SIGNED

อาจเกิน Range

94. ต้อง Sync Schemaก่อน Import

ไม่ควรลด IDลงแบบสุ่ม

95. เปลี่ยน IDเพื่อให้พอดีอันตราย

Tablesอื่นอาจอ้าง IDเดิม

96. Database Merge

ยิ่งต้องระวัง ID RangeและCollision

97. Offset IDs

การบวกเลข Offsetในการ Mergeอาจทำให้ IDเกิน INT

98. Example

Server B IDsถูกบวก:

+ 2,000,000,000

บาง Recordsอาจเกิน Signed INT

99. Merge Planningต้องเลือก Data Typeก่อน

ไม่ใช่ค่อยแก้หลัง Import Fail

100. Error UNSIGNEDตอน Import

Sourceมี Negative Values

แต่ Destinationเป็น UNSIGNED

ต้องเข้าใจความหมายของ Negative Valuesก่อน Conversion

101. Negative Stateอาจเป็น Sentinel

บาง Legacy Systemsใช้:

-1

แทน Stateพิเศษ

ถ้า Schemaใหม่ UNSIGNED:

Migrationต้อง Mapใหม่

102. อย่าเปลี่ยน -1เป็น0โดยเดา

เพราะ State Meaningอาจต่าง

103. Migration Mappingต้องอิง Resource

104. Error after replacing garage resource

Garageเก่าอาจใช้:

-1
0
1

Garageใหม่ใช้:

0
1
2

Schema/State Mappingจึงต้อง Convert

105. Resource Replacementต้องมี Conversion Plan

ไม่ใช่เพียง Import SQLใหม่

106. Errorหลังเปลี่ยน Inventory

Count/Weight Typesอาจต่าง

107. Errorหลังเปลี่ยน Banking

Balances/Transaction IDsอาจใช้ Numeric Typeต่างกัน

108. Errorหลังเปลี่ยน Phone

Phone Numberบางระบบเก็บเป็น String

บางระบบอาจมี Internal Numeric IDแยก

109. Phone Numberไม่ควรเปลี่ยนเป็น INTเพียงเพราะประกอบด้วยตัวเลข

เพราะ:

Leading zero
Formatting

อาจมีความหมาย

110. เลขที่ดูเหมือน Numberอาจเป็น Identifier

เช่น:

0812345678

ไม่ใช่ Quantity

111. Database Typeต้องตาม Meaning

ไม่ใช่หน้าตาของข้อมูลอย่างเดียว

112. Vehicle Plateก็เช่นกัน

ถึง Plateบางคันเป็นตัวเลขทั้งหมดก็ยังควรเป็น Stringตาม Resource Design

113. Error 1264ไม่ควรแก้ด้วย VARCHARทุกครั้ง

เช่นเดียวกับไม่ควรแก้ทุกอย่างเป็น BIGINT

114. ต้องเลือก Typeตาม Domain

115. Strict Mode เกี่ยวอย่างไร

MariaDB ระบุว่าใน Strict Mode ค่าตัวเลขที่ Out-of-rangeสามารถทำให้ Statementเกิด Error ขณะที่เมื่อไม่ใช้ Strict Mode ระบบอาจปรับค่าเข้าหาค่าขอบเขตที่รองรับแล้วออก Warningแทน.

116. ตัวอย่างจาก MariaDB

เอกสาร INT และ BIGINT แสดงตัวอย่างค่าที่ต่ำหรือสูงเกินช่วงแล้วเกิด Warning/Error 1264ตาม SQL Mode.

117. ปิด Strict Modeดีไหม

ไม่ควรเป็น Fixแรก

118. เพราะ Databaseอาจ Clamp Value

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

ค่าจริง = 999999999999

แต่ Columnรับไม่ไหว

Non-strict behaviorบางกรณีอาจปรับไปที่ค่าขอบเขตแทนพร้อม Warning.

119. ทำไมอันตรายใน FiveM

Resourceอาจคิดว่า:

บันทึกเงิน 999999999999 สำเร็จ

แต่ Databaseเก็บค่าอื่น

120. Economy Stateจึงไม่ตรงกับ Application

121. Expiration Timeก็อันตราย

Timestampถูก Clampอาจทำให้:

Banหมดผิดเวลา
Cooldownผิด

122. จึงควรให้ Errorเกิดแล้วแก้ต้นเหตุ

ดีกว่าปล่อย Dataผิดเงียบ ๆ

123. วิธีตรวจ SQL Mode

SELECT @@sql_mode;

MariaDBใช้ sql_mode เพื่อควบคุม Strict Behaviorและการจัดการค่าที่ไม่ถูกต้องหลายประเภท.

124. อย่าแก้ Global SQL Modeเพื่อ Resourceเดียว

อาจกระทบ Databases/Applicationsอื่น

125. Errorหลังย้าย Hosting

Serverใหม่อาจใช้ Strict Modeต่างจาก Serverเก่า

Bugที่เคยถูก Clampเงียบ ๆ อาจเริ่มแสดง Error

126. นี่ไม่ใช่เหตุผลให้กลับไป Non-strictทันที

ควรแก้ค่าที่ผิด

127. วิธีตรวจ Actual Value

อ่านข้อความ Errorเต็ม

เช่น:

Out of range value for column 'balance' at row 1

จากนั้นดู Query/Parametersว่า:

balance = ?

ได้รับค่าเท่าไร

128. ถ้าเป็น 4,000,000,000

ตรวจ:

Column Type
Business Requirement

129. ถ้าเป็น -500

ตรวจ:

UNSIGNED
Transaction Logic

130. ถ้าเป็น Timestamp 13หลัก

ตรวจ:

Seconds vs Milliseconds

131. ถ้าเป็นเลขมหาศาลแบบสุ่ม

ตรวจ:

Overflowใน Application
Multiplication
Parsing

132. JavaScript Number มีข้อจำกัดของตัวเอง

Custom Developerควรระวังตัวเลขขนาดใหญ่มากก่อนถึง Databaseด้วย ไม่ใช่พึ่ง Databaseเพียงอย่างเดียว

133. JSON Numbersกับ BIGINT

ค่าที่ใหญ่มากอาจมี Precision Considerationsใน Application Layer

ดังนั้น IDsขนาดใหญ่มากบางระบบเลือกส่งเป็น Stringระหว่าง Layers

134. แต่ Database Columnอาจยังเป็น BIGINT

Architectureต้องออกแบบให้สอดคล้องกัน

135. อย่าเปลี่ยน IDเป็น Stringทั้งระบบเพราะ JavaScript Issueหนึ่งจุด

Resource RelationsและIndexesอาจได้รับผล

136. Use Official Resource Pattern

สำคัญที่สุดสำหรับ Third-party FiveM Scripts

137. Errorจาก Lua

Lua Number Representationขึ้นกับ Runtime

แต่ Root Cause Error1264ยังคือค่าที่ถึง MariaDBไม่พอดีกับ Column

138. ตรวจค่าก่อน Query

ไม่ว่าภาษาจะเป็น:

Lua
JavaScript
TypeScript

139. Server-side Range Validation

Developerควรกำหนด:

min
max

ตาม Business Rule

ก่อน Query

140. Example Money

แนวคิด:

if amount <= 0:
    reject

และอาจมี Maximum Transaction Limitตามระบบ

141. อย่าใช้ Database Maxเป็น Transaction Max

เพราะ Database Maxอาจใหญ่เกิน Gameplay Design

142. Example Grade

Gradeควรอยู่ในรายการที่ Job Configมีจริง

ไม่ใช่:

0–2,147,483,647

143. Example Vehicle State

Stateควรอยู่เฉพาะ Codesที่ Resourceรองรับ

144. Example Quantity

Quantityต้องไม่เกิน Inventory Rules

145. Range Validationป้องกันทั้ง BugและAbuse

โดยไม่ต้องเปิดเผยวิธี Bypass

146. Error 1264หลัง Item Dupe Bug

จำนวน Itemอาจเพิ่มผิดปกติจน Numeric Rangeเต็ม

การขยาย Columnจะทำให้ Dupeไปได้ไกลขึ้น

ต้องแก้ Duplication Logic

147. Errorหลัง Economy Exploit

หลักเดียวกัน

อย่าเพิ่ม Money Rangeเพื่อรองรับค่าที่ไม่ควรเกิด

148. ตรวจ Logsก่อน Clean Data

เพื่อหาว่า Valueผิดเกิดเมื่อไร

149. อย่า Reset Player Moneyทั้งหมด

ถ้ามีเพียง Recordเดียวผิด

150. Selectเฉพาะ Recordที่เกี่ยว

ก่อน Update Production

151. Backupก่อน Data Cleanup

สำคัญ

152. อย่า Bulk UPDATEแบบเดา

เช่น:

UPDATE users
SET money = 0;

จะกระทบทุกคน

153. ตรวจ Rowsก่อน

ใช้ SELECTตาม Schemaจริง

154. Error `at row 1`

ไม่ได้หมายความว่า:

primary id = 1

เสมอไป

หมายถึง Rowใน Statement/Operationที่รายงาน

155. Bulk INSERTอาจ Errorเฉพาะ Rowหนึ่ง

ดูค่าของ Rowนั้น

156. Error CSV Import

อาจมี Amountหนึ่ง Cellเกิน Range

157. Data Migrationใหญ่

ควรหาค่าสูงสุด/ต่ำสุดก่อนเปลี่ยน Type

158. MAX()

สามารถช่วยดูค่ามากสุดของ Numeric Columnใน Dataที่มีอยู่

159. MIN()

ช่วยดูค่าต่ำสุด

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

SELECT MIN(amount), MAX(amount)
FROM transactions;

ใช้กับ Tableจริงหลัง Backup/Inspectionตามความเหมาะสม

161. ก่อนเปลี่ยน BIGINT→INTยิ่งต้องตรวจ

เพราะ Existing Dataอาจไม่พอดี

162. ลด Typeเสี่ยงกว่าขยายในแง่ Range

แต่ทั้งสองยังมีผลด้าน Schema/Indexes

163. UNSIGNED Conversionก็ต้องตรวจค่าติดลบ

ก่อน ALTER

164. Checklist Error1264

อ่าน Errorเต็ม
หา Column
ดู Actual Value
ดู Column Type
เช็ก Signed/Unsigned
ตรวจ Resource Logic
ตรวจ Unit
ตรวจ Migration
Backup
แก้ Root Cause

165. Checklist Amount/Money

Valueเท่าไร
Negativeหรือไม่
Column INT/BIGINT?
Signed/Unsigned?
Scriptคำนวณถูกไหม?

166. Checklist Timestamp

Seconds?
Milliseconds?
INT?
BIGINT?
Resource Version?

167. Checklist Vehicle State

Allowed State Codes?
Config Mapping?
Resource Migration?

168. Checklist XP

Formula?
Max?
Legacy Data?

169. Checklist IDs

AUTO_INCREMENT?
INT Range?
High-volume Table?
Referenced by other Tables?

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

เปลี่ยนทุก INTเป็นBIGINT
เอา UNSIGNEDออกทุก Column
ปิด Strict Mode
Clamp Valuesใน Codeโดยไม่แจ้ง
Resetข้อมูลทั้ง Table
ลบ Database

171. Clampคืออะไร

การบังคับค่าเกิน Maxให้กลายเป็น Max

เช่น:

999 → 100

ถ้า Limitคือ100

172. Clampเหมาะบาง Gameplay State

เช่น Hungerที่ต้องอยู่ 0–100

173. แต่ไม่เหมาะทุก Data

Transaction Amountที่ถูก Clampเงียบ ๆ อาจสร้าง Money Bug

174. ValidationกับClampต่างกัน

Validate

ค่าผิด → Reject

Clamp

ค่าผิด → ปรับให้อยู่ Range

ต้องเลือกตาม Business Logic

175. Vehicle Fuelอาจ Clampได้

หาก Resource Designตั้งใจ

176. Bank Transferควร Rejectค่าผิดมากกว่าในหลายระบบ

เพื่อให้ Playerรู้ว่า Transactionไม่ถูกต้อง

177. Identifierไม่ควร Clamp

IDต้องคงความเป็นเอกลักษณ์

178. Timestampไม่ควร Clampสุ่ม

จะเปลี่ยนเวลา Event

179. Error after Database Restore

ถ้า Codeใหม่ใช้ BIGINTแต่ Backup Schemaเป็น INT:

1264เกิดได้

180. Error after Resource Rollback

ตรงกันข้ามก็ได้

Schemaใหม่อาจรองรับ แต่ Codeเก่าสร้าง Unitผิด

181. Version Compatibility

ต้องดูทั้ง:

Code
Schema
Existing Data

182. Error after MySQL/MariaDB migration

ตรวจ Numeric Type Definitionsและ SQL Modeใน Environmentใหม่

183. INT Rangeไม่ได้เปลี่ยนเพราะ FiveM

Rangeกำหนดโดย Database Type.

184. BIGINTไม่ได้ทำ Serverเร็วขึ้น

มีไว้รองรับ Rangeที่ต่างกันและใช้ Storageต่างกัน

อย่าเลือกเพราะคิดว่า “ใหญ่กว่าดีกว่า”

185. Data Typeเล็กมีประโยชน์

ช่วยบอก Domain Rangeและลด Storageในหลายบริบท

186. TINYINTสำหรับStateอาจถูกต้องมากกว่า BIGINT

ถ้ามีเพียงไม่กี่ States

187. Database Designควรสื่อความหมาย

ไม่ใช่เลือก Typeใหญ่สุดทุก Column

188. Error1264จึงอาจเป็นสัญญาณว่า Dataผิด

ไม่ใช่ Schemaเล็กเสมอไป

189. Quick Diagnosis Matrix

อาการ	จุดที่ควรตรวจ
เงินจำนวนมาก Error	INT Range / Economy Logic
ค่าติดลบ Error	UNSIGNED / Calculation
Timestamp Error	seconds vs milliseconds
State Error	State Mapping
Grade Error	Config / Range
หลัง Update	Migration
หลัง Restore	Schema Version
เฉพาะ Playerเดียว	Abnormal Data
ทุก Player	Code/Schemaระดับระบบ

190. Error 1264 FAQ

FiveM Out of range value for column คืออะไร

หมายถึงค่าตัวเลขที่ Resourceส่งมีค่าต่ำหรือสูงเกินช่วงที่ Numeric Columnรองรับ โดย MariaDBใช้ Error 1264 สำหรับกรณีนี้.

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

1366มักเกี่ยวกับค่าที่ไม่เหมาะกับ Field เช่น Stringเข้า Integer ส่วน 1264หมายถึงค่าตัวเลขอยู่นอก Rangeที่ Typeรองรับ

INT เต็มได้ไหม

ได้ เพราะ INT มีช่วงค่าจำกัด.

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

ได้เมื่อ Resource/Schema Designต้องรองรับ Rangeที่ใหญ่กว่า เพราะ BIGINTมีช่วงกว้างกว่า INTมาก.

ควรเปลี่ยนทุก INTเป็นBIGINTไหม

ไม่ ควรใช้ Typeตาม Requirementจริง

UNSIGNEDคืออะไร

Numeric Typeที่ใช้ช่วงค่าที่ไม่ติดลบ การส่งค่าติดลบสามารถกลายเป็น Out-of-rangeได้.

Moneyติดลบแล้ว Errorทำอย่างไร

ตรวจว่า Serverอนุญาต Negative Balanceหรือไม่ ถ้าไม่ควรติดลบให้แก้ Transaction Logic

เงินเกิน 2พันล้านทำอย่างไร

ตรวจว่า Columnเป็น Signed INTหรือไม่ และตรวจว่าค่าขนาดนั้นเป็น Requirementจริงหรือ Bugก่อนเปลี่ยน Schema.

Timestampทำ Error1264ได้ไหม

ได้ หาก Resourceส่งค่าที่ใหญ่เกิน Column เช่นใช้ Millisecondsใน Fieldที่ออกแบบสำหรับค่าขนาดเล็กกว่า

Unix Timestampควรใช้ INTหรือBIGINT

ขึ้นอยู่กับ Representationและ Resource Design โดยเฉพาะว่ากำลังเก็บ SecondsหรือMilliseconds

Date.now()ต้องระวังอะไร

ใน JavaScriptค่าที่ได้เป็น Milliseconds จึงไม่ควรสมมติว่าเท่ากับ Unix Secondsที่ Schemaเดิมอาจใช้

Vehicle State Error1264ทำอย่างไร

ตรวจ State Codeที่ Resourceรองรับ ไม่ควรขยาย Numeric Typeเพียงเพื่อรองรับ Stateผิด

Grade Error1264ทำอย่างไร

ตรวจ Job Grade Rangeและ Config

Quantity Error1264ทำอย่างไร

ตรวจ Inventory Validationและค่าที่ Resourceสร้าง

XP Error1264ทำอย่างไร

ตรวจ XP Formulaและ Data Type

Transaction IDเต็มทำอย่างไร

High-volume Tablesอาจต้องใช้ Numeric Typeที่มี Rangeกว้างกว่า แต่ควรวาง Migrationอย่างถูกต้อง

BIGINT รองรับเท่าไร

MariaDB ระบุ Signed BIGINTประมาณ ±9.22×10^18 และ Unsignedสูงสุดประมาณ 1.84×10^19.

Strict Modeเกี่ยวไหม

เกี่ยว MariaDBระบุว่า Out-of-range valuesภายใต้ Strict Modeสามารถเกิด Error ส่วน Non-strict modeอาจปรับค่าแล้วออก Warning.

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

ไม่ควรเป็น Fixหลัก เพราะอาจทำให้ Databaseปรับค่าที่ผิดแทนการบอก Error ซึ่งสามารถทำให้ Applicationกับ Databaseมีค่าคนละอย่าง.

Clear FiveM Cacheช่วยไหม

โดยทั่วไปไม่ใช่ Fixของ Numeric Range Errorฝั่ง Database

Restart MariaDBช่วยไหม

ไม่ ถ้าค่าที่ส่งยังเกิน Rangeเดิม

Restart FiveMช่วยไหม

ไม่แก้ Logicเดิม แต่หลังแก้ Resourceอาจต้อง Reloadตามระบบ

ต้อง Reinstall Databaseไหม

ไม่

Error1264ส่วนใหญ่ต้องแก้:

Value
Calculation
Numeric Type
Migration

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

ตรวจ Official Migrationและ Schemaของ Versionใหม่

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

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

Errorเกิด Playerเดียว

ตรวจค่าของ Playerนั้น เช่น Money, XPหรือ Metadata-derived Numeric State

Errorเกิดทุกคน

ตรวจ Code/Config/Schemaระดับระบบ

ต้อง Backupก่อนเปลี่ยน INTเป็นBIGINTไหม

ควรอย่างยิ่ง โดยเฉพาะ Core Tablesหรือ Columnsที่ถูกอ้างจาก Tablesอื่น

สรุป FiveM MySQL Out of Range Value for Column Error 1264

FiveM MySQL/MariaDB Error 1264 Out of range value for column เกิดเมื่อ Resource ส่งค่าตัวเลขที่สูงหรือต่ำเกินช่วงที่ Numeric Data Type ของ Column รองรับ โดย MariaDB มี Numeric Typesหลายระดับตั้งแต่ TINYINT ไปจนถึง BIGINT และแต่ละชนิดมี Rangeแตกต่างกัน.

เมื่อเจอ Error นี้ให้ตรวจ:

Error 1264
↓
Column ไหน?
↓
Actual Value เท่าไร?
↓
INT / BIGINT / TINYINT?
↓
SIGNED หรือ UNSIGNED?
↓
ค่าควรใหญ่ขนาดนั้นจริงไหม?
↓
Unit ถูกไหม?
↓
Resource กับ Schema ตรง Versionไหม?
↓
แก้ Root Cause

สิ่งที่ comsiam แนะนำคืออย่าเห็นตัวเลขเกิน Rangeแล้วเปลี่ยน INT เป็น BIGINTทันที เพราะ FiveM Resourceอาจกำลังสร้างค่าผิดตั้งแต่ต้น เช่นเงินถูกคูณซ้ำ, Quantityผิดปกติ, Vehicle Stateผิด หรือ Timestampถูกส่งเป็น Millisecondsทั้งที่ระบบเดิมคาด Seconds การขยาย Columnในกรณีเหล่านี้เพียงทำให้ Databaseรับ Bugที่ใหญ่กว่าเดิม

อีกหลักที่ comsiam แนะนำคือถ้า Official Schemaของ Resource Versionใหม่กำหนด BIGINTจริง แต่ Productionยังเป็น INT นั่นจึงเป็นเหตุผลที่เหมาะสมในการตรวจ Migrationและเปลี่ยน Schemaอย่างเป็นระบบ โดยควร Backup Databaseก่อน ALTER TABLE, ตรวจ Columnsที่อ้าง IDเดียวกัน และทดสอบ Featureเดิมหลัง Migration ไม่ควรปิด Strict Modeเพื่อซ่อน Error เพราะ MariaDBสามารถปรับค่าที่อยู่นอก Rangeเป็นค่าขอบเขตพร้อม Warningใน Non-strict behaviorได้ ซึ่งเสี่ยงทำให้ข้อมูลในเกมไม่ตรงกับค่าที่ Resourceตั้งใจบันทึก.