Conquest DICOM server 1.4.13 released

  • Today, a new version of the Conquest DICOM server is released.

    I would like to thank all the users of the forum who reported problems, suggested changes, and helped testing and documenting.

    The main new features are:

    SqLite driver, jpeg and mysql driver in one package, auto setup database, delayed forwarders and prefetchers, more scripting commands, WEB viewer for IE, configure V2/DCM, configuration of deletion order, and bug fixes.

    You can find it at:



  • I downloaded the new package and found the Linux installation manual. Thank you. I did not find instructions to how to compile in Linux for MySql. Where should I look?



  • I'm working on it.
    Is there a specific user and pswd that I need to set for MySQL? When I executed dgate -v -r, I got 'Failed MYSQLExec'. Is there a log that will tell me what happened?



  • Here is the list of known issues in 1.4.13

    1) Using the LRUSort parameter (anything but the default) seems to cause
    this: [CD-PACS] ***Failed SQLExecDirect : SELECT PatientID FROM ICOMStudies WHERE [CD-PACS] ***Error: 102: 37000: [Microsoft][ODBC SQL Server Driver][SQL Server]Incorrect syntax near 'WHERE'.
    When applying makespace command. This is with a MSSQL2005 database. Andrew Batiuk. Will be solved in next release.

    2) Make delayed forwarder more flexible. In next release.

    3) %s is interpreted as string "pointer" in the logs while it should be printed literally - an old bug. This may cause a segfault or not: it just whats happens to be on the stack. Will be solved in next release. A "patch" in the dprintf.cpp source code is on the forum (for linux users).

    4) A linux only problem: The %02d items in cache devices are not filled in and linux then does not understand the cachedevice string for calcualting the free store (in windows only the drive letter is used, and that part of the string is dumped). A temporary patch: just return a large number in CheckFreeStoreOnCACHEDevice in device.cpp (line 706) like "return 5000000". Fixed in next release.

    5) I guess that you have LittleEndianImplicit enabled for 1.4.13 and not for 1.4.12c - maybe an issue with our install program. In any case I made a fix that will make the server work correctly for LittleEndianExplicit. This will be in the next release. Please disable LittleEndianExplicit for now.

    6) Add compression mode uj. Fixed in next release.

    7) that was my first idea too, but it does not works. It is also equal witch version of ini I use. The complete version .13 with the older dgate.exe on webserver runs and the picturesize is all right. Olaf. Finding not confirmed. Marcel

    8 ) Malformed dicom images or message now "crash" stop the viewer with an allocation failure message. These were ignored before.

    9) "virtual server" and export converters interferes with BrowseThroughDBF?: Only patient dbf created. Finding not confirmed. Marcel

    10) Is the K-PACS viewer in the Browse Database tab hard coded to port 5678? I get an error Conquestdicomserver, Server not running(in this directory), when the server is set to port 104. I have not tried any other ports. When I set the port back to 5678 then the viewer works without error. Fixed in next release.

    11) Webviewer fails when patientID contains spaces. Fixed in next release.

    12) Out of memory errors - but not clear why these occur (apart from malformed DICOM images). Please provide more info.

    13) Missing dicom.sql should not crash web cgi app. Fixed in next release.


    15) Malformed header of WEB pages, making that pages served up from a windows machine can only be viewer with IE (other browsers will ask to 'save to disk'. Fixed in next release.

    16) Check on presence of dgate.dic when starting dgate.exe. Thanks Peter. Fixed in next release.

    17) MovePatientData will fail if data for same pat was already present on the target device. Thanks Ali. Fixed in next release.

    18 ) Missing \ on MAGDevice0 etc would fail browser but not server. Thanks Ali. Fixed in next release.

    19) Regen without any images seems to fail (with with myodbc only?). Ali.

    20) Browsing beyond end of table seems to fail with myodbc. reinitialize database without patient causes an error. And deletion of all patients results error. This all with myodbc. Ali.

    21) Case sensitivity of database names under unix and maybe myodbc was ignored in several delete and archival options. Fixed in the next release.

    22) Send to from browser crashes GUI when query/move page in UID mode. Fixed in next release.

    23) Worklist delete fails for patients with space in ID. Fixed in next release.


  • Hi, Marcel.
    Great work! Now we're using Conquest 1.4.13beta with Web KPACS enabled. It's very good!

    Now that the 1.4.13 version is released I'd like to know if there is any issue following the update steps described at the manual (section 2.1.3 "Updating to newer versions").

    Is it safe to update from 1.4.13beta to 1.4.13 by replacing dll and exe files only?

    Thank you!

    [ ]s!

    Gustavo F. Caetano
    Technical Coordinator and Biomedical Informatics Specialized Technician
    Image Sciences and Medical Physics Center
    Hospital das Clínicas - FMRP - USP

  • Forum users:

    can you please provide me with more input on the out-of memory errors. The test is new in 1.4.13, but it is not clear to me why these occur (apart from malformed DICOM images). Please provide more info.


  • Hi, I'm new in the Forum!!

    I have problem to compile Conquest DICOM server 1.4.13 in Ubuntu 7.04 - Feisty Fawn, I change the permissions of the scripts maklinux, maklinux_sqlite, maklinux_postgres but when i try compile and install web access :s

    I'm not expert in linux, I would be thankful for any aid, sorry for my english...

  • Hello,
    Building a new Conquest server with Win2k3, 4GB RAM, MSSQL2005, Conquest 1.4.13 and ran into the out-of-memory error during a regen of an approximately 500GB worth of data. Wondering if most of these errors are occurring with MSSQL and which versions? Is there a minimum available memory threshold compiled into dgate.exe?
    I have three Conquest instances running on one server. I started the regen of the first and ran into the out-of-memory error. Rather than digging for malformed DICOM files, I started a regen of the second instance.
    I was watching the taskmager, the amount of CPU utilization and Memery Usage and noted that while dgate.exe and ConquestDICOMServer.exe mem usage remained fairly constant (5-8MB), sqlservr.exe memory usage continued to increase. I left my office with sqlservr.exe mem usage up to 1.5+GB and will find out Monday if this regen also failed.
    The SQL databases are stored on two 36GB Ultra320 drives in a RAID-1 mirror - should be more that fast enough. But, I am wondering if the continuous increase in mem usage is being caused by MSSQL not being able write to the database fast enough compared to dgate's ability to read the DICOM data?
    Thanks, Scott

  • Hi,

    this behaviour looks normal: MSSQL will use most available RAM to store indexes - it is not related to the dgate out of memory error (you see that it does not leak memory).

    The dgate out of memory occurs on a malformed DICOM image, where the length of an element is read faulty as a very big number causing "out of memory" when dgate tries to allocate that. If 1.4.14beta there is a flag to supress the out-of memory message - causing the image to fail loading without stopping the server.


  • Thanks Marcel, just a thought.
    Any thoughts on how the data becomes malformed - at the sending side when orginally sent to Conquest, from a file copy error, etc.? If the file malformed in its current state what are the options for fixing it to allow inclusion in the system - move from its current location, regen the data directory, then drag an drop back into Conquest?
    Thanks, Scott

Participate now!

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