Posts by skrani

    I have never been able to copy/write more than about 100.000 files over network share before windows crashes.


    But if you reboot the system before you copy/write about 50.000 files you should be save.


    Has anyone else experience with this???


    (Same goes for writing to USB disks, drives me crazy when trying to copy large amount of dicom files.)

    Are you sure it works with DBASEIII?


    Did you create user for MySQL with the same username and password as is in conquest's dicom.ini?


    Can you skipp the verify step and do rebuild database??


    Did you try to use ODBC instead of native MySQL driver??


    Just some "hints" that might get you started..


    Best regards


    steini.

    Have you tried to select "study" at the top, then enter a date, such as 20070602 and then press "find local missing.."


    I use the common setup of "primary" and "secondary" conquest where the primary forwards all images to the secondary, and every now and then I compare them. I make a log in a txt file on the desktop that states what dates I have already compared. Then I compare a range of dates such as one month (january 2007 in this example) by entering 20070101-20070131. If I select to long period, it times out.


    Just remember that you MUST select "study" level (the top box) before you press "find local missing" .


    Good luck.

    Hello All.


    I was using Native MySQL driver with Conquest 1.4.13Alpha and users started complaining that study descriptions did not match the study. And then later that referring physician was also "bullshit". (Well I did not check any other fields, this was bad enough)



    Found out that using Native MySQL, Conquest somehow uses information from "previous" patient to fill in EMPTY study description fields and referring physician fields, when returning DICOM query requests.


    (That is that those studies that do not have any description will get description from other patients.)


    This does not affect the images, it is just the query reply that has this problem.



    I changed to ODBC connection and it works normally now.
    (MySQL ODBC 3.51 driver)


    Just wanted to warn you all..


    Thanks for great server and the Forum is also great.


    Steini.
    Service Engineer Iceland.

    Hello Nuccerz.


    I did not read your first post carefully enough.


    I think you are doing a mistake...
    If you already created ODBC connection to the database (The conquest manual calles this "create ODBC by hand"), you do NOT need to press the "Make ODBC data source" button. (infact should not press it)
    pages 47 and 50 in the manual touch on this.


    You should just change your dicom.ini as follows.


    SQLServer = Datasource name you selected during your creation of "ODBC by hand"
    Username = The DB username to use.
    Password = The DB password to use.


    If you then open up the Conquestserver.exe GUI you should be able to press "verify database installation" and you should see 10 tables or something created and dropped.


    Installation in short....
    Unzip files to C:\dicomserver.
    Install MySQL
    Create (System) ODBC data source.
    Start conquestDicomserver.exe, select ODBC.
    Save configuration
    Exit conquestdicomserver.exe
    edit dicom.ini
    start conquestDicomserver.exe
    press verify database installation
    press regenerate database.



    That should do it.


    Hope this helps.


    steini.

    First thing I would check is if MySQL is actually started, and working properly.


    test if you can communicate with it in any way, using GUI for example (or telnet somehow...)


    Good luck.


    steini.

    Hello All.


    We had a similar problem several years ago and spent hours and hours on it.


    In short...We had a professional DICOM analyst look at images sent from the ACUSON system to GE Radstore(that removes patient name from the header, this is a research site), from there to GE Centricity archive and from the archive to the OFFIS DCMTK STORESCP. The conclusion from the DICOM specialist was that the still images were OK. The multiframe images how ever claimed to be YBR_FULL_422 but actually were RGB images.


    Our workaround was to send the images from ACUSON to RADSTORE to CENTRICITY to RADSTORE to "wherever we need them" and then all is OK.


    It seems that the CENTRICITY archive VERSION we have at the research site somehow does not do a proper job when "decompressing or what ever" when it sends the images away, but GE RADWORKS understands it and "fixes" it.


    BTW. I use Conquest archive with US machines from Toshiba, Philips/ATL, and Acuson. And it works quite well, except for the ACUSON where I had some problems with multiframe images, but it was a long time ago, the customer did not care (did not use MF) and I never investigated it.