Hi,
the database only stores configured items in dicom.sql. You can extend it to add as much as you want, as long as you do not change the first and last field of each database, and regenerate after editing.
HOWEVER, this is only required if you want to QUERY on that data. The headers on disk are not touched and will store ALL data.
Marcel
Hi,
maybe you can try to send from that conquest to another one and see if the problem persists. What database are you using?
Marcel
Hi,
maybe you can (temporarily if you want) upgrade to the dgate.exe of 1.4.14 - or if you are using 1.4.14 switch one debug logging. This gives some more info in case of a rejected association. There may be a transfer syntax issue as well.
Marcel
Hi Mark,
I believe that the behavior is more or less correct: --imagelister should not be used to query filenames of a remote server through DICOM (this would be non-standard behavior). It can be used to query pat:sop using a format string like ":%s:%s". To get the filenames only 'local' as server is correct.
Marcel
Hi,
images have to be registered in the database to be visible. So to enter new images you can send them over a dicom connection or use windows drag and drop on the user interface panel: this will copy the images and update the database.
Marcel
Hi Pat,
for the web viewer you do not need to enter each user, since only the web server is using a DICOM connection. The web viewer of 1.4.14 will likely not work (fully) against 1.4.12c but you can give it a try.
Actually, without the web viewer, you can also use wildcard AE titles in dicom.ini, which would allow you to use one definition for multiple AE's containing the IP address. We use this to connect all our viewers. I.e., if my IP is 192.168.0.2, then if I use AE V192.168.0.2 the server matches this to V* in acrnema.map, and takes the IP from the AE.
Still interested in the crash though, can you give more details of what happens when you try to reinitialize the database?
Marcel
Hi,
you are correct: it is easy to switch database. The easiest way to switch database is to delete dicom.ini which forces the server to go through the install procedure again including the choise of database driver.
On a WAN query speed will be determined by the network, not by the database driver. But MySQL gives the most compact database with the least requirements for maintenance.
Splitting data to an archive server is not very helpful, the speed of the server should not be impaired up to millions of images.
As far as your crash is concerned, please give me the crash information (adress, drwatson report, or whatever you can get) and then I can fix it. I am not aware of other recent crash reports.
Marcel
Hi,
reindexing requires reading all images and is typically not limited by the database speed. However, in principle, you should never have to reindex: it is only required when the database structure is updated or when the database is lost.
Packing the database removes deleted records from the dbaseIII tables. However, there should not be many in there (they only appear when you delete images from the server).
As far as the database is concerned, I now believe MySQL is the best choice for large installations. It can be installed on the same machine. There is an extensive database section in the windowsmanual document.
What particular operation do you want to speed up? The fastest read/write speed is probably obtained by saving the images (non-standard) as .V2, uncompressed or with NKI compression. Saving the images as .DCM is slower, and JPEG compression is particularly slow.
Marcel
Hi,
it is not a good idea to change the patient ID or UIDs on an import converter. This may be the cause of your problems.
Marcel
Hi,
Drag and drop does no checks at all. But conquest should accept anything as long as you add it to dgatesop.lst - so it may actually be a transfer syntax issue, where the other station is not conforming to the dicom standard and converts the data to implicitlittleindian. Maybe try to enable jpeg support and see what happens? (you need to re-edit dgatesop.lst then).
Marcel
Hi,
added to buglist.
Marcel
Menu: View-source
Marcel
Hi,
I am not aware of a running one on the internet. You will have to try to install the server yourself. Furthermore, there is little or no security built-in. Some have added some security on (see forum).
Marcel
Hi,
big-endian does not work in conquest - yet (never fixed it and enabled it). So that may explain. However, it is a k-pacs bug if it does not convert from little-endian to big-endian on need, because conquest reports it cannot handle big-endian.
Marcel
Hi Donnie,
The ActiveX plugin (in 1.4.14. edit the web version of dicom.ini to use seriesviewer), transmits the original DICOM data, although it may be recompressed and downsized depending on your config. You can change level and window and zoom on the fly. If you scroll to other slices, they are collected from the server, which takes a little bit of time. However, the web browser cache keeps slices that you have been to, and going back and forth through the stack is very fast after the first time.
Marcel
Hi,
As far as the first question is concerned: it is also possible to send images from the server to itself to do some data processing (as long as the file name stays the same) such as downsizing. However, you lose your original, so be careful.
Marcel
I believe a 1.4.14a release should be done in a few weeks.
Marcel
hi,
can you reply with the web page source as displayed by ie7? This may help to solve the prob.
Marcel
Hi,
the rebuild function of conquest should be much faster on newer releases.
Marcel
Hi,
"connection terminated" shows up if the sending application hangs up before transfer is complete. I have seen StoreSCU do this if the image transfer syntax does not correspond with the requested transfer syntax - i.e., becuase it cannot recompress images it will hangup even after the connection is made.
Hope this helps.
Marcel
