Posts by dermot

Thanks - works a treat!

dermot

Quote from marcelvanherk

Hi,

you can give a date range to the command. Limit the date range to make sure the command can complete in reasonable time.

Marcel

OK, So I would start with (in my case) "dgate --movestudy:OLDSERVER,NEWSERVER, *daterange*" ?

What is the syntax for daterange and, incidentally, can I use the same syntax for gSERVER when getting studies from a remote server?

thanks,

dermot

Quote from marcelvanherk

Hi,

see: http://forum.image-systems.biz…=11459&hilit=batch#p11459

Marcel

Is it this command - "dgate --movestudy:CONQUESTSRV1,OTHERSERVER,patid:studyuid" ?

and can I use a wildcard to move all studies, or do I need to generate a list of all studies in some way?

dermot

I have a many tens of thousands of studies on an old server that is getting a bit old and slow - and running out of diskspace.

I have a new one ready configured and ready too go - is there a method whereby I can get the old conquest server to do a dicom push and send all the data to the new one?

regards,

dermot

Quote from marcelvanherk

I added a directory monitor to allow automatic upload of DICOM and zip files. Together with the "submit" command this would allow efficient automatic sftp forwarding of large amounts of DICOM data between conquest servers.

Very interesting - I have 11TB of research data on a 1.4.15 server that is almost full and I have a new 48TB dual XEON one to replace it.

What is the easiest method of transferring that data across my gigabit connection between the two?

And once again thanks for all the work on Conquest.

dermot

Thanks for the response.

I've tried:

.......................

# Configuration of forwarding and/or converter programs to export DICOM slices
ForwardAssociationLevel = SERIES
ForwardAssociationCloseDelay = 5
ForwardAssociationRefreshDelay = 3600
ForwardAssociationRelease = 2
ExportConverters = 2
ExportModality0 = CT
ExportConverter0 = ifnotequal "%V0010,0010[0,1]^","A"; stop; ifnotequal "%V0010,0010[0,1]^","B"; stop; forward series to server1
ExportModality1 = CT
ExportConverter1 = ifnotequal "%V0010,0010[0,1]^","C"; stop; ifnotequal "%V0010,0010[0,1]^","D"; stop; forward series to server2

ForwardCollectDelay = 5
MaximumExportRetries = 0
MaximumDelayedFetchForwardRetries = 0

...................

Although when the server reboots, it states that two export queue threads are started, no forwarding happens after a CT study arrives.

Any thoughts?

dermot

I need to split up a stream of patient CTs inbound to a Conquest server so that there are, say, 4 separate destinations and Conquest forwards by looking at the first initial of the patient surname such that patients of surnames beginning A through F go to destination 1, G through L go to destination 2 &c.

Is there an easy way to do this?

Even if doing it alphabetically is not be the easiest way of dividing up the workload - are there any other methods that splits the traffic into more-or-less equal chunks?

dermot

Searching through the forum, I find that I'm not the only person having problems getting Conquest to talk to a Vitrea (just purchased) workstation; Vitrea will query Conquest, but fails to retrieve.

Does anyone have a definitive configuration that works?

cheers,

dermot

Ah yes, thanks, that's an avenue to try.

There is obviously still a risk of images not always getting to the right place, how about filtering by series description, is that feasible?

We could always modify the protocols on the CT so that the appropriate series include something unique in the series description (NON-PACS?). It would be a bit of work to change so many protocols, but perhaps more reliable in the long run?

regards,

dermot

I've had a look through both the manual and the forum, but not found an answer to my problem - apologies if I've missed it and it has been answered already...

Since we upgraded to 64 slice CTs, we are eating up disk space on PACS at a great rate.

What I want to do is forward all of the incoming studies to another Conquest server with a large (12TB) array and forward only the thick slice MPRs and other recons, plus the scout, to PACS

This way, we'll save our expensive PACS disk space but keep all of the original thin slice data for a couple of years in case we need to do further processing on it.

I'm already using Conquest to buffer and forward studies to PACS because PACS is rather slow at receiving images (120 per minute) while the CT can send to Conquest at 1500 images per minute. This allows the CT to be freed up much faster to send to local modality workstations.

This, alone, is already a huge advantage for us, so thanks once again to the Conquest developers.

I've been running Conquest for several years on a dual Xeon 3GHz Win2003 server box with 2GB of ram and 2TB of RAID disk.

I'm almost out of disk space but have aquired a new box of similar spec but with 3TB of disk.

I've been running Conquest with the default dbase driver and response is generally good, except that startup or reinitialization is rather slow, as you would expect, with over 20 million images stored.

Since I now have the opportunity to start over with the new server, I thought I should ask for advice on database choices; is MySQL sufficiently fast and stable? Other choices?