PDOException: SQLSTATE[22003] after entering large value in integer and decimal field

Hm. Not sure how we can predict the max int size allowed by the db in use, and catch errors at validation time.

I too am having this problem in d7 release. In my case I created an integer field for use as a user's cell phone number. When a user ads any number into the field (there is no minimum or maximum limit for testing purposes) this error appears:

PDOException: SQLSTATE[22003]: Numeric value out of range: 1264 Out of range value adjusted for column 'field_pcell_value' at row 1: INSERT INTO {field_data_field_pcell} (entity_type, entity_id, revision_id, bundle, delta, language, field_pcell_value) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6); Array ( [:db_insert_placeholder_0] => user [:db_insert_placeholder_1] => 1 [:db_insert_placeholder_2] => 1 [:db_insert_placeholder_3] => user [:db_insert_placeholder_4] => 0 [:db_insert_placeholder_5] => und [:db_insert_placeholder_6] => 4175228511 ) in field_sql_storage_field_storage_write() (line 425 of /myserverpath/httpdocs/modules/field/modules/field_sql_storage/field_sql_storage.module).

just discovered a similar problem after modifying the date of one of my articles.
i tried to change the date to 2008-07-21 20:55:47 +0100 but accidently ended up with 208-07-21 20:55:47 +0100 causing the following error:

PDOException: SQLSTATE[22003]: Numeric value out of range: 1264 Out of range value adjusted for column 'created' at row 1: INSERT INTO {node} (vid, type, language, title, uid, status, created, changed, comment, promote, sticky) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10); Array ( [:db_insert_placeholder_0] => 0 [:db_insert_placeholder_1] => podcast [:db_insert_placeholder_2] => de [:db_insert_placeholder_3] => Funkfabrik #06 [:db_insert_placeholder_4] => 1 [:db_insert_placeholder_5] => 1 [:db_insert_placeholder_6] => -55585890253 [:db_insert_placeholder_7] => 1295636367 [:db_insert_placeholder_8] => 2 [:db_insert_placeholder_9] => 0 [:db_insert_placeholder_10] => 0 ) in drupal_write_record().

we need to avoid exeeding integer range.

See http://drupal.org/node/159605 for a list of database types and common sizes. Maybe store the ISBN as text with a custom validator?

i agree storing isbn and phone numbers using an integer is not a good idea but in my case it was a malformed date (year 208) causing my drupal to throw this exception.

Also see this with one of the sites that got migrated from D6. Have not yet found time to dig into it though.

I'm having the same problem using Drupal 7.10 after delete an integer type field and make a new one with the same name but using decimal type. Here is the error message:

PDOException: SQLSTATE[22003]: Numeric value out of range: 1264 Out of range value adjusted for column 'field_superficie_unidad_value' at row 1: INSERT INTO {field_data_field_superficie_unidad} (entity_type, entity_id, revision_id, bundle, delta, language, field_superficie_unidad_value) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6); Array ( [:db_insert_placeholder_0] => node [:db_insert_placeholder_1] => 9 [:db_insert_placeholder_2] => 9 [:db_insert_placeholder_3] => unidad_vecinal [:db_insert_placeholder_4] => 0 [:db_insert_placeholder_5] => und [:db_insert_placeholder_6] => 1 ) en field_sql_storage_field_storage_write() (línea 448 de /data/sites/observatoriopen/modules/field/modules/field_sql_storage/field_sql_storage.module).

I have the same error.

This error still appears in the latest version D7.12, and not only in integer fields but also numeric fields like decimal.
Would be nice if this gets fixed soon.
Currently my site shows:
"The website encountered an unexpected error. Please try again later." and the error message above I found in the logs.

I'm seeing this in 7.12 with integer field too. Just try to enter 602527406183 in a normal integer field. Did I set up the field improperly maybe?

Hola:

El campo Número entero es un tipo de campo INT (integer) y su caracteristica en MySQL es que puede almacenar hasta 10 dígitos
( 4 Bytes = 4x8 = 32 bits ==> 4.294.967.296 valores); que esten en el intervalo entre -2.147.483.648 Y 2.147.483.647.

ES DECIR, si el numero es MENOR QUE < - 2.147.483.648 O MAYOR QUE > 2.147.483.647 ; NO CABE y ocurre un desbordamiento (overflow) y aparece dicho error

La solucion: Cambiar el tipo de datos a BIGINT (en la base de datos con PHPMYADMIN) que puede almacenar hasta 20 digitos
( 8 Bytes = 8x8 = 64 bits ==> 18.446.744.073.709.551.616 valores) que esten en el intervalo
entre - 9.223.372.036.854.775.808 Y 9.223.372.036.854.775.807

AUNQUE OCUPA EL DOBLE DE MEMORIA (doble memoria para el desempeño); PUEDE SER LA SOLUCIÓN

______________________________________________________________________________________________________

The integer field is a field type INT (integer) and feature in MySQL is that it can store up to 10 digits
(4 bytes = 4x8 = 32 bits ==> 4,294,967,296 values); who are in the range - 2.147 .483.648 and 2.147.483.647

THEN, if the number is less than < -2.147.483.648 OR GREATER THAN> 2.147.483.647; an overflow occurs and the error appears

The Solution: change the BIGINT data type (in DataBase with PHPMYADMIN)that can store up to 20 digits
(8 bytes = 8x8 = 64 bits ==> 18,446,744,073,709,551,616 values) who are in the range
from - 9,223,372,036,854,775,808 And 9,223,372,036,854,775,807

EVEN THOUGH , you need twice the memory ( Double memory for the performance ) MAY BE THE SOLUTION

#7 is a weird one, why would 1 be out of range for a decimal? Aside from that, the way to fix this IMO is to provide a min and max value in the field settings for int / decimal, default it to -2**31-1..2**31 and work from there. Ie: do not try to guess the size of the DB column, let the user tell us.

Thanks chx, i fixed the error message in #7 adjusting the minimun and maximun values in the configuration of the field in the "Manage Fields" and the "Manage Display" tabs. The values weren't the same in both cases and that caused an error in my case.

Let's have someone try to reproduce this issue on a clean install of D8. If it's reproducible, then let's add a test demonstrating the bug.

Ok I was able to reproduce so here's the steps needed :)

1. get a fresh install of drupal 8
2. click the link structure in the admin menu
3. find content type and click on it too
4. go to manage fields for any content type (it doesn't matter which)
5. look for the drop down menu for field types and find integer
6. enter in some text into the field label (doesn't matter what you put in) and click save
7. just save field settings (it doesn't give you any options anyways)
8. now that its saved you don't have to worry about anything else so go ahead and click content inside the admin menu
9. click add content
10. find the content that you added the field to
11. create that content with some unusually large number inside the number field (something bigger than trillions should do) and save it

that then displays the error ^^

Next up: test

It should have a validation that an int cannot be bigger than 2147483647.

If you use an ISBN or a telephone split up the field into multiple parts or use a text field. Int are useful to do calculation on. Telephone nrs and isbn nrs dont require calculations so ints are not needed.

Test + validation for PHP_INT_MAX

#20: testfortookbigint-1003692-20.patch queued for re-testing.

There are a couple of tiny unrelated styling issues but they look good.
Great work :).

And this is good to go :)

+++ b/core/modules/field/modules/number/lib/Drupal/number/Tests/NumberFieldTest.phpundefined
@@ -156,5 +155,27 @@ class NumberFieldTest extends WebTestBase {
+
+    //Create a node from the new node type and test the validations
+    //Int too big
+    $edit = array(
+      "title" => $this->randomName(),
+      'field_' . $field_name . '[und][0][value]' => PHP_INT_MAX + 10,
+    );
+
+    //Post a too big int
+    $this->drupalPost('node/add/' . $type, $edit, t('Save'));
+    $this->assertText($label . ': the value may be no greater than');
+
+    //Int too small
+    $edit = array(
+      "title" => $this->randomName(),
+      'field_' . $field_name . '[und][0][value]' => -PHP_INT_MAX - 10,
+    );
+
+    //Post a too big int
+    $this->drupalPost('node/add/' . $type, $edit, t('Save'));
+    $this->assertText($label . ': the value may be no less than');

The comments don't meet coding standards. Also is it necessary to do this with a drupalPost() - could we not test the field validation more directly than that?

+++ b/core/modules/field/modules/number/number.moduleundefined
@@ -121,6 +121,8 @@ function number_field_instance_settings_form($field, $instance) {
+ * - 'int_to_small': Int should not be smaller than -2147483647

Should be into_too, not into_to.

+++ b/core/modules/field/modules/number/number.moduleundefined
@@ -137,6 +139,18 @@ function number_field_validate($entity_type, $entity, $field, $instance, $langco
+          'message' => t('%name: the value may be no less than %min.', array('%name' => $instance['label'], '%min' => -PHP_INT_MAX)),

Trailing whitespace here.

How can you test a field validation error while not triggering validation? I always checked this by submitting the form.

The test should be able to call field_attach_validate() directly on an arbitrary $entity object, without going through an entity form submit.

I fixed syntax errors and some errors I had testing locally.

#27: d8-toobiginteger-1003692-27.patch queued for re-testing.

It seems that my core version wasn't up to date.I try again.

Just tried it, and I still get error.

When I enter ridiculously big int, I get the message:

Error message
num: the value may be no greater than 9223372036854775807.

After I enter that number, I get the same error as in the original issue report.

#31 Seems correct for me.

The original report was SQL error. With the patch you have a validation message error.

This is what the test verify. We verify if you have this error.

patch -p2 < d8-toobiginteger-1003692-31.patch -b
patching file modules/field/modules/number/lib/Drupal/number/Tests/NumberFieldTest.php
Hunk #1 FAILED at 27.
Hunk #2 FAILED at 36.
Hunk #3 FAILED at 138.
Hunk #4 FAILED at 156.
4 out of 4 hunks FAILED -- saving rejects to file modules/field/modules/number/lib/Drupal/number/Tests/NumberFieldTest.php.rej
patching file modules/field/modules/number/number.module
Hunk #1 FAILED at 121.
Hunk #2 succeeded at 171 with fuzz 1 (offset 34 lines).
1 out of 2 hunks FAILED -- saving rejects to file modules/field/modules/number/number.module.rej

#31: d8-toobiginteger-1003692-31.patch queued for re-testing.

What about decimal fields?

• Rerolled against latest HEAD.
• Replaced PHP_INT_MAX with a new constant NUMBER_MAX_INT which is hard coded to 2147483647. This addresses the problems on 64-bit systems as mentioned in #24 and #32.

Just a couple of code style things.

+++ b/core/modules/number/lib/Drupal/number/Tests/NumberFieldTest.phpundefined
@@ -36,7 +36,7 @@ public static function getInfo() {
+    $this->web_user = $this->drupalCreateUser(array('access field_test content', 'administer field_test content', 'administer content types', 'administer node fields','administer node display', 'bypass node access'));

Needs a space after the comma.

+++ b/core/modules/number/lib/Drupal/number/Tests/NumberFieldTest.phpundefined
@@ -163,5 +163,22 @@ function testNumberIntegerField() {
+      'field_' . $field_name . '[und][0][value]' => NUMBER_MAX_INT + 10,

As someone said earlier, do we need to test with +/-10 if +/-1 will suffice. Not sure how big a deal this is.

+++ b/core/modules/number/lib/Drupal/number/Tests/NumberFieldTest.phpundefined
@@ -27,8 +27,8 @@ class NumberFieldTest extends WebTestBase {
-      'name'  => 'Number field',
-      'description'  => 'Test the creation of number fields.',
+      'name' => 'Number field',
+      'description' => 'Test the creation of number fields.',
       'group' => 'Field types'
     );
   }

If this was wrong before, shouldn't it be fixed in it's own issue rather than here?

This looks like it could be related to a bug in the Debian package libapache2-mod-php5filter. I've reported it here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709023

My fix was to install the package libapache2-mod-php5 which then replaced libapache2-mod-php5filter.

In fact the package libapache2-mod-php5 should be used in preference to libapache2-mod-php5filter as on the package page for libapache2-mod-php5filter it even says 'Unless you specifically need filter-module support, you most likely should instead install libapache2-mod-php5.'

This has also been reported as a bug - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709027

It could also be related to https://bugs.php.net/bug.php?id=62507

For me any patch didn't help.
Simple case to reproduce problem - create decimal field, and insert value greater then specified integer part.
I.e. i have decimal(10,2) field, then any simple integer value longer then 8 digits cause PDO fatal error.
I think we should provide additional validation here to respect available length of integer and fractional parts.
So patch should compare not the how value is big or small, but length of components in case of decimal.

Patch does not apply any more.

Rerolled patch with needed changes from #2015691: Convert field type to typed data plugin for number module. Also addressed the remarks from #41. Setting to needs review to get test results, but this still needs work to address the remarks from @IRuslan in #43.

+++ b/core/modules/number/lib/Drupal/number/Tests/NumberFieldTest.php
@@ -205,5 +205,23 @@ function testNumberIntegerField() {
+}
\ No newline at end of file

Woops! Dreditor flags this as a big red warning :D

Added D8 error message.

Straight reroll.

Patch doesn't apply due to https://drupal.org/node/2218199

Patch attached. Also added NUMBER_MIN_INT, which its value is different (-2147483648) than NUMBER_MAX_INT (2147483647)

Go Grisendo!! Wish I was there with you guys :)

54: 1003692-54-number-int_too_big.patch queued for re-testing.

Still an issue, when I had accidentally gave the decimal field the same precision as scale this error appeared.

Was able to reproduce as well with a value of 259457056. I edited the actual DB field and that didn't seem to help.

I can still reproduce this issue in the following scenarios:

1) When having a field of type=integer, if you write more than 10 digits and then submit the form the error appears.
2) When having a field of type=decimal, if you write more digits than the precision digit that was configured for that field.

#11 yes, that was my problem, i did so and worked for me. thanks a lot :)

I checked the patch #54.

1. It may be better to change IntegerItem rather than NumericItemBase if the problem is only with Integer field.
2. It's better to not add global constants.

+define('NUMBER_MAX_INT', 2147483647);
+define('NUMBER_MIN_INT', -2147483648);

I'd like to propose an approach that changes the IntegerItem rather than NumericItemBase. But I'm not confident and would like someone to review this.

The Data types table can be useful here, I believe.

https://www.drupal.org/docs/7/api/schema-api/data-types

The patch #66 failed on some existing tests.

One was caused because I changed the error message without considering the side effect. Another was caused for the test for string input into an integer field.

I fixed the points and I hope this would work.

I'm sorry to mess up the issue. I forgot to change the test appropriately on #70... Here is another trial.

Back to needs review, since the failure if because the test only file.

+++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldType/IntegerItem.php
@@ -109,4 +126,58 @@ public static function generateSampleValue(FieldDefinitionInterface $field_defin
+        // 2^64 is large and cannot be always handled by PHP.

I think this comment could explain when this is a issue.

Hey guys, what is the workaround while this change comes to drupal 8.3?

You could apply the patch to your installation. The instructions are here: https://www.drupal.org/patch/apply

I applied the passing patch from #72 and tested in my Drupal 8.4 install. All tests passed and the code from the patch looks good

Needed a reroll as #72 no longer applies.

Weirdly I couldn't get an interdiff generated, I think because the previous patch didn't apply. But this is basically just an update using the new array syntax.

Thank you for reviewing and rerolling the patch.

I updated the patch #80 with changes like the following.

       $size_map = [
-        'normal' => 4294967296,
-        'tiny' => 256,
-        'small' => 65536,
-        'medium' => 16777216,
-        // 2^64 is large and cannot be always handled by PHP.
-        'big' => NULL,
+        'normal' => (PHP_INT_SIZE >= 4) ? 4294967295 : PHP_INT_MAX,
+        'tiny' => 255,
+        'small' => 65535,
+        'medium' => 16777215,
+        'big' => (PHP_INT_SIZE >= 8) ? 9223372036854775807 : PHP_INT_MAX,
       ];

Firstly, as dagmar told in comment #75, the comment // 2^64 is large and cannot be always handled by PHP and value NULL for 'big' was not so helpful and I replaced it to

        'big' => (PHP_INT_SIZE >= 8) ? 9223372036854775807 : PHP_INT_MAX,

because the value 2^64-1 should be used if it's supported, and PHP_INT_MAX should be used if not.

Secondly, the values 256, 65536 and 16777216 are not proper and should be changed to 255, 65535 and 16777215 (I used these values mistakenly).

The auto tests must pass :)

Thanks @hgoto.

If I ran this in my local environment:

echo PHP_INT_SIZE;
8

echo PHP_INT_MAX;
9223372036854775807

So tecnically PHP_INT_MAX == 9223372036854775807 when PHP_INT_SIZE >= 8. Therefore

'big' => (PHP_INT_SIZE >= 8) ? 9223372036854775807 : PHP_INT_MAX,

Seems redundant, isn't?

Also, Try I still see the getDefaultMaxValue a bit cryptic.

 /**
+   * Helper method to get the max value restricted by databases.
+   *
+   * @return int
+   *   The maximum value allowed by database.
+   */
+  protected function getDefaultMaxValue() {

• First, is the maximum value allowed by the database? Or is the maximum value supported by php.
• Secondly, you added the explanation of why did you used those numbers in the ticket but not on the code, so if someone try to understand why this was designed in this way, there is no clear explanation about what those numbers means.
• Finally, (PHP_INT_MAX >> 1),. Why is this? In general lines I think some comments should help to understand what this method is doing.

@dagmar thank you for your sharp review.

I understood it. I'm sorry, I had misunderstood that we need to make sure that the values to be used for the range check are properly recognized as integer values by PHP. One reason why I thought so is the following behavior of PHP.

PHP_INT_MAX < PHP_INT_MAX + 1;  // => false
PHP_INT_MAX == PHP_INT_MAX + 1;  // => true

Hence, I used complicated expressions to check if the literals can be recognized as integer by PHP.

I was wrong. As you think, such handling is not necessary, right?

As you may already know, we don't need to care if literals can be recognized as integers here because PrimitiveTypeConstraintValidator already checks if the value entered in an integer field is an integer or not.

Drupal\Core\Validation\Plugin\Validation\Constraint\PrimitiveTypeConstraintValidator:

/**
 * Validates the PrimitiveType constraint.
 */
class PrimitiveTypeConstraintValidator extends ConstraintValidator {

  use TypedDataAwareValidatorTrait;

  /**
   * {@inheritdoc}
   */
  public function validate($value, Constraint $constraint) {

    // ...

    if ($typed_data instanceof IntegerInterface && filter_var($value, FILTER_VALIDATE_INT) === FALSE) {
      $valid = FALSE;
    }

I'm going to revise the patch from #80.

I revised the patch #80 (The patch #81 was based on my misunderstanding and I restarted from #80...).

+  protected function getDefaultMaxValue() {
+    if ($this->getSetting('unsigned')) {
+      // Each value is (2 ^ (8 * bytes) - 1).
+      $size_map = [
+        'normal' => 4294967295,
+        'tiny' => 255,
+        'small' => 65535,
+        'medium' => 16777215,
+        'big' => 18446744073709551615,
+      ];
+    }
+    else {
+      // Each value is (2 ^ (8 * bytes - 1) - 1).
+      $size_map = [
+        'normal' => 2147483647,
+        'tiny' => 127,
+        'small' => 32767,
+        'medium' => 8388607,
+        'big' => 9223372036854775807,
+      ];
+    }

Points are as follows.

1. I added comments like // Each value is (2 ^ (8 * bytes) - 1). to each block to make the magic numbers easier to be understood.
2. I replaced 'big' => NULL to the proper number.
3. The max values for "unsigned" were wrong and I changed them.

I myself tested the allowed max values for each size with MySQL.

In addition, if it's OK, I'd like to add tests for boundary values of integer into the PrimitiveTypeConstraintValidatorTest because it's closely related to the integer field validation. Is it OK?

+    $data[] = [new IntegerData(DataDefinition::create('integer')), PHP_INT_MAX, TRUE];
+    $data[] = [new IntegerData(DataDefinition::create('integer')), ~PHP_INT_MAX, TRUE];
+    $data[] = [new IntegerData(DataDefinition::create('integer')), PHP_INT_MAX + 1, FALSE];
+    $data[] = [new IntegerData(DataDefinition::create('integer')), ~PHP_INT_MAX - 1, FALSE];

FYI, the changed test classes in this patch are as following.

• Drupal\field\Tests\Number\NumberFieldTest
• Drupal\Tests\serialization\Unit\Normalizer\PrimitiveDataNormalizerTest

Added validation for the decimal item as well. Not tested enough but seems to solve the problem.

Added a patch for 8.9.16 version.

Re-roll patch created for 9.3.x.

Fixed cs issue.

Fixed fail tests, Please have a look.

1. +++ b/core/modules/field/tests/src/Functional/Number/NumberFieldTest.php
   @@ -281,6 +281,79 @@ public function testNumberIntegerField() {
   +  public function testNumberIntegerFieldWithoutSettings() {
   

   We are only testing for the field size 'normal'. Could we add a @dataProvider method to also test for other sizes.

2. +++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldType/DecimalItem.php
   @@ -102,9 +102,67 @@ public function getConstraints() {
   +    return pow(10, $precision - $scale) -
   +      (1 / pow(10, $scale));
   

   Can we add some documentation about this calculation. What, why and how about the calculation.

3. +++ b/core/modules/field/tests/src/Functional/Number/NumberFieldTest.php
   @@ -281,6 +281,79 @@ public function testNumberIntegerField() {
   +  public function testNumberIntegerFieldWithoutSettings() {
   

   I this test we test the integer field changes. Can we also create a test for the decimal field?

4. +++ b/core/tests/Drupal/KernelTests/Core/TypedData/TypedDataTest.php
   @@ -618,7 +618,7 @@ public function testTypedDataValidation() {
   -    $this->assertEquals(1, $violations->count());
   +    $this->assertEquals(3, $violations->count());
        $this->assertEquals('0.value', $violations[0]->getPropertyPath());
   

   The number of violations goes up for 1 to 3. Only for the first violation do we test what the violation is about. Can we do the same for the 2 new violations.

5. +++ b/core/tests/Drupal/KernelTests/Core/TypedData/TypedDataTest.php
   @@ -661,7 +661,7 @@ public function testTypedDataValidation() {
   -    $this->assertEquals(1, $violations->count());
   +    $this->assertEquals(3, $violations->count());
   ...
        $this->assertEquals('string', $violations[0]->getInvalidValue());
        $this->assertSame('0.value', $violations[0]->getPropertyPath());
   

   The number of violations goes up for 1 to 3. Only for the first violation do we test what the violation is about. Can we do the same for the 2 new violations.

6. +++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldType/DecimalItem.php
   @@ -102,9 +102,67 @@ public function getConstraints() {
   +    $constraint_manager = \Drupal::typedDataManager()->getValidationConstraintManager();
   

   I think this line can be removed.

7. +++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldType/DecimalItem.php
   @@ -102,9 +102,67 @@ public function getConstraints() {
   +    $min = $this->getDefaultMinValue();
   +    if (!is_null($min)) {
   

   This can be done on a single line: if ($database_absolute_minimum = $this->getDefaultMinValue()) {. The changed variable better describes what it is for. Why test for !is_null? As the return value from the method is always an integer value. The same for the other 3 places.

Closed #1107666: Allow larger values for Integer field as a duplicate.

Updated the IS but it still needs, at least, the proposed resolution section fixed.

We applied #99 and while testing we noticed, that when you have a decimal(16,2) field and you want to give a higher number, we receive the following error message: "Field name: The integer must be smaller or equal to 1.0E+14." While the message clearly says that it can be equal, in reality, it can't. It must be smaller than the mentioned number.

Re-roll patch created for 9.5.x.

Re-roll patch created for 9.5.x.
Fix phpcs errors.

Re-roll patch created for 10.2.3

Looks like this might also be caused by #2230909: Simple decimals fail to pass validation?

(While I think if this is a real book ISBN, you should use a string anyway). Can anyone confirm this is a duplicate or not?

No, this is not a duplicate. It's related, but that one is kind of the opposite: Valid number do not pass validation due to an issue with the decimal validation. Here invalid (not mathematically/theoretically, but in practice because they do not "fit" in the database) numbers do pass validation but then blow up the DB.