Posts by scoots39

Has anyone ever received an:

Access violation at address 77FCB0C8 is module 'ntdll.dll'. Write of address 404E27E6.

while browsing in the Browse Database tab. This is on a Win2K server machine. I have tried multiple databases - MSSQL2005, MSSQL 7.0, SQLite, Conquest 1.4.13, and Conquest 1.4.12c?

Online, I have run across the error in regards to corrupt ntdll.dll, and issue with Delphi and an empty list box (don't think it is this one given Conquest stabilty seen to date). Any ideas?

I am down to reloading the OS from scratch. Thanks.

Just curious - the Syngo browser patient registration page on your system does not contain a field for entering an Accession number?

Sorry, not sure how to e-mail you an image. I did not see a method using the forum to attach an image file. Help, please.

I will an image tomorrow - they are nuclear medicine images.
Thank you for your assistance and the great work with K-PACS.
Scott

Andreas,
Just to clarify - my Siemens based Syngo system will read and display the contents of the DICOMDIR file. But, after selecting a patient, study or series, the import fails. This also occurred with an attempted import to eFilm. I attempted another import on the Syngo system (dropping files from the CD into the directory from which a backround application attempt to import into the loca database), but also failed. The application log for this second failure indicated something like, "DICOM attributes not in order", or something along those lines.

Would you like me to send the contents of CD - DICOMDIR and image files? I will select small images. How should I send them?

Thank,
Scott

We have found that DICOM data written to a CD with K-Pacs v1.0 can not be read/imported into other DICOM systems - well at least two. Siemens Syngo and eFilm will read the DICOMDIR but import fails. I can provide a header dump if that would be helpfull?

If I move StationName and DepartmentName to the series table definition of a new v1.4.12d installation, do I need to be concerned where they are included in the dicom.sql listing?
Thanks

Any other changes to the dicom.sql invisioned for v1.4.13 besides moving StationName and DepartmentName to the Series table? Is the order of group/elements in dicom.sql significant?
I am working to upgrade my server to new hardware and would prefer to only regenerate my databases once.

Quote from radtraveller

Have had that issue also... Too much data being moved and MySql chokes and shuts down. ie mysql service has to be restarted. I have tried increasing caches and timeouts to no avail.

Got a new test box finally. Going to try ..Win2003R2/MSSQL2005 and longhorn beta3 Web with MSSQL2005.

Any tales of experiences would be welcomed.

I have run into the known: "2005: Secure socket layer error with GUI browser (+/-BDE) on some installations of MSserver2003 with MSSQL2005." Issue.

I am running a server with Win2k and MSSQL2005 without problems.

I have gone through the database fields against the DICOM standard -
PS 3.3-2006 - no sure if there is a new publication. Marcel's responses to my comments (via e-mail) are included below:

0008,0061 does not appear to exist in the DICOM standard published in 2006. Page 262 has Modality as a Series attribute - Study level seems more logical. Maybe leave it in both Study and Series tables.....?
64 character string?

Page 271 lists both:
0008,1010 StationName
0008,1040 InstitutionDepartmentName
as Series attributes.
Would seem logical to keep 0008,1040 in Study table......?

Page 291 indicates 0018,0010 as an Image attribute. Included in Series table seems logical as ContrastBolusAgent would seem to be fixed between images within a Series.......?

Quote

From Marcel:

it seems quite OK.

0008,0061 is generated by the server, not by the modalities: it is now called "Modalities in Study". See chapter 6.

StationName and DepartmentName should move: in DICOM RT, series can be scanned on different machines and potentially in different (sattelite) departments.

Indeed I would vote to keep ContrastBolusAgent in the series table. It would futher bloat the image table.

Would you mind posting your findings and my response on the forum.

Display More

Could you send to me as well please? s-leonard@northwestern.edu

I know this is a known issue but anyone solved this issue or discovered a work around? It is very frustrating. I am assuming this is really a Windows2003 server (security?) issue - issue not seen with SQL2005 on Win2k (Server or Pro) or WinXP. Might try with a Vista installation.

I will try to work on this. I'm in for some good reading.

Sorry if I missed this in another post.
From the manual, it looks like %studyid and %seriesid use the same group/element?

%studyid=(0020,0010), %studyuid=(0020,000D), %seriesid=0020,0010), %seriesuid=(0020,000E), %sopuid=(0008,0018), %imagenum=0020,0013), %image=(0020,0013) as 6
digit integer, %imageid=(0054,0400)

Should it be %seriesid=0020,0011 - SeriesNumber? Looks to me like this is what dgate is using, looking at dgatefn.cpp source.

Looking at dicom.sql, 0x0008, 0x1010, "StationName" is stored in the Study table. In our nuclear medicine department (as I think with many), a patients study may have individual series acquired on different cameras/stations and processed/derived on yet another. With StationName in the Study table, only the StationName of the last Conquest stored series will be recorded. If I wish to use the Conquest database to help our department track camera utilization I would like to have StationName stored in the Series table.
Is it best to move StationName to the Series definition portion of dicom.sql or can it exist on both Study and Series portions? I understand a complete database re-initialization would be required following any changes.

Understand. The -r1 confused me because I didn't see anything with dgate -? indicating that "1" was an option.
Any thoughts on NTFS compression?
Thanks, Scott

Sorry Marcel, I'm even slower than usual tonight.
I am missing the significance of -r vs -r1 --- or is "dgate -v -r in init" the full command. I am looking at "dgate -?" and not piecing this together.
I ran into the Windows2003 and SQL 2005 GUI browser issue - so I backed up and used Win2k server with another project. Will try Win2003 R2 and report back.

Thanks Marcel, now I feel bad about my last post, was not directed to you, intended as simple "what is everyone using?"
Right now I have about 300GB stored but using NTFS file compression at roughly 2.5to1 - so around 750GB. We are installing a PET/CT in the next few months and our storage requirements will ramp up - database requirements as well given PET and CT's single frame/file. I am preparing an array with the capability of 2.5+TB - will start at 1TB and grow the array as we go. We had e-mailed in the past about NTFS file compression which as not seemed to cause any problems. Any downside to NTFS compression you can see other than CPU utilization?
Cheers.

Thanks Bushranger. Thought the question would have elicited more of a response and/or debate. Leaning towared WinXP. Now, MS SQL or MySQL (noting bugs)?

First, a very big "Thank you" and "Nice work" to Marcel van Herk and Lambert Zijp for all their efforts with the ConQuest project. I am repeatedly astonished at the robustness of ConQuest, the number of options included and responsiveness of its developers. Thank you.

I have been using ConQuest in a nuclear medicine departement for nearly four years, running on a dual 500MHz XEON Dell workstation, 1GB RAM, SQL 7.0 database (Desktop Ed.) with Windows 2000 Pro. The time and resource have come to upgrade the hardware - more power/ram to host multiple servers for research as well as clinical, more redundances in server hardware and storage, etc. I am considering which version of Windows to use for the new system(s) - seems like I should move forward from Win2K, Windows 2003 seems like over kill for the price - don't need Active Directory, Domain controller, etc., WinXP is already a "last generation" OS but probably would suffice, anyone had a chance to try Vista yet? Opinions would be appreciated.
Scott