Saving an Image field with an image that has undeterminable dimensions throws PDOException.

I have the same problem, when I add new content shows me the following error

"PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'field_imagen_teaser_blog_width' in 'field list': INSERT INTO {field_data_field_imagen_teaser_blog} (entity_type, entity_id, revision_id, bundle, delta, language, field_imagen_teaser_blog_fid, field_imagen_teaser_blog_alt, field_imagen_teaser_blog_title, field_imagen_teaser_blog_width, field_imagen_teaser_blog_height) 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] => node [:db_insert_placeholder_1] => 54 [:db_insert_placeholder_2] => 54 [:db_insert_placeholder_3] => blog [:db_insert_placeholder_4] => 0 [:db_insert_placeholder_5] => und [:db_insert_placeholder_6] => 55 [:db_insert_placeholder_7] => [:db_insert_placeholder_8] => [:db_insert_placeholder_9] => 731 [:db_insert_placeholder_10] => 900 ) in field_sql_storage_field_storage_write() (line 448 of /home/paulydash/psyche.cl/modules/field/modules/field_sql_storage/field_sql_storage.module).".

The content is published but incorrectly

I get that too:
PDOException: SQLSTATE[HY000]: General error: 1366 Incorrect integer value: '' for column 'field_image_width' at row 1: INSERT INTO {field_data_field_image} (entity_type, entity_id, revision_id, bundle, delta, language, field_image_fid, field_image_alt, field_image_title, field_image_width, field_image_height) 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] => node [:db_insert_placeholder_1] => 44 [:db_insert_placeholder_2] => 44 [:db_insert_placeholder_3] => article [:db_insert_placeholder_4] => 0 [:db_insert_placeholder_5] => und [:db_insert_placeholder_6] => 105 [:db_insert_placeholder_7] => [:db_insert_placeholder_8] => [:db_insert_placeholder_9] => [:db_insert_placeholder_10] => ) in field_sql_storage_field_storage_write() (line 448 of /home/roadof/public_html/modules/field/modules/field_sql_storage/field_sql_storage.module).
This started popping up for me after moving the site and restoring the database, so I figure I screwed something up.....

Hmmm - after applying that patch, I received the following error message:

Notice: Undefined index: not null in field_sql_storage_field_storage_write() (line 434 of /home/roadof/public_html/modules/field/modules/field_sql_storage/field_sql_storage.module).
Notice: Undefined index: not null in field_sql_storage_field_storage_write() (line 434 of /home/roadof/public_html/modules/field/modules/field_sql_storage/field_sql_storage.module).

If you try to stuff bogus data in a field, it's normal that you end up with an exception. Everything works as designed here.

I got this error when trying to create a node that had an image field in it. The width and height values ended up being empty strings instead of nulls. I did try to figure out where the original error happens, with no success, so I decided to go with the added checks and filters.

Here's a patch made against D8 (as per http://drupal.org/node/767608), as well as a back-ported patch for D7 (they are practically identical). I added one more check to the fix, as I was getting notices from the original version (the ones mentioned in #4).

Renamed D7 patch file to allow test bot to ignore it.

Same issue with me. Checked status report there is no file system available putted the files system path and error gone.

Please don't change the version number. All core patches need to be created for the latest version (D8 at the moment) and backported to earlier versions. As such, this is a D8 bug that's just been backported to D7. See http://drupal.org/patch/submit for more information (under "Always post against the most recent development version").

I had the same bug, which has been fixed with the patch. I switch the priority to major, as it affects the current D7 version, and prevents integer fields from working well.

As previously mentioned, there is no bug in field_sql_storage_field_storage_write(). Something higher up the chain is not working properly, and this patch just hides the issue under the carpet.

Postponed until we have a way to reproduce the issue.

Thank you for your quick answer. Yes, that's what it seemed to me.
I tried to reproduce by doing this :

• Install a fresh Drupal 7.10, Standard profile
• Add a new Integer field to the Basic page content type and keep default settings (not required, no default value,...)
• Try to add a basic page without filling the integer field -> It works
• Add a minimum value of 0 and maximum of 100 to the field settings -> It works too
• Install Entity API 7.x-1.0-rc1 -> still OK
• Install Profiles2, reuse the integer field in the main profile type, and try to create a user with the integer field left blank -> OK
• Go to the edit profile page and save -> OK
• Add minimum and maximum settings -> OK

Hard to find a simple context where it fails. I had a bunch of contrib modules enabled, maybe one is guilty. I'll investigate further. For me it appeared when I tried to use field_attach API to insert my integer field, and I could not figure out why this error occured.

@BenStallings : Can you reproduce on a fresh install ? What was your use case ? Which form, which entity ?

@damien: I would disagree on there not being a bug in the field sql storage. The way I see it, a function should do _some_ checking on its input before executing the code. Even if it is (and it looks like it is) a misbehaving contrib module that's causing the problem, I'd rather not see a fatal SQL-level error message on a site after clicking on a few configuration options.

A better approach, in my opinion, would be to do the extra checks for the input data, not run the query if there's something wrong with the data, and then show a big red error message on the screen about something having gone horribly wrong. This way everything else at least would get to run normally.

I'm very sorry. For me it was a bad use of field_attach_submit($entity_type, $entity, $form, &$form_state). The values are not cleaned in $form_state as one could expect (the only parameter passed by reference), but in $entity (which actually, as an object, is always passed by reference).
Some contrib modules may have the same bad use of field_attach_submit, giving this kind of error.

I'll chime in that this patch works for 7.12. I also am using core only to submit a file in an image field. Before the patch I was seeing the identical errors to #3 above, of course with my own table and row names inserted for my image field. I've run the patch from #9 and the error is gone and files are saving correctly.

Are you for darned sure that we have to get this patch applied to D8 and D7 at the same time? D8 is a long way out at this point and this is a critical bug in D7 core that's breaking user data in a bad way. I'm punching up the priority, at least.

Instructions to reproduce in Drupal 7 are fine, but we need instructions to reproduce, none have been provided.

See http://drupal.org/node/767608 for how backports are handled.

The patch is not remotely RTBC, marking it as such and bumping priority without providing steps to reproduce will mean this takes more time to get fixed, not less.

I noticed this error on certain images I was uploading (same as in #1, #3, and #20) but NOT on other images. I'm reproducing the error on a FRESH 7.12 standard install.

Steps to reproduce the error:
1. Download the image I've attached to this post (this is critical)
2. Log in to your fresh install, click the "Add Content" link, and create a new Article
3. Enter a title and then browse for the image you just downloaded
4. Save the node (you won't see the image when you view the node)
5. Click the node's Edit tab (you'll see the file name/icon but again no image)
6. Save the node and you'll see the error

After saving the node with this image, I installed Devel and the image in question has NULL width and height values whereas other images show these values correctly. This leads me to believe there might be two bugs I'm observing here: one in an image-related core module and another more general bug which BenStallings stated in the initial post. It may just so happen that this image file is the key to unlocking both bugs in a sort of domino effect.

So can anyone else duplicate this on a clean install using my file and the instructions in #21?

I had same problem (as described in #1) with 7.12 after upgrading from drupal 6.22. Patch in #7 solves the issue for me.

I dunno if it helps, but I was able to reproduce this error on CentOS 6.2 by disabling the GD extension for PHP, and then using the Image module to attach and image to an Article content type. When I publish the article, I would get this same error.

Again, it was resolved by enabling the required GD extension.

GD was the issue for me as well. This seems to happen when cloning sites (and skipping the install process), so I suppose it isn't really a Drupal problem. Having the Image module check for the presence of GD would probably be overkill, and the Status Report will complain anyway if it isn't installed.

I wonder if this should be marked as closed (works as designed). What do people think?

GD PHP extension is installed and enabled for my configuration. I still get the error on a fresh install (not cloned). My 2 cents is to keep this active.

BTW, will someone please try my steps to reproduce in #21?? It takes no more than 5 minutes to install a fresh copy of D7 and 30 seconds to try and reproduce the error using those steps.

@Damien Tournoud: I have to agree with your assertion in #14 that the patch only hides the issue and doesn't solve the problem (at least from what i can observe).

I patched D7 from the patch in #7 and used my method in #21 to reproduce the error. No more error message, HOWEVER, I am unable to generate derivative images from this uploaded image, which was a byproduct of the "PDOException" error that this thread pertains to.

So in essence, there is something else going on and so far no one has been able to get to the root of it. If no one else has any ideas, i'm changing the status.

I've started getting these errors on a site that I'm trying to upgrade from 6.25 to 7.12. We just (today) got to the point of trying to create new content on the upgraded site, and our testers saw a fair number of errors reading "The website encountered an unexpected error. Please try again later." - this on a _new_ node. I haven't tried editing a node yet.

After checking the logs, I saw the following error message:

PDOException: SQLSTATE[HY000]: General error: 1366 Incorrect integer value: '' for column 'field_overlayflags_value' at row 1: INSERT INTO {field_data_field_overlayflags} (entity_type, entity_id, revision_id, bundle, delta, language, field_overlayflags_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] => 239779 [:db_insert_placeholder_2] => 240007 [:db_insert_placeholder_3] => media_asset [:db_insert_placeholder_4] => 0 [:db_insert_placeholder_5] => und [:db_insert_placeholder_6] => ) in field_sql_storage_field_storage_write() (line 448 of F:\sites\media-stage.59\modules\field\modules\field_sql_storage\field_sql_storage.module).

To my (non-expert) eyes, this looks like a similar error to that reported in #1 above. I should note that this is _not_ an image field, but an integer field, with a textfield widget. I previously saw this on two other fields, one another integer field and then on a location field. I got past the first two by setting default values on the fields (default lat/long in the case of the location field), and when the third field popped up I decided to stop chasing my tail.

The site in question is certainly not a clean install (~50 modules, hundreds of thousands of nodes) - I'm going to try and reproduce on a clean install, but wanted to at least speak up that I've seen something similar.

FWIW, I actually see two identical errors in the log - one marked as type 'node' and the other as type 'php'. Everything else about the entries is the same.

We just migrated our account to a new server and are getting the following error message when trying to save new content to a Block with an image.

PDOException: SQLSTATE[HY000]: General error: 1366 Incorrect integer value: '' for column 'field_image_width' at row 1: INSERT INTO {field_data_field_image} (entity_type, entity_id, revision_id, bundle, delta, language, field_image_fid, field_image_alt, field_image_title, field_image_width, field_image_height) 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] => node [:db_insert_placeholder_1] => 132 [:db_insert_placeholder_2] => 132 [:db_insert_placeholder_3] => new_hire [:db_insert_placeholder_4] => 0 [:db_insert_placeholder_5] => und [:db_insert_placeholder_6] => 161 [:db_insert_placeholder_7] => [:db_insert_placeholder_8] => [:db_insert_placeholder_9] => [:db_insert_placeholder_10] => ) in field_sql_storage_field_storage_write() (line 448 of /srv/www/htdocs/intranet/modules/field/modules/field_sql_storage/field_sql_storage.module).

Seems as though our permissions are the same for our drupal settings and server settings. The issue is specific to uploading and saving a new image. Any advice welcome. Thanks

I encountered the error identical to the one in #3 when I was trying to save a node on my local development environment. The site was cloned from the production server. As it turned out, the image attached to the node had not been copied correctly to the local server. Obviously, PHP/GD cannot determine the width and height of a non-existent image. That caused the missing integer value for field_data_field_image.field_image_width. Once I had correctly copied all files from the production server, the error disappeared.

Hope that helps anyone.

As hinted back in #14, this is not an issue with the field system. The previous posts identified this as the image module trying to set the width and height of the image to NULL or an empty string when the referenced file does not exist or the GD extension is not enabled.

This is done in image_field_presave(), so we should look at this and image_get_info().

Reassigning properly.

Thanks Damien.

I just did some more tests, trying if to bring back the error again. Simply deleting the image was not enough, but the following did work:

1. delete (or rename) the image attached to a chosen node (nid 48 in my case)
2. flush all image styles:
   drush image-flush
3. clear all caches (image size is cached in cache_field):
   drush cc all
4. in the field_data_field_[fieldname] table, set the field_[fieldname]_width and field_[fieldname]_width values to NULL:
   UPDATE field_data_field_image SET field_image_width = NULL, field_image_height = NULL WHERE entity_id='48';
5. do the same in the field_revision_field_[fieldname] table:
   UPDATE field_revision_field_image SET field_image_width = NULL, field_image_height = NULL WHERE entity_id='48';
6. now open node/48/edit and try to save it

This problem seems to be related to the change that happened in Drupal 7.9, when the width and height columns were added to the image field tables (see #1129642: Populate HTML image tags with dimension attributes (like D6 imagefield) without re-introducing I/O). Older entities, like nid 48 in my example, (ie. not edited under Drupal 7.9 or higher), have NULL in those columns. I believe that the error occurs if the image size cannot be retrieved from the database nor from the image itself.

I had the same issue with integer fields as described in #1. It happened with 2 separate content types on the same site. I had upgraded the site from D6 to D7. Patch in #9 fixed my issue and allowed me to continue working. Tried to get a D8 test site running, but there were too many major errors for me to deal with in my project's budget (not surprising...it's under heavy development right now).

This thread helped me come to the conclusion that upgrading can bring along too much cruft from the previous version and possibly cause hard-to-reproduce issues like this one. Upgrade problems happen despite all the effort developers put in to providing upgrade paths. As a result, for new upgrade projects, I put my effort toward migrating data from D6 to a newly built from scratch D7 version of the site. But BenStallings, your post is certainly understandable. Thanks for originally posting the issue! It saved me some time.

tagging.

I was having this same issue with some files. After realizing that the file names contained spaces I tried it with a URL of an image with no spaces in it's name and it seems to work fine. Perhaps there is a bug with files containing spaces in the file name?

I had this problem because GD was not installed on my server. Installing php-gd and restarting Apache got rid of the error.

IMHO this shouldn't cause an error since the size fields in the database are nullable (and therefore presumably optional). If GD isn't installed or if the Exif tag is blank it should just put null into the database. Just my $0.02.

for reproduce: http://drupal.org/node/1619796

patch from 9 for dtupal 7 fix warning but image don't precess correctly with ImageAPI Optimize (or Image Optimize) mudule

I just ran into this problem and like some of the others in the thread, it turned out my new server did not have GD installed. I installed it and the problem immediately disappeared.

Needs tests and a better string. I presume the test would try to upload a text file as an image.

Ops, didnt meant to demote.

#9 patch worked for me！

re #35 and #36
Same problem with integer fields, and list fields.

I solved it by resaving all fields for the content type with a problem, as it seems some settings were borked on D6 - D7 upgrade.

I'm seeing this with some integer fields, which I _think_ went through an upgrade from D6.

field_info_instance() on them yields:

[default_value] => Array(
   [0] => Array (
          [value] => '',  // empty string
          [_error_element] => 'default_value_widget][field_property_area][0][value'
    )
)

Once I've added a default value, saved, and removed it again:
[default_value] => NULL

Edit: There's already a CCK bug for this: #1431524: Problem afterwards with migrated integer or nodereference field when empty

#43: 1330952_43.patch queued for re-testing.

http://drupal.org/node/1427826 contains instructions for updating the issue summary with the summary template.

The summary may need to be updated with information from comments.

#9 works for me for drupal 7

I was going to write an issue summary, but reading through, it seems to me this is a dupe of #1546024: Drupal throws PDOException error when uploading certain images (or that is a dupe of this). I am going to close this and work on that issue. Please re-open if you think this issue is unrelated.

This issue is older and has 5x followers than the other one. So I think it should be the other way. I'm closing that issue.

i have to add that in my case it was not an image referencing a non-existing file but it was an entity reference field that was running me into this error... nevertheless the patch works and i can add (translated) nodes without this error again.

tagging: entity reference, node/add, translation, i18, PDOException: SQLSTATE[HY000]: General error: 1366 Incorrect integer value,
-> use patch from #9

Re #52, #53: The other issue does contain a patch that comes back green and is reported to solve the problem. The patch seems to take a different approach to fixing the bug. I hope someone who understands the problem better than I do can compare the various patches and suggest a way forward.

#9 Worked for me.

corrected is_int function to is_numeric

Updated issue summary.

OK, this issue has gone unfixed for way too long, most likely due to the confused nature of the problem and the difficulty in reproduction. So I'm going go try to lay it all out here so that the devs can finally commit a fix.

Ultimately, for both the Integer field and Image field sufferers, the problem stems from the fact that empty strings are sometimes being sent into nullable INT columns in the database. You can't store non-INT, non-null data in those columns, so the database thrown a PDOException. The patch in #7/#9 attempts to fix this by sanity checking the inputs for INT fields. While that's probably a good idea, it doesn't solve the original problem.

So why are empty strings being sent into these INT columns?

For image fields, the problem is described in detail by pingers in comment #1 on #1546024: Drupal throws PDOException error when uploading certain images. The Image field code is improperly checking the form values, by using !isset() instead of empty(). isset() returns TRUE for empty string, and that ultimately led these empty strings to get sent into the width and height INT columns in the database. The fix, as seen in the attached patches (I made a small edit to pingers' patch, and added a D7 backport), is to do the check using empty(), and to then explicitly set the width and height to NULL if image_get_info() fails.

You can see the attached patch in action by creating a fresh Drupal 7 install and performing these steps:
1) Add an Article node.
2) Add the attached Problem.jpg file to the Image field.
3) Click the Upload button on the Image field. (This step is essential! See pingers' explanation as to why.)
4) Click the Save button for the node form.
You'll see the PDOException get thrown due to '' being shoved into an INT field, and the node will not be created.
5) Apply the attached D7 patch.
6) Repeat steps 1-4.
The PDOException is not thrown, and the node is created successfully.

Unfortunately, I don't know what it is about Problem.jpg that causes this issue. Doing some JIT debugging shows that getimagesize() is returning FALSE, instead of returning an array of image metadata. But I don't know how to dig into getimagesize() to find out why it's failing.

As for Integer fields, I looked into the Number module to try to find a similar problem with data validation, but nothing obvious stuck out. At this point, though, any work on Number belongs in another issue.

Since the D8 patch failed testing, I downloaded and installed a D8 instance to see why. Looks like D8's image code has changed quite dramatically since pingers wrote his patch back in June 2012 (not surprising, I suppose), and the way he implemented this fix no longer applies.

Interestingly, though, a different change has apparently gone in somewhere else, which is preventing the PDOException from being thrown. When you attempt to attach Problem.jpg to an Image field in D8, you'll get an error message rather than an exception... but it's really not any more helpful, as you can see in the attached screenshot. D8 appears to be detecting that the empty width and height values are bad data, but since they're hidden form elements, the error highlights the wrong field, and thus gives a nonsensical message.

I tried adapting the patch to the new code in core/modules/image/image.field.inc (the fix goes in image_field_widget_process() now). But even with it correctly detecting empty strings and converting them to NULLs, D8 still throws the error: "This value should be of the correct primitive type." Even though NULL is a valid value for the height and width columns.

Hi coredumperror,

In the above patch is not working , kindly help me i have same error..

In the new D8 context, $image->isSupported() returns NULL for that image. That means Problem.jpg is not a valid image file according to GD2. In this case there's still a bug in the code because Drupal should return "Invalid image file" instead of setting width and height to NULL.

We should move in that direction and completely invalidate the form for such images.

I have added a image validation for drupal7 but it still needs test.

If you are still looking for a way to reproduce this, check out this sandbox issue: #2298841: PDOException on field_attach_update() using emtpy integer values.

I created a custom module that creates an $entity object and passes this to field_attach_update('user', $entity). I ran into the PDOException as stated in OP because I was directly getting the empty string from the integer field into the value field of my entity.

So, to reproduce this, you could create a minimal module which creates a malformed $entity object like described above. I'm not sure how to deal with that and I know this was discussed before, but shouldnt the field_sql_storage module be able to handle empty strings as NULL as proposed by the OP?

BTW this is not only affecting image fields, isnt it?

Edit, just rethinking the issue. This is quite a basic PHP->SQL issue, isnt it? For PHP an empty string '' is equal NULL, but passing '' (0 character string) to a mysql database is not handling the string as NULL (or 0) but as a string which triggers this PDOException.

Patch from #63 works for me on D7 but the wrong fields get a red border; the contrib "manual crop" selector and the core "add more" file selector.

Proposed solution will generate notice in the case if field schema allows null int values. I face this problem in the fivestar module.

Notice: Undefined index: target in field_sql_storage_field_storage_write() 

If you use this patch - better add isset check to the verfification string

correct:

<?php
if ($attributes['type'] == 'int' && !$attributes['not null'] && (isset($item[$column]) && !is_numeric($item[$column]))) {
?>

wrong:

<?php
if ($attributes['type'] == 'int' && !$attributes['not null'] && !is_numeric($item[$column])) {
?>

More better will be to fix module itself and do not touch drupal core.

This issue has many different aspects, but AFAICS at least the Image field part of it is now a duplicate of #2377747: Incorrect node create validation error when an invalid image is attached to a field, that has a patch and tests for D8. In current D8 HEAD, it is possible to upload an invalid(*) image file but then when submitting the form, you get the message reported in #60 and form submission fails, so the Image field does not get 'polluted'. But the file is anyway uploaded and the error message quite obscure. #2377747: Incorrect node create validation error when an invalid image is attached to a field fixes that in the direction indicated in #62.

(*) Invalid means: zero-size file, correct file extension but wrong content inside (i.e. rename a .txt file to .jpeg), toolkit not available, etc.

I had the same error and was solved enabling php gd library.

Whoa, this issue is a lot to digest!

I am unable to reproduce either the integer field or the image upload issue on 9.0.1. Steps provided below in case I missed something. I'm not going to close this because I believe it still needs to be fixed in D7 but can anyone confirm that these steps are correct and if so we can move the issue over to 7.x?

Integer steps:

1. Install Drupal
2. Add a 'Number (integer)' field to the article content type without a default value
3. Create a new article, leaving the integer field blank
4. Save
5. No errors - works as expected

Screenshot of node that was saved with empty value:

Image steps:

1. Install Drupal
2. Upload the 'Problem_3.jpg' file from #57 to the image field
3. Image uploads without an issue
4. Save
5. No errors - works as expected

Screenshot of image uploaded:

I followed the same steps given by pameeela in #81 on a 9.1.x site and a Drupal 7, 7.73-dev, site. On both sites I was unable to reproduce the error.

I do get the following error when uploading an invalid image file (a text file rename to .png). An idea I got from reading #70
PDOException: SQLSTATE[22007]: Invalid datetime format: 1366 Incorrect integer value: '' for column `db`.`field_data_field_image2`.`field_image2_width` at row 1: INSERT INTO {field_data_field_image2} (entity_type, entity_id, revision_id, bundle, delta, language, field_image2_fid, field_image2_alt, field_image2_title, field_image2_width, field_image2_height) 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] => node [:db_insert_placeholder_1] => 2 [:db_insert_placeholder_2] => 2 [:db_insert_placeholder_3] => article [:db_insert_placeholder_4] => 0 [:db_insert_placeholder_5] => und [:db_insert_placeholder_6] => 4 [:db_insert_placeholder_7] => [:db_insert_placeholder_8] => [:db_insert_placeholder_9] => [:db_insert_placeholder_10] => ) in field_sql_storage_field_storage_write() (line 514 of /var/www/html/modules/field/modules/field_sql_storage/field_sql_storage.module).

The above error is fixed by the patch in #2345695: Users are able to upload 0-byte images.

Thanks to everyone who worked diligently on this problem.

Based on the testing by myself and pameeela, this can be closed as outdated. The error for image files is being done in #2345695: Users are able to upload 0-byte images.

Thanks!