Posts by Bookworm

    I and a reseller sat down with a local University, and they're wanting to do some interesting things with DICOM/PACS data.


    Because they're only doing research, they aren't going to be doing a lot of actual image viewing, but they _do_ need/want to add additional fields to the database, so they can link studies together with common information, as well as the possiblity of linking either an additional table structure (for columns of analysis data), or at least to an external file. (the table structure would be better for search functions).


    Would it be possible to expand the function of the ConQuest interface to allow those searches through without damaging the essential DICOM compatibility? (This would allow them to use a modified viewer to perform the searches, rather than requiring a secondary interface)


    Also, I know I can look at the files, but I'm too tired at the moment - long day - What programming language was used to write the bulk of ConQuest? I'm assuming C or C++.


    Thanks


    Troy
    Aka
    Bookworm

    I did the work myself, with help from a technician that works for the US Veterans Administration hospital - he let me sit down and see what the settings were in his unit for transmission to and from other systems.


    that, plus reading a LOT of big heavy books that were translated from the original Japenese by someone whose first language was Urdu.


    BW


    I don't recall the name of the software, I'll have to go look it up tomorrow. (I'm not there right now). It's semi-automated. A user must go through and select all the scans that have happened that day (it can be a range - it's also not if images, it's of the people that have images. ), and then they're transmitted as a block.


    If it is Eyepix, I'll find my notes on it, and transcribe them here.


    BW

    I just went through and re-read the COPYING copyleft agreement that's included in that version of MySQL - as long as they can _get_ the source, and you tell them how, you should have no problem redistributing the .dll file.


    My suggestion is that you take the DLL, a file containing the information on where that DLL came from, and that it has not been modified from the original source, plus the link to the page - http://downloads.mysql.com/archives.php?p=mysql-5.0&v=5.0.22 - and the COPYING file with. Then you'll have a zip file with three files inside of it - the dll, the information/README file, and the COPYING file. Have that as a separate download.


    ----------------


    MySQL version on linux is 5.0.24a (I don't know if it makes a difference for the failure to authenticate in dgate)

    Okay - switching libmysql.dll files out did the trick for 'native mysql support'.


    So, what has to be done for the ODBC mysql support? I'll re-read the documentation and see if there's something I missed.


    What I am seeing in some of the documentation is that steps are being skipped - it's the same issue I have when writing documentation; unless I do the process while I write the documentation, I miss 'obvious' steps.


    Off to start my day.


    BW

    Downloading the dll file right now.


    As for redistributing, there should be a notation somewhere in the copyleft about redistribution. As long as you provide a link to the _entire_ version (which is in their archive), and include the copyleft in a zip file with the .dll, I don't think anyone would have a problem.


    Doublebackslashtodb - I'll try setting it to see what happens. No compile time problems, database(s) are both accessible - just the 'can't connect' message.


    Would access to the server in question help?

    (This is a windows attempt - edit)


    Note: Installed MySQL 5.0.27, with mysqlcc-0.96, and odbc connector 3.51.


    Attempted to follow directions in PDF file (copied libmysql.dll from the MySQL directory to the dicomserver directory), and selected native mysql support.


    Receiving the following error -


    "There was a problem loading library libmysql.dll - mysql not functional"


    Deleted out libmysql.dll - currently trying it as 'use SQL server' and setting ODBC configuration.


    Note: ConquestPACS.pdf is only packaged as part of the linux configuration (mind you, it might be a standalone on the site), it's not included in any of the windows zip files that I can find, so far.


    Is it possible to get a copy of the original document from which the PDF was created? If so, I can add additional information to a copy for myself (and then to be uploaded, of course)


    BW

    Quote from blub:-)

    Bushranger


    Mhh.. I have used Nero for amounts up to 500GB, I am pretty sure that it is not the size but the amount of files in total (660k) that was the prob.
    But you are right I will not use it again next time :-).


    Bookworm
    I just took a quick look at the prog, sounds promising. I will try it out when I have some time left :-).
    By the way do you know how many files you copied?


    I use it nightly to back up a windows server running ConQuest - I don't know how many files are on that now. (several thousand is all I can say). However, I have transferred something like 300,000 files without a problem. What takes a while is the calculation of the relatives sizes of the information. That can take a long time - once it's done, however, the transfer itself moves fast - at least, once the data has been transferred at least once.

    Quote from marcelvanherk

    Probably edting odbci.hpp is enough. Did you create an empty database.
    The cgi interface is independent of that database. It will not work though before the server is up.


    There is an empty database, with the correct username/password as are in the dicom.ini file. Apparently the issue is with authentication between dgate and the mysql database. I may try it with no password at all, or a database with no underscore in the name. (or just a shorter name)


    What email address? (or should I PM you for the address?)


    BW

    I'll work on it some more tonight - it's been a busy weekend.


    Not sure that the hard path WAS a problem - I took it out to make certain. the 'mysql.h' definitely was a problem, as it doesn't seem to actually look for where mysql.h is located in the machine - if mysql.h isn't in the path, it won't be found with that standard include statement - you have to put a full path in the file.


    Troy
    aka
    Bookworm

    The hashes were added just for that posting - I don't have them in my dicom.ini file.


    Doing some further abuse, I found that I am getting an "Error Connecting to SQL" message. (./dgate -r )


    It also has a Regen Device 'MAG0' before the error


    I'm assuming that has to do with the line


    MAGDevice0 = ./data/


    in dicom.ini


    I didn't modify odbci.cpp at all - I didn't realize there might be a need to. I modified odbci.hpp, but only to change the two references to mysql.h to the actual location of the mysql.h file.


    Apparently much of this goes back to the failure of dgate to actually log into the MySQL database. I can't get a good traceback, as the --debuglog_on option apparently doesn't work (at least, not before it's trashed itself)


    Interestingly enough, the 'dgate.html' link in cgi-bin brings up some query fields. It's not doing much, mainly because the database hasn't been initialized with tables.