problem troubleshooting a **Error saving to SQL message.

    Hi,
    I need some help troubleshooting a **Error saving to SQL message. I sporadically get this message from my Fuji CR and one of several Toshiba GX CT scanners and conquest does not accept the images. I also do see this problem with my Hologic Delphi Dexa unit all the time (used to work and then stopped after a software update).
    I am running latest conquest with native SQL (had the problem with mysql odbc too though, upgraded to native a month ago). System is great otherwise, no problems.
    I can't find any useful info in the logs. Has anyone dealt with this issue out there?
    Thanks,
    L.J.Jaszczak MD

    Hi!
    I encoutnered the same SQL error several times before.
    It really seems to happen randomly and in my case only with images from the GE MRI machine.
    I noticed an increased frequenzy when updating from 1.4.11 to 14.4.12.
    Since Version 1.4.12c I could not find this massage in the logs again.
    However 1.4.12c is only running for a few days now.
    On one day we had about 100 entries of SQL errors just within a few minutes, SQL server itsself ran smoothly during that time.
    I managed to identify a couple of those studys causing this error message and tried to reproduce them, until now I was not successfull.
    However I found out that all images of these studies were stored correctly.
    I might have a theory about this:
    maybe this error only occurs when conquest is under heavy load.
    I get this idea because we send all our MRI studies from an Efilm machine at the end of the day to Conquest. Efilm is sending a few studies at a time instead of one by one.
    greetz

    I can reproduce this problem with the hologic delphi. Here is the debug info.


    2/10/2007 4:55:39 PM [FAIRLIGHT] ***Failed MYSQLExec : INSERT INTO DICOMSeries (SeriesInst, SeriesNumb, Modality, Manufactur, ModelName, BodyPartEx, SeriesPat, StudyInsta, AccessTime) VALUES ('1.2.840.113850.70918..1', '1', 'OT', 'HOLOGIC', 'Delphi C (S/N 70918)', 'HIP', '16633', '1.2.840.113850.70918.', 1171148128)
    2/10/2007 4:55:39 PM [FAIRLIGHT] ***Error: Duplicate entry '1.2.840.113850.70918..1' for key 1
    2/10/2007 4:55:39 PM [FAIRLIGHT] ***Error: 0: :
    2/10/2007 4:55:39 PM [FAIRLIGHT] ***Unable to DB.Add()
    2/10/2007 4:55:39 PM [FAIRLIGHT] ***SQL: INSERT INTO DICOMSeries (SeriesInst, SeriesNumb, Modality, Manufactur, ModelName, BodyPartEx, SeriesPat, StudyInsta, AccessTime) VALUES ('1.2.840.113850.70918..1', '1', 'OT', 'HOLOGIC', 'Delphi C (S/N 70918)', 'HIP', '16633', '1.2.840.113850.70918.', 1171148128)
    2/10/2007 4:55:39 PM [FAIRLIGHT] ***Error: Duplicate entry '1.2.840.113850.70918..1' for key 1
    2/10/2007 4:55:39 PM [FAIRLIGHT] ***Error: 0: :
    2/10/2007 4:55:39 PM [FAIRLIGHT] ***Error saving to SQL: 16633\1.2.840.113850.70918..1_0001_000001_11711481390020.v2

    Hmm, in producing the error I stumbled upon something. We do not use accession numbers. If I leave the accession number blank I produce the error. If I include it ("0" or any value), I don't seem to generate an error. I will try to work with this some more and post with info.
    LJJ

    Here is a similar error but from Fuji Carbon CR. I have had no problems since install two months ago, but on the 7th and 8th Feb, two studies refuse to transfer with the SQL error.


    [FAIRLIGHT] UPACS THREAD 56: STARTED AT: Sat Feb 10 17:58:36 2007
    [FAIRLIGHT] A-ASSOCIATE-RQ Packet Dump
    [FAIRLIGHT] Calling Application Title : "FCR-CSL "
    [FAIRLIGHT] Called Application Title : "FAIRLIGHT_SCP "
    [FAIRLIGHT] Application Context : "1.2.840.10008.3.1.1.1"
    [FAIRLIGHT] Number of Proposed Presentation Contexts: 1
    [FAIRLIGHT] Presentation Context 0 "1.2.840.10008.5.1.4.1.1.1"
    [FAIRLIGHT] Server Command := 0001
    [FAIRLIGHT] 0000,0002 26 UI AffectedSOPClassUID "1.2.840.10008.5.1.4.1.1.1"
    [FAIRLIGHT] 0000,0100 2 US CommandField 1
    [FAIRLIGHT] 0000,0110 2 US MessageID 89
    [FAIRLIGHT] 0000,0700 2 US Priority 0
    [FAIRLIGHT] 0000,0800 2 US DataSetType 258
    [FAIRLIGHT] 0000,1000 52 UI AffectedSOPInstanceU "1.2.392.200036.9125.9.0.84911893.10687232.2020745846"
    [FAIRLIGHT] FreeStore Left 1560849 on G:\
    [FAIRLIGHT] ***Failed MYSQLExec : INSERT INTO DICOMImages (SOPInstanc, SOPClassUI, ImageNumbe, ImageDate, ImageTime, AcqDate, AcqTime, AcqNumber, SamplesPer, PhotoMetri, Rows, Colums, BitsStored, ImageType, ImagePat, SeriesInst, AccessTime, ObjectFile, DeviceName) VALUES ('1.2.392.200036.9125.9.0.84911893.10687232.2020745846', '1.2.840.10008.5.1.4.1.1.1', '1001', '20070207', '085811.687', '20070207', '085800.578', '001', '1', 'MONOCHROME1', '3015', '2505', '10', 'DERIVED\\PRIMARY\\POST_PROCESSED\\100000', '33308', '1.2.392.200036.9125.3.1911412011834.64512579345.14523', 1171151904, '33308\\1.2.392.200036.9125.3.1911412011834.64512579345.14523_1001_001001_11711519180027.v2', 'MAG0')
    [FAIRLIGHT] ***Error: Duplicate entry '1.2.392.200036.9125.9.0.84911893.10687232.2020745846' for key 1
    [FAIRLIGHT] ***Error: 0: :
    [FAIRLIGHT] ***Unable to DB.Add()
    [FAIRLIGHT] ***SQL: INSERT INTO DICOMImages (SOPInstanc, SOPClassUI, ImageNumbe, ImageDate, ImageTime, AcqDate, AcqTime, AcqNumber, SamplesPer, PhotoMetri, Rows, Colums, BitsStored, ImageType, ImagePat, SeriesInst, AccessTime, ObjectFile, DeviceName) VALUES ('1.2.392.200036.9125.9.0.84911893.10687232.2020745846', '1.2.840.10008.5.1.4.1.1.1', '1001', '20070207', '085811.687', '20070207', '085800.578', '001', '1', 'MONOCHROME1', '3015', '2505', '10', 'DERIVED\\PRIMARY\\POST_PROCESSED\\100000', '33308', '1.2.392.200036.9125.3.1911412011834.64512579345.14523', 1171151904, '33308\\1.2.392.200036.9125.3.1911412011834.64512579345.14523_1001_001001_11711519180027.v2', 'MAG0')
    [FAIRLIGHT] ***Error: Duplicate entry '1.2.392.200036.9125.9.0.84911893.10687232.2020745846' for key 1
    [FAIRLIGHT] ***Error: 0: :
    [FAIRLIGHT] ***Error saving to SQL: 33308\1.2.392.200036.9125.3.1911412011834.64512579345.14523_1001_001001_11711519180027.v2
    [FAIRLIGHT] UPACS THREAD 56: ENDED AT: Sat Feb 10 17:58:39 2007
    [FAIRLIGHT] UPACS THREAD 56: TOTAL RUNNING TIME: 3 SECONDS

    Hi,


    this message (hologic) normally appear when the same series is re-inserted but now belonging to another study - this is forbidden. The later one (fairlight) that the same image is re-inserted for a different series - again forbidden. Where do you set the accessionnumber? Default it is just stored but further ignored by conquest - indicating maybe a bug on the sending site. Also the double point in the hologic UID is strange '70918..1'.


    Can you check to see differences between the log and the contents of the server (db, headerdump) for these data (focus on patientid, studyuid and seriesuid)?


    Marcel

    Ok, the issue with the Hologic Delphi is definitely a Hologic specific problem. If the technologist leaves the accession field blank, the Delphi generates a malformed key (70918..1) which is duplicate and generates an SQL error because of the duplication.
    I am working on the Fuji still. That problem is sporadic...

    Hi!


    I had quite a hard time to reproduce the SQL error.
    After moving almost 350 studies I finally got one SQL error message.
    It happened with a Patient who was examined twice in two days and so the database entries in table DicomPatient already existed.
    I was however not able to reproduce the error with this patient a second time, this is why I think it is some random error.
    The log file reads as follows: (Debug Level 4)


    PACS trouble:
    20070212 11:20:48 ***Failed MYSQLExec : INSERT INTO DICOMPatients (PatientID, PatientNam, PatientBir, AccessTime) VALUES ('040544', ABC, '19440504', 1171275616)
    20070212 11:20:51 ***Error: Duplicate entry '040544' for key 1




    20070212 11:21:06 ***SQL: INSERT INTO DICOMPatients (PatientID, PatientNam, PatientBir, AccessTime) VALUES ('040544', 'ABC, '19440504', 1171275616)
    20070212 11:21:07 ***Error: Duplicate entry '040544' for key 1
    20070212 11:21:09 ***Error: 0: :


    20070212 11:21:13 ***Error saving to SQL: 040544\1.2.840.113619.2.135.3596.3078814.7796.1170078362.911\1.2.840.113619.2.135.3596.3078814.7709.1170078713.951\1.2.840.113619.2.135.3596.3078814.7709.1170078714.17.v2


    Server log:
    12.02.2007 11:21:21 [PACS] Add to Table: DICOMSeries
    12.02.2007 11:21:21 [PACS] Columns: SeriesInst, SeriesNumb, SeriesDate, SeriesTime, SeriesDesc, Modality, PatientPos, Manufactur, ModelName, ProtocolNa, FrameOfRef, SeriesPat, StudyInsta, AccessTime
    12.02.2007 11:21:21 [PACS] Values: '1.2.840.113619.2.135.3596.3078814.7709.1170078717.781', '2', '20070210', '112355', 'T2 SAG frFSE', 'MR', 'HFS', 'GE MEDICAL SYSTEMS', 'SIGNA EXCITE', '060155/', '1.2.840.113619.2.135.3596.3078814.7796.1170078362.935', '060155', '1.2.840.113619.2.135.3596.3078814.7796.1170078362.936', 1171275680
    12.02.2007 11:21:21 [PACS] ***Error saving to SQL: 040544\1.2.840.113619.2.135.3596.3078814.7796.1170078362.911\1.2.840.113619.2.135.3596.3078814.7709.1170078713.951\1.2.840.113619.2.135.3596.3078814.7709.1170078714.17.v2
    12.02.2007 11:21:21 [PACS] Server Command := 0001
    12.02.2007 11:21:21 [PACS] 0000,0002 26 UI AffectedSOPClassUID "1.2.840.10008.5.1.4.1.1.4"
    12.02.2007 11:21:21 [PACS] 0000,0100 2 US CommandField 1
    12.02.2007 11:21:21 [PACS] 0000,0110 2 US MessageID 3597
    12.02.2007 11:21:21 [PACS] 0000,0700 2 US Priority 0
    12.02.2007 11:21:21 [PACS] 0000,0800 2 US DataSetType 0
    12.02.2007 11:21:21 [PACS] 0000,1000 54 UI AffectedSOPInstanceU "1.2.840.113619.2.135.3596.3078814.7709.1170078704.551"
    12.02.2007 11:21:21 [PACS] Server Command := 0001
    12.02.2007 11:21:21 [PACS] 0000,0002 26 UI AffectedSOPClassUID "1.2.840.10008.5.1.4.1.1.2"
    12.02.2007 11:21:21 [PACS] 0000,0100 2 US CommandField 1
    12.02.2007 11:21:21 [PACS] 0000,0110 2 US MessageID 3600
    12.02.2007 11:21:21 [PACS] 0000,0700 2 US Priority 0
    12.02.2007 11:21:21 [PACS] 0000,0800 2 US DataSetType 0
    12.02.2007 11:21:21 [PACS] 0000,1000 50 UI AffectedSOPInstanceU "1.2.840.113619.2.5.1762864713.5114.1168260429.843"

    Ok,


    this looks like a serious problem. Conquest queries mysql and cannot find the patient 040544 and then tries to insert it, which fails because it already exists. Maybe the query fails because of a lock? Can you check that the patient 040544 indeed existed prior to this transfer?


    For mssql there is a retry on failed queries due to locks to avoid this problem. This works - never seen such a problem in our hospital's pacs. Maybe mysql needs a similar thing.


    Marcel

    Hi Marcel!


    Right now I have cleared the DB again in order to reproduce the error again.


    Here is what I can say for now:
    A)
    1) I start with an empty conquest Archive and DB
    2) I copy a dozen of studies to conquest using eFilm
    3) then copy the studies of patient 040544 (seperatley)
    - no error, everything works


    B)
    1) I start with an empty conquest Archive and DB
    2) I copy a about 20 to 30 studies at a time (total 312) to conquest using eFilm
    3) during that copy operation at some point patient 040544 is send to conquest
    - error occurs, well until now I only was able to reproduce it once!


    I will try it again tomorrow.


    I get the impression that the heavier the load of CPU or maybe Conquest is, the more likely it is to get an error!?


    C)EFilm always copies multiple studies at once, maybe this could cause problems?
    What if Efilm sends one image of study 1 and one image from study 2 from patient 040544 at the same time - would in this situation the entrie be "locked"?


    D) is there any possibility to turn the debug level always to "on". this would make it possible tu run it on our real server with conquest in background. Doing this I hope to get more of these errors because they are somehow hard to reproduce


    greetz
    Stephan

    hi!
    I just moved 15GB of images on my test installation, and guess what - no error!
    I will try to switch the debug level on next time I take a look at the server, maybe this way we will get more information.
    greetz

    Hi!


    So after quite a while I managed to log a SQL Erro event on our Server machine.
    Details:


    PCAS Error log: 20070301 12:07:00 ***Error saving to SQL: 240662\1.2.840.113619.2.135.3596.3078814.8148.1172467839.711\1.2.840.113619.2.135.3596.3078814.8069.1172468194.936\1.2.840.113619.2.135.3596.3078814.8069.1172468195.2.v2


    Serverstatus log with Debug L. 4.
    20070301 12:07:00
    20070301 12:07:00 Calling Application Title : "EFilmMR "
    20070301 12:07:00 Called Application Title : "PACS "
    20070301 12:07:00 Presentation Context 0 "1.2.840.10008.5.1.4.1.1.4"
    20070301 12:07:00 Presentation Context 1 "1.2.840.10008.5.1.4.1.1.4"
    20070301 12:07:00 Presentation Context 2 "1.2.840.10008.5.1.4.1.1.7"
    20070301 12:07:00 Presentation Context 3 "1.2.840.10008.5.1.4.1.1.7"
    20070301 12:07:00 Written file: D:\conquestarchive\240662\1.2.840.113619.2.135.3596.3078814.8148.1172467839.705\1.2.840.113619.2.135.3596.3078814.8069.1172468194.101\1.2.840.113619.2.135.3596.3078814.8069.1172468194.167.v2
    20070301 12:07:00 [recompress]: recompressed with mode = n2 (strip=1)
    20070301 12:07:00 Written file: D:\conquestarchive\060747\1.2.840.113619.2.135.3596.3078814.8148.1172467839.714\1.2.840.113619.2.135.3596.3078814.8069.1172468195.95\1.2.840.113619.2.135.3596.3078814.8069.1172468195.161.v2
    20070301 12:07:00 ***Error saving to SQL: 240662\1.2.840.113619.2.135.3596.3078814.8148.1172467839.711\1.2.840.113619.2.135.3596.3078814.8069.1172468194.936\1.2.840.113619.2.135.3596.3078814.8069.1172468195.2.v2
    20070301 12:07:00 Written file: D:\conquestarchive\030344\1.2.840.113619.2.135.3596.3078814.8148.1172467839.696\1.2.840.113619.2.135.3596.3078814.8069.1172468192.845\1.2.840.113619.2.135.3596.3078814.8069.1172468192.911.v2
    20070301 12:07:00 Written file: D:\conquestarchive\211048\1.2.840.113619.2.135.3596.3078814.8148.1172467839.702\1.2.840.113619.2.135.3596.3078814.8069.1172468193.686\1.2.840.113619.2.135.3596.3078814.8069.1172468193.752.v2
    20070301 12:07:00 Written file: D:\conquestarchive\140435\1.2.840.113619.2.135.3596.3078814.8148.1172467839.708\1.2.840.113619.2.135.3596.3078814.8069.1172468194.560\1.2.840.113619.2.135.3596.3078814.8069.1172468194.626.v2
    20070301 12:07:00
    20070301 12:07:00 UPACS THREAD 355: STARTED AT: Thu Mar 01 12:06:59 2007
    20070301 12:07:00 Calling Application Title : "EFilmMR "
    20070301 12:07:00 Called Application Title : "PACS "
    20070301 12:07:00 Application Context : "1.2.840.10008.3.1.1.1"
    20070301 12:07:00 Presentation Context 0 "1.2.840.10008.5.1.4.1.1.4"
    20070301 12:07:00 Presentation Context 1 "1.2.840.10008.5.1.4.1.1.4"
    20070301 12:07:00 Presentation Context 2 "1.2.840.10008.5.1.4.1.1.7"
    20070301 12:07:00 Presentation Context 3 "1.2.840.10008.5.1.4.1.1.7"
    20070301 12:07:00 [recompress]: recompressed with mode = n2 (strip=1)
    20070301 12:07:00 Written file: D:\conquestarchive\300943\1.2.840.113619.2.135.3596.3078814.8148.1172467839.674\1.2.840.113619.2.135.3596.3078814.8069.1172468190.188\1.2.840.113619.2.135.3596.3078814.8069.1172468190.254.v2
    20070301 12:07:00


    I hope this will help a litte :-)
    greetz

    Hi,


    I still it may have to with a lock on a mysql table - causing a query to abort and return nothing. Does anybody have experience with locked tables in mysql and know how to catch such an error so that conquest can retry? The retry code for ODBC is in odbci.cpp, but not for mysql.


    Marcel

    Hi Marcel!
    It seems that this is quite a rare error message. And at the moment there is no further development in this case. I would like to help but sadly I have absolutely zero experience with MySQL.
    In the past I have randomly checked studies with this error to see if the image is in fact missing or not. It turned out that suprisingly all studies were complete. (at least the few I looked into)
    What I would like to ask is how Conquest handles such error mesages.
    Is the normal procedure that the program retries the query and then saves the images or is it possible that images will get lost?
    greetz
    Stephan

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login