Hi,
Wanted to try this module out. Exported 16 FAQ nodes from a D6 in a file format, and have an error when importing to a D7:
PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'temporary://node-export.export' for key 'uri': INSERT INTO {file_managed} (uid, filename, uri, filemime, filesize, status, timestamp) 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] => 1 [:db_insert_placeholder_1] => node-export.export [:db_insert_placeholder_2] => temporary://node-export.export [:db_insert_placeholder_3] => application/octet-stream [:db_insert_placeholder_4] => 86685 [:db_insert_placeholder_5] => 0 [:db_insert_placeholder_6] => 1297440630 ) in drupal_write_record() (line 6776 of C:\xampp\htdocs\drup7\includes\common.inc).
I need a hand interpreting this error message, please.
Thanks
Comment | File | Size | Author |
---|---|---|---|
#25 | node_export-failing_to_import-1058750-25.patch | 1.09 KB | acrollet |
#19 | remove_fid_if_no_file_managed_record-1058750-19.patch | 872 bytes | tmsimont |
#10 | file-import-1058750-10.patch | 1.95 KB | kjauslin |
#9 | file-import-1058750-9.patch | 1.15 KB | kjauslin |
Comments
Comment #1
danielb CreditAttribution: danielb commentedlooks like it could be a bug
try renaming the file to something unique before upload?
dunno how much success you'll have with d6 nodes in d7 at this point either
Comment #2
S@ilor CreditAttribution: S@ilor commentedHi again, thanks for responding
I did name the .export file to something easier. It had an insanely long filename, and I thought it could have been a reason, but no. Same error.
It's a shame if I cannot reuse content from my D6 site with this module. That is the sole reason why I installed it. How else can I export/import data apart from copy/paste every page? Will take a month ... There gotta be a way.
I'll wait for the next version, and see how it goes.
Thanks,
Comment #3
danielb CreditAttribution: danielb commentedThis module might help you: http://drupal.org/project/migrate
I don't know, I've not tried it yet.
I would like to get more d6 -> d7 compatibility in node_export, but I don't know enough about how to do that yet.
Comment #4
S@ilor CreditAttribution: S@ilor commentedThanks, danielb
I will take a look.
Comment #5
safetypinI ran into this issue as well, but if I just reloaded the page (resubmitting the import form) the import worked, and I didn't get the error again.
The weird thing is, this happens every time I try to upload the same file. When I reload the form submission, drupal properly detects that there is a file that exists with the same name, and automatically renames the path ([original_file_name]_xx.[ext]) so it is unique in the database. I can also manually remove the record from the database. I wonder if this is a problem with core temporary file handling system.
Comment #6
S@ilor CreditAttribution: S@ilor commented@ idlewilder
That's interesting. Want to try it. In the meantime, disabled the FAQ module (it was faq nodes I wanted to import) because it created some inexplicable errors. Now when I want to enable it again, it just blank out the whole module page. What is that all about?
Anyway, seems something is not finished in the D7. But thanks for the tip.
- C
Comment #7
safetypinIf you can access the apache error.log file, that will often give a better clue about where the error (especially white-screen errors) are coming from.
If you're on a hosting provider that includes Plesk, you can access this by the log manager. If you're running MAMP (or probably some other *AMP installation, although I'm not certain) you can find the error log inside the application folder.
Comment #8
danielb CreditAttribution: danielb commentedComment #9
kjauslin CreditAttribution: kjauslin commentedI had a similar problem importing images (inline base64) if a file already existed (D7->D7). You can try the attached patch.
It will check whether a URI exists already in the file_managed table and will keep the existing version (import will continue without error). A notice will be written to the log that the existing file was kept on import.
Additionally, I fixed a D7 migration issue: drupal_dirname is used for new files when using inline base64 encoding for filedata (instead of dirname which does not know about stream wrappers).
Comment #10
kjauslin CreditAttribution: kjauslin commentedI forgot to include to small changes, which will get rid of the warning messages in multilingual setup and when the node_export_file_path does not exist. Please use the improved patch.
Comment #11
danielb CreditAttribution: danielb commentedI've added that patch kjauslin, thanks.
Let me know if there are additional problems or patches for me to consider.
For more D6-D7 stuff
#994376: Converting nodes from Drupal 6 to 7
Comment #13
seanburlington CreditAttribution: seanburlington commentedHi,
I'm not sure the problem originally described is fixed as I'm encountering it with the latest dev version which contains the above patches.
There seems to be a problem specific to interaction with node_export and faq modules.
I have a Drupal 7 site in development - and want to export faq nodes from a dev site for import to a live site (both essentially copies of the same site)
The FAQ nodes seem to export OK but when I import I get the following error
and when I look at an exported node it does seem to be short on data
(minor details adjusted to protect client identity)
Comment #14
seanburlington CreditAttribution: seanburlington commentedOK I think there is an issue with the FAQ module - making it incompatible with node_export
The detailed_question field is marked in the schema API as NOT NULL
The faq_load function does not add this parameter if the value would be empty
The faq_form function sets the parameter to "" if it does not exist
and faq_save requires the field to be present (by virtue of the NOT NULL constraint)
All this works out OK if you use the form to create the node that you save - but you can't load a node, export it (or anything else like trying to modify nodes programatically) then save it again.
I don't think that node_export can sensibly do anything about this - but posting here for completeness.
I've raised the issue over at #1252142: detailed_questions field is logically optional but constrained to be non-null
Comment #15
danielb CreditAttribution: danielb commentedYep you've nailed it. If you node_load() and then node_save() a node, and some module's functionality breaks, then they're doing it wrong.
Comment #16
danielb CreditAttribution: danielb commentedAnyways I'm dealing with a very similar issue here which might affect this: #1192586: file upload error if temp file exists
I don't think I can do anything with that FAQ thing, but reopen if you think node export does something wrong.
Comment #17
michalsen CreditAttribution: michalsen commentedI am seeing a similar issue with drush ne-import
Steps to reproduce:
D7.10
Create custom content (specialty) type which includes an image.
Create one node of this content type.
drush ne-export --type=specialty > specialty.node
Now for the the fun.
Do not delete node in cms.
drush ne-import --file=/PATH/TO/specialty.node
Duplicate content is created in system without errors.
Delete node(s) in cms.
drush ne-import --file=/PATH/TO/specialty.node
Content is not created.
WD node: PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '' for key 'uri': INSERT INTO {file_managed} [error]
(filesize, status, timestamp, uuid) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2,
:db_insert_placeholder_3); Array
(
[:db_insert_placeholder_0] => 0
[:db_insert_placeholder_1] => 1
[:db_insert_placeholder_2] => 1326293395
[:db_insert_placeholder_3] => 42554a1b-0609-6ab4-35a4-3496cc7f309e
)
Edit specialty.node to remove all lines pertaining to field_specialty_image.
drush ne-import --file=/PATH/TO/specialty.node
Content imports beautifully....of course without an image.
I have only recently come across this and will look more into this today, but wanted to post what I was seeing if it may help someone else.
Comment #18
kenorb CreditAttribution: kenorb commentedSee: #1163740: PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '' for key 2: INSERT INTO {file_managed}
Comment #19
tmsimont CreditAttribution: tmsimont commentedI was having problems with a site that has the file on the server, but doesn't have the record in the
`file_managed`
table. I was trying to manually merge two versions of one site, and ran into this condition... By adding a few lines to the import code, I was able to get it to work.Comment #20
kenorb CreditAttribution: kenorb commentedRelated:
#1058750: Failing to import
#1911638: Missing file attributes cause Integrity constraint
#2063121: Node Export: WD node: PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '' for key 'uri'
Comment #21
Mat77 CreditAttribution: Mat77 commentedThe patch #19 worked for me!
Thank you
Comment #22
jnicola CreditAttribution: jnicola commentedI have tried all of the patches listed here to no avail. I am getting the following errors on my most recent efforts at importing:
Comment #23
Mat77 CreditAttribution: Mat77 commentedHi,
Your errors show that it's trying to import a file but it can't find it on the server.
As you can see, it's looking at this address:
http://default/public%3A//amb3_0.jpg
The addresse is wrong, it should be something like:
http://127.0.0.1/sites/default/public%3A//amb3_0.jpg
Or
http://localhost/sites/default/public%3A//amb3_0.jpg
Or
http://www.mywebsite.com/sites/default/public%3A//amb3_0.jpg
So there is something wrong with your URL configuration, that has nothing to do with the Node Export module IMO.
[Edit]
Actually I read it wrong, this is only warnings. The error is actually the same as in this issue.
Did you try cleaning the file_managed table of empty results?
Comment #24
juantxo_kupul CreditAttribution: juantxo_kupul commentedThe patch #19 worked for me!
Thank you
Comment #25
acrollet CreditAttribution: acrollet commentedStill had issues with this with #19 applied, updated patch attached that also checks for a pre-existing entry in file_managed before attempting to save the file object.
Comment #26
dooug CreditAttribution: dooug commentedComment #28
danielb CreditAttribution: danielb commented