[Loris-dev] Imaging visits in front-end but no UploadIDs in the database

[Nicolas Brossard]

Hi Alfredo,

So what you are saying is that the script deleted a record in table
mri_upload with uploadid = 3200 but there was no corresponding UPDATE
session statement? In your previous email you were referring to a session
with ID 845 that had scan_done set to 'Y' even though there were no
archives associated to it. Was the mri_upload with uploadid 3200 tied to
session 845? Are you able to see in the backup file all the mri_uploads
tied to session 845 that were deleted?


Nicolas

On Wed, Apr 15, 2020 at 12:51 PM Morales Pinzon, Alfredo <
AMORALESPINZON at bwh.harvard.edu> wrote:

> Hi Nicolas,
>
> I checked the records, for the 3200 deleted uploadId, and the sessionID
> was not in there. Also, the UPDATE statement was issues in the same table.
> Here is an example of INSERT and UPDATE commands in the SQL file:
>
> ===
> INSERT INTO `mri_upload` VALUES (9,'lorisadmin\n','2017-11-28
> 16:30:47',’/ABC/AAB21935_880779_m00.tar.gz','/tmp/ImagingUpload-16-30-jIjf1G',1,0,'AAB21935_880779_m00',8,8,6,
> 4,1,1,'N');
> UPDATE session s SET Scan_done = 'Y' WHERE s.ID IN (4) AND (SELECT
> COUNT(*) FROM mri_upload m WHERE m.SessionID=s.ID) > 0;
> ===
>
> Maybe the insertion process didn’t finish properly but the state of the
> database was updated? As you can see this images were uploaded in 2017
> using LORIS v17.0.0 or v18.0.0. Let me know if you have more suggestions on
> what to check and how we can solve this.
>
> Best,
> Alfredo.
>
> On Apr 13, 2020, at 8:37 PM, Nicolas Brossard <
> nicolasbrossard.mni at gmail.com> wrote:
>
>         External Email - Use Caution
>
> Hi Alfredo,
>
> I am curious to see the actual records that the delete script removed from
> your mri_upload table. Since the delete script backs up what it deletes,
> you can have a look inside the backup file it created. By default, this
> file is named imaging_upload_backup.tar.gz. Inside, you'll find an SQL file
> that should contain all the entries in mri_upload that were deleted. Can
> you check if all of them have a sessionID set to 845 (they should)? Can you
> also check in the same file the UPDATE statement that was issued on the
> session table? We'll start with these checks first.
>
>
> Best,
> Nicolas
>
>
> On Mon, Apr 13, 2020 at 8:16 PM Morales Pinzon, Alfredo <
> AMORALESPINZON at bwh.harvard.edu> wrote:
>
>> Dear LorisDev Team,
>>
>> I recently removed all the UploadIDs from a study using the script “
>> delete_imaging_upload.pl”. However, in the front-end I can see some imaging
>> visits for some candidates of the study.
>>
>> Here is an example for one visit:
>>
>> Here is the imaging session for one the Candidates with the issue:
>> ===
>> select * from session where CandID in (450030) \G;
>> *************************** 1. row ***************************
>>                   ID: 845
>>               CandID: 450030
>>             CenterID: 60
>>              VisitNo: 1
>>          Visit_label: m00
>>         SubprojectID: 2
>>            Submitted: N
>>        Current_stage: Not Started
>>    Date_stage_change: NULL
>>            Screening: NULL
>>       Date_screening: NULL
>>                Visit: NULL
>>           Date_visit: NULL
>>             Approval: NULL
>>        Date_approval: NULL
>>               Active: Y
>>          Date_active: 2017-11-10
>>         RegisteredBy: 5216-ICR_dataman
>>               UserID: 5216-ICR_dataman
>>      Date_registered: 2017-11-10
>>             Testdate: 2017-11-30 11:07:25
>>     Hardcopy_request: -
>>          BVLQCStatus: NULL
>>            BVLQCType: NULL
>>       BVLQCExclusion: NULL
>>                  QCd: NULL
>>            Scan_done: Y
>>          MRIQCStatus:
>>         MRIQCPending: N
>> MRIQCFirstChangeTime: NULL
>>  MRIQCLastChangeTime: NULL
>>            MRICaveat: false
>> ===
>>
>> However, there is no TarchiveID associated with the session id in the
>> mri_upload table
>> ===
>> select TarchiveID from mri_upload where SessionID=845 \G;
>> Empty set (0.00 sec)
>> ===
>>
>> Any ideas on how can I fix this.
>>
>> Thank you in advance for your help.
>>
>> Regards,
>> Alfredo.
>>
>>
>> _______________________________________________
>> Loris-dev mailing list
>> Loris-dev at bic.mni.mcgill.ca
>> https://mailman.bic.mni.mcgill.ca/mailman/listinfo/loris-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.bic.mni.mcgill.ca/pipermail/loris-dev/attachments/20200415/e6429008/attachment-0001.html>