[Loris-dev] Imaging visits in front-end but no UploadIDs in the database
Nicolas Brossard
nicolasbrossard.mni at gmail.com
Thu Apr 16 09:05:32 EDT 2020
Hi Alfredo,
If none of the INSERT statements have a session ID of 845, then that
session was not related in any way to the uploads you deleted.
Consequently, I think that the behaviour of the delete script is totally
unrelated to the fact that session 845 has scan_done = 'Y' even though it
is not tied to any archive. When you start a visit, you have to specify
whether a scan was done or not and the system will not immediately "force"
you to upload scans if you indicated that a scan was done. It is thus
entirely possible that:
1. Session 845 was started and the user who started it indicated that a
scan was done.
2. No scans were uploaded afterwards for that session....
I personally think this behaviour is not desirable and the Scan_done flag
should only be set to 'Yes' if the session is tied to an existing archive.
If you also agree, you can just identify the sessions that do not fill this
requirement and set their Scan_Done flag to 'No'.
Hope that help!
Best,
Nicolas
On Thu, Apr 16, 2020 at 12:04 AM Morales Pinzon, Alfredo <
AMORALESPINZON at bwh.harvard.edu> wrote:
> Hi Nicolas,
>
> I checked the INSERT statements but no one has a SessionID set to 845.
>
> Also, are you sure you did not manually delete records from mri_upload
> after the delete script was run?
>
>
> Yes, I’ve only used the script. However, I recall that during the
> insertion of this study I had issues with the insertion of the images, for
> instance I had errors in the middle of the pipeline.
>
> Let me know if a call can be helpful to figure this out faster.
>
> Best,
> Alfredo.
>
> On Apr 15, 2020, at 3:42 PM, Nicolas Brossard <
> nicolasbrossard.mni at gmail.com> wrote:
>
> External Email - Use Caution
>
> Hi Alfredo,
>
> Yep, all clear. Tables mri_upload and tarchive both have a column
> SessionID. You said you did not find in your backup files an UPDATE
> statement for session 845. Can you check in your backup files the INSERT
> statements for tables mri_upload and tarchive? Do any of these statements
> have a SessionID set to 845?
>
> Also, are you sure you did not manually delete records from mri_upload
> after the delete script was run?
>
>
> Best,
> Nicolas
>
> On Wed, Apr 15, 2020 at 3:32 PM Morales Pinzon, Alfredo <
> AMORALESPINZON at bwh.harvard.edu> wrote:
>
>> Hi Nicolas,
>>
>> Apologies for not being clear in my last email. I meant to say that after
>> removing 3200 upload ids and didn’t find the session 845 in any of the
>> backup SQL generated files. I have multiple back up files as I removed the
>> 3200 ids one by one. Is it clear now?
>>
>> Best,
>> Alfredo.
>>
>> On Apr 15, 2020, at 2:17 PM, Nicolas Brossard <
>> nicolasbrossard.mni at gmail.com> wrote:
>>
>> External Email - Use Caution
>>
>> 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
>>>>
>>>
>>>
>>
>> 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/20200416/8163840c/attachment.html>
More information about the Loris-dev
mailing list