| Project: | Apps |
| Version: | 7.x-1.0-beta7 |
| Component: | Documentation |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (duplicate) |
Issue Summary
I am encountering the following error from OpenEnterprise when I click on the apps menu.
PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'public://apps/webform_screenshot_21.png' for key 2: UPDATE {file_managed} SET uid=:db_update_placeholder_0, filename=:db_update_placeholder_1, uri=:db_update_placeholder_2, filemime=:db_update_placeholder_3, filesize=:db_update_placeholder_4, status=:db_update_placeholder_5, timestamp=:db_update_placeholder_6 WHERE (fid = :db_condition_placeholder_0) ; Array ( [:db_update_placeholder_0] => 1 [:db_update_placeholder_1] => webform_screenshot.png [:db_update_placeholder_2] => public://apps/webform_screenshot_21.png [:db_update_placeholder_3] => image/png [:db_update_placeholder_4] => 7390 [:db_update_placeholder_5] => 1 [:db_update_placeholder_6] => 1345765955 [:db_condition_placeholder_0] => 28 ) in drupal_write_record() (line 7013 of /hermes/bosweb25b/b954/whl.studioandfxlab/DrupalEnterprise/includes/common.inc).
The website encountered an unexpected error. Please try again later.
Comments
#1
Keep bumping into that one as well
#2
Getting the same error. Completely reinstalled, updated all modules, cleared caches, etc. Still same error.
Tried updating to the latest dev release of apps - same error.
#3
Found a fix, see http://drupal.org/node/1606850#comment-6411386
This has you revert back to apps 7.x-1.0-beta6 which I found here
http://drupal.org/node/1543654
The error goes away and I now have the apps available.
#4
Can you see if reverting this changes fixes your problems?
http://drupal.org/node/1721538#comment-6331722
#5
Hello,
I've got the same problem.
It seems to be due to a forgetting image from apps.leveltendesign.com website :
The apps verify the screenshot to this site. But for Webform it doesn't work : there's no webform_screenshot.png to the url :
http://apps.leveltendesign.com/sites/default/files/screenshots/webform_s...
If you edit your locals webform_screenshot[_X].png with a text editor, it's a HTML page !
I fixe the problem with :
1. Adding into profile/openentreprise/modules/apps/app.manifest.inc line 257 :
if( $url == 'http://apps.leveltendesign.com/sites/default/files/screenshots/webform_screenshot.png' ) $url = 'http://apps.leveltendesign.com/sites/default/files/screenshots/open_enterprise_screenshot_1.png' ;2. Delete all webform_screenshot[_X].png in /site/default/file/apps/
3. In this folder, copy "open_enterprise_screenshot_1.png" and rename into webform_screenshot.png
4. Delete in the table "file_managed" the rows with "public://apps/webform_screenshot_[X].png"
5. Update in the table "file_managed" the rows with "public://apps/webform_screenshot.png" the filesize with the same value that "public://apps/open_enterprise_screenshot_1.png"
IT'S NOT A REAL SOLUTION !!! But it works for me ^_^.
#6
This problem occurs when apps tries to update the image for an app. The issue is that file_save_data creates an entry in the file table, Apps then goes in and tries to save the item again which creates the error about as that uri exists already in the table.
I've created a patch to use file_unmanaged_save_data so the file will only get saved once.
#7
#8
Thanks .The patch at Number 6 Works beautiful but you also need to first empy the table file_managed and not bad idea also to delete /files/apps/*
#10
I had to change
$file = new stdClass;to$file = new stdClass();in jec006's patch, but otherwise,this fix works perfectly.Actually, it seems to generate this intermittent error when running
cron:#11
I was able to prevent this error by force through changing line 196 of html/sites/all/modules/media/includes/media.types.inc from
if (preg_match($expression, $file->filemime)) {toif (isset($file->filemime) && preg_match($expression, $file->filemime)) {.#12
I have incorporated this patch into my work on #1621474: Allow Apps to function when offline
Additionally I also set the $file->mimetype so there should be no issues when using with Media as in #11.
#13
This is great! Thanks febbraro!
$file->mimetype = $request->headers['content-type'];#14
#5 (http://drupal.org/node/1748638#comment-6437560)
It tuck 30min but it worked well!
LOL
Thanks