Dicom Server 1.4.19beta3b release windows/linux

    Quote from marcelvanherk

    Hi,


    can you give it a quick test please? I am eager to put out the fix.


    Marcel


    Hi


    I just pulled about 3000 images from Conquest 1.4.19beta3b - so sending large studies seems to work now

    I tested renaming some patient-id's (on a test server this time) and most of the patients I tried setting up with a new ID number were deleted from the database and my hard drive.
    The following showed in the logs:


    I went in the Browse Database, searched for a patient, right clicked, changed the ID, and all data was gone

    Hi,


    is this a newly regenerated database or an old database; i.e., what is in uidmods.dbf. I tested it for both, but most recently only for the newly generated database.


    The log is completely correct: data is deleted and resaved. Are you sure images are gone? Maybe delete a small one and post debug log?


    Marcel

    That was on a test server, which might have had multiple copies of the same images under different names and ID's
    I tested it on a semi-production server with only decent images on it, and it is working correctly there.


    Although I have 2 questions about it:
    I just upgraded this one (not a clean install) and now I notice the following in my Server Status:

    Code
    [CONQUEST] ***SQLITEExec error: no such column: Stage[CONQUEST] ***SQLITEExec error: 5 values for 4 columns[CONQUEST] ***[NewUIDsInDICOMObject] FAILED to change 0002,0003 (MediaStorageSOPInstanceUID)[CONQUEST] ***SQLITEExec error: no such column: Stage[CONQUEST] ***SQLITEExec error: 5 values for 4 columns[CONQUEST] ***[NewUIDsInDICOMObject] FAILED to change 0008,0018 (SOPInstanceUID)[CONQUEST] ***SQLITEExec error: no such column: Stage[CONQUEST] ***SQLITEExec error: 5 values for 4 columns[CONQUEST] ***[NewUIDsInDICOMObject] FAILED to change 0020,000d (StudyInstanceUID)[CONQUEST] ***SQLITEExec error: no such column: Stage[CONQUEST] ***SQLITEExec error: 5 values for 4 columns[CONQUEST] ***[NewUIDsInDICOMObject] FAILED to change 0020,000e (SeriesInstanceUID)


    I didn't see any requirement for a database regen with this version, or changes to the layout.
    Do we need to make database modifications for this version?


    And when changing a patient is, I always seem to get a message that it is refusing to save something, even though when verifying functionality later, everything seems to be there

    Code
    [CONQUEST] Importconverter-1.0 executes: newuids

    [CONQUEST] Deleting database entry for image: E:\pacsimages\1111-111\1.2.840.113619.2.227.2079247177132.2133131125200851.10005_53163_000001_14182421940018.dcm

    [CONQUEST] ***Refused to enter inconsistent link PatientID into DICOMStudies: PatientID = '2222-222' StudyInsta = '1.2.840.113619.2.227.2079247177132.17909131125194554.20000', Old='1111-111', Refused='2222-222'

    [CONQUEST] ***Error saving to SQL: 2222-222\1.2.840.113619.2.227.2079247177132.2133131125200851.10005_53163_000001_14737831610005.dcm

    [CONQUEST] ***Error entering object into server: E:\pacsimages\1111-111\1.2.840.113619.2.227.2079247177132.2133131125200851.10005_53163_000001_14182421940018.dcm

    Correction to the above post:
    Images are not saving correctly on the live system either.
    - I had a patient saved as 1111-111 with 4 images under 1 study
    - I right click on the patient and did Change PatientID
    - for the first 3 images:
    -- conquest deleted the image from the database
    -- conquest tried to resave it in the database, but refused to, due to an inconsistent link patientID
    -- conquest left the image with original patientID, in the original folder, but it is not present in the database any more
    - the last image:
    -- conquest delete the image from the database
    -- conquest modified the image to reflect the new patientID
    -- conquest saved the image with new details in the database


    So the end result is:
    1 image saved with the new ID
    3 images still present on disk with the old ID, but no longer to be found in the database

    Hi,


    thanks for that info. Basically I believe that the cause it that there is information in the UIDmods table that is inconsistent.


    change patient ID does old UID -> UIDMODS - new UID
    gives new uids that have been given out for a different patient before.


    I would suggest clearing the UIDmods database. It may have come into that state due to the previous error.


    Marcel

    I don't see a table for UIDmods anywhere.
    I checked a couple different versions I'm running but no luck with that.
    I even re-initialized a database on one of my smaller servers, with the latest beta3b installed, but no UIDmods to be found

    Hi,


    I missed this post, was this with a new or an old database?:


    [CONQUEST] ***SQLITEExec error: no such column: Stage
    [CONQUEST] ***SQLITEExec error: 5 values for 4 columns


    I will test again to see what could cause this. It will wreak havoc in the newuids function and should not occur in 1.4.19beta3b - there is a test of the presence of the Stage field.


    UIDMODS is the internal key table, it changed format and that causes the issue. It is created when the database is initialized. I tested the function on a just installed server (new database) and there it works fine.


    Marcel

    Hi,


    the stage error is a known bug in 1.4.19beta versions before 1.4.19beta3b, where it failed with the new server on old databases. The 1.4.19beta3b version should work both with old and new databases.


    If the internal UIDmods table is corrupted, this is how it is created:


    DB.CreateTable ( "UIDMODS", "MODTime int, OldUID varchar(64), MODType varchar(32), NewUID varchar(64), Stage varchar(32), Annotation varchar(64)" );
    DB.CreateIndex ( "UIDMODS", "mods_old", "OldUID");
    DB.CreateIndex ( "UIDMODS", "mods_stage", "Stage");


    If needed I can post a lua script to do this. Stage and Annotation were added in 1.4.19beta.


    Marcel

    I am also receiving the

    Quote

    UN2CADW14] ***SQLITEExec error: no such column: Stage
    [UN2CADW14] ***SQLITEExec error: 5 values for 4 columns


    error when trying to anonymize.
    Re-initialized DB but still no good.
    In terms of results, sometimes the anonymization seems to work despite the errors, but on other occasions, the Patient Name shows as "No Name" and original images are lost...


    Is there any update or advice on this?


    Many thanks

    Hi,


    is this the latest version? It is a database compatibility problem, but the latest version should deal with it. It can be mitigated by adding the Stage column to the uidmods table.


    Marcel

    Hi


    I know its a little late but I would like to add a feature request:


    Possibility to add multiple IP Adresses to one AET


    Reason:
    We use Site-2-Site VPN as well as "on the road" dial-up-vpn. However Client IPs for S-2-S differ from dial up IPs - any chance to make that happen anytime in the future?

Participate now!

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

Register Yourself Login