[Loris-dev] Errors when using delete_imaging_upload.pl

Mon Apr 13 20:03:33 EDT 2020

Dear Cécile, Ling ma, and Nicolas,

I modified my scripts to execute the solutions you provided. @Cecile, the option -ignored worked perfect. @Nicolas, there were multiple entries in “mri_upload” linked to the same TarchiveID indeed.

Now all the UploadIDs linked to the study I am removing images from are now deleted. However, in the front-end I can still see 8 imaging visits! I will send an email explaining the issue.

Thank you again.

Regards,
Alfredo.

On Apr 7, 2020, at 8:06 AM, Nicolas Brossard <nicolasbrossard.mni at gmail.com<mailto:nicolasbrossard.mni at gmail.com>> wrote:

        External Email - Use Caution

Hi all,

Regarding the foreign key constraint fail error, my guess is that you have two records in mri_uploads that are tied to the same archive and you are trying to delete one of them. What I am saying is that you have two uploads, say U1 and U2, which have the same tarchive ID, say A1. If you try to delete U1, the script will try to delete everything associated to it, including archive A1, which will fail because of the foreign key constraint still tying U2 to A1. This is unfortunately a bug of the delete script.

You should be able to delete *all* the uploads that have the same tarchive ID though, but you'd have to do it in the same script invocation. So back to our example, you could delete U1 and U2 but you'd have to delete them at the same time by supplying both upload IDs in a comma-separated list via the -uploadID switch (see the perldoc for the delete script).

I hope this makes sense. Let me know if I you need more information.

Regards,
Nicolas

On Mon, Apr 6, 2020 at 6:02 PM Cecile Madjar <cecile.madjar at mcin.ca<mailto:cecile.madjar at mcin.ca>> wrote:
Hi Alfredo,

See answers below in blue.

Error type 1:
===
Error! File /ABC/data/pic/979907/IPMSA_979907_m00_NA_001_182_check.jpg exists in the database but was not found on the file system.
Aborting.
===

Error type 2:
===
Error! File /ABC/data/assembly/677803/m12/mri/native/IPMSA_677803_m12_NA_002.nii exists in the database but was not found on the file system.
Aborting.
===

The first two errors are the same. The delete script always checks first if the file is on the filesystem. My guess is that when you ran the pipeline, the path to the NIfTI file was inserted into the database even when the NIfTI file was not created due to some mnc2nii conversion errors (known bug that was fixed in release 22.0). You can use the option -ignore to ignore the check between database and file system.

Error type 3:
===
/ABC/data/pic/819059/IPMSA_819059_m12_NA_006_3098_check.jpg
/ABC/data/pic/819059/IPMSA_819059_m12_NA_007_3099_check.jpg
/ABC/data/pic/819059/IPMSA_819059_m12_NA_008_3100_check.jpg
/ABCdata/pic/819059/IPMSA_819059_m12_NA_009_3101_check.jpg
/ABC/data/pic/819059/IPMSA_819059_m12_t1_001_3091_check.jpg
/ABC/data/pic/819059/IPMSA_819059_m12_t1_002_3092_check.jpg
/ABC/data/tarchive/2009/DCM_2009-12-10_ImagingUpload-7-57-r0hk9h.tar

DBD::mysql::db do failed: Cannot delete or update a parent row: a foreign key constraint fails (`IPMSA_LORIS`.`mri_upload`, CONSTRAINT `FK_mriupload_TarchiveID` FOREIGN KEY (`TarchiveID`) REFERENCES `tarchive` (`TarchiveID`)) at /data_/ipmsa/loris_data/IPMSA/bin/mri/tools//delete_imaging_upload.pl<http://delete_imaging_upload.pl/> line 1612.
Issuing rollback() due to DESTROY without explicit disconnect() of DBD::mysql::db handle database=IPMSA_LORIS;host=132.216.133.50;port=3306; at /data_/ipmsa/loris_data/IPMSA/bin/mri/tools//delete_imaging_upload.pl<http://delete_imaging_upload.pl/> line 1612.
===

Not sure what is going on here. Could you point me to the file so I can check where the issue comes from? Or the release version you are using. Are there any processed output data for that upload ID?

Error type 4:
===
Cannot delete upload 1543: the MRI pipeline is currently processing it.
===

If you are sure you are not running the pipeline, you will need to update the mri_upload table to reflect this. For some obscure reason, the insertion status fields of the mri_upload table were not updated for that UploadID. Maybe the pipeline got interrupted?
UPDATE mri_upload SET Inserting=0, InsertionComplete=1 WHERE UploadID=1543;
Then, rerun the delete script on that UploadID.

Hope this helps. Best,

Cécile

Looking forward to hearing from you.

Regards,
Alfredo.

_______________________________________________
Loris-dev mailing list
Loris-dev at bic.mni.mcgill.ca<mailto:Loris-dev at bic.mni.mcgill.ca>
https://mailman.bic.mni.mcgill.ca/mailman/listinfo/loris-dev
_______________________________________________
Loris-dev mailing list
Loris-dev at bic.mni.mcgill.ca<mailto:Loris-dev at bic.mni.mcgill.ca>
https://mailman.bic.mni.mcgill.ca/mailman/listinfo/loris-dev

The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.bic.mni.mcgill.ca/pipermail/loris-dev/attachments/20200414/ec2b7c31/attachment-0001.html>