Posts by mukoya

My Apologies, Marcel

It appears we did not collect sufficient info before contacting you. We made several assumptions.

It looks like there were 3 distinct studies, and some images between the studies conflicted.

In the image attached, I have masked PID, Name, and DOB, which were the same in all 3.

We will identify a pair of conflicting files from two of the studies and then interrogate further. I will then update you.

We have not seen a similar error again on this or other PostgreSQL installations so far.

Thank you.

We have done further tests, and looks like someone changed the study details on modality before resending.

So, the error does not occur when the exact same study is re-sent to Conquest. This is a good thing.

The error seems to occur when a duplicate SOP Instance UID is received with study/series details that do not match those of the old similar SOP Instance.

So, it is a different, less serious problem than what we initially thought. Resending failed studies is not an issue unless the user changes the study details before resending.

4/12/2025 6:19:28 PM [RADWEB] *** ERROR: duplicate key value violates unique constraint "dicomimages_pkey" DETAIL: Key (sopinstanc)=(1.2.156.112536.3.560.11000010138.1519099378125.131) already exists.

4/12/2025 6:19:28 PM [RADWEB] ***Failed PGSQLExec : INSERT INTO DICOMImages (SOPInstanc, SOPClassUI, ImageNumbe, EchoNumber, AcqDate, AcqTime, ReceivingC, SamplesPer, PhotoMetri, QRows, QColumns, BitsStored, ImageType, ImagePat, SeriesInst, AccessTime, ObjectFile, DeviceName) VALUES ('1.2.156.112536.3.560.11000010138.1519099378125.131', '1.2.840.10008.5.1.4.1.1.4', '4', '1', '20250411', '095211', 'L_BODY', '1', 'MONOCHROME2', '512', '512', '12', E'DERIVED\\PRIMARY\\OTHER\\PK', 'NAKR-850694', '1.2.156.112536.3.560.11000010138.1519099147953.35', 1744471136, E'Images\\20250411\\NAKR-850694\\0\\40155\\1.2.156.112536.3.560.11000010138.1519099378125.131.dcm', 'MAG0')

4/12/2025 6:19:28 PM [RADWEB] Query On Image

4/12/2025 6:19:28 PM [RADWEB] Issue Query on Columns: DICOMImages.SOPInstanc, DICOMSeries.SeriesInst, DICOMStudies.PatientID, DICOMStudies.StudyInsta

4/12/2025 6:19:28 PM [RADWEB] Values: DICOMStudies.PatientID = E'NAKR-850694' and DICOMSeries.StudyInsta = DICOMStudies.StudyInsta and DICOMImages.SeriesInst = DICOMSeries.SeriesInst

4/12/2025 6:19:28 PM [RADWEB] Tables: DICOMImages, DICOMSeries, DICOMStudies

4/12/2025 6:19:28 PM [RADWEB] Query Distinct Tables: DICOMImages, DICOMSeries, DICOMStudies

4/12/2025 6:19:28 PM [RADWEB] Columns : DICOMImages.SOPInstanc, DICOMSeries.SeriesInst, DICOMStudies.PatientID, DICOMStudies.StudyInsta

4/12/2025 6:19:28 PM [RADWEB] Where : DICOMStudies.PatientID = E'NAKR-850694' and DICOMSeries.StudyInsta = DICOMStudies.StudyInsta and DICOMImages.SeriesInst = DICOMSeries.SeriesInst

4/12/2025 6:19:28 PM [RADWEB] Records = 0

4/12/2025 6:19:28 PM [RADWEB] RemoveFiles 0 images

4/12/2025 6:19:28 PM [RADWEB] Add to Table: DICOMImages

4/12/2025 6:19:28 PM [RADWEB] Columns: SOPInstanc, SOPClassUI, ImageNumbe, EchoNumber, AcqDate, AcqTime, ReceivingC, SamplesPer, PhotoMetri, QRows, QColumns, BitsStored, ImageType, ImagePat, SeriesInst, AccessTime, ObjectFile, DeviceName

4/12/2025 6:19:28 PM [RADWEB] Values: '1.2.156.112536.3.560.11000010138.1519099139859.119', '1.2.840.10008.5.1.4.1.1.4', '1', '1', '20250411', '094755', 'L_BODY', '1', 'MONOCHROME2', '512', '512', '12', E'DERIVED\\PRIMARY\\OTHER\\PK', 'NAKR-850694', '1.2.156.112536.3.560.11000010138.1519098871343.34', 1744471136, E'Images\\20250411\\NAKR-850694\\0\\40154\\1.2.156.112536.3.560.11000010138.1519099139859.119.dcm', 'MAG0'

4/12/2025 6:19:28 PM [RADWEB] *** ERROR: duplicate key value violates unique constraint "dicomimages_pkey" DETAIL: Key (sopinstanc)=(1.2.156.112536.3.560.11000010138.1519099139859.119) already exists.

4/12/2025 6:19:28 PM [RADWEB] ***Failed PGSQLExec : INSERT INTO DICOMImages (SOPInstanc, SOPClassUI, ImageNumbe, EchoNumber, AcqDate, AcqTime, ReceivingC, SamplesPer, PhotoMetri, QRows, QColumns, BitsStored, ImageType, ImagePat, SeriesInst, AccessTime, ObjectFile, DeviceName) VALUES ('1.2.156.112536.3.560.11000010138.1519099139859.119', '1.2.840.10008.5.1.4.1.1.4', '1', '1', '20250411', '094755', 'L_BODY', '1', 'MONOCHROME2', '512', '512', '12', E'DERIVED\\PRIMARY\\OTHER\\PK', 'NAKR-850694', '1.2.156.112536.3.560.11000010138.1519098871343.34', 1744471136, E'Images\\20250411\\NAKR-850694\\0\\40154\\1.2.156.112536.3.560.11000010138.1519099139859.119.dcm', 'MAG0')

4/12/2025 6:19:28 PM [RADWEB] Query Tables: DICOMImages

4/12/2025 6:19:28 PM [RADWEB] Columns : ObjectFile, DeviceName

4/12/2025 6:19:28 PM [RADWEB] Where : SOPInstanc = '1.2.156.112536.3.560.11000010138.1519099140640.120' AND ImagePat = 'NAKR-850694'

4/12/2025 6:19:28 PM [RADWEB] Order : (null)

4/12/2025 6:19:28 PM [RADWEB] FreeStore Left 161220 on D:\

4/12/2025 6:19:28 PM [RADWEB] Add to Table: DICOMImages

4/12/2025 6:19:28 PM [RADWEB] 0000,0002 18 UI AffectedSOPClassUID "1.2.840.10008.1.1"

4/12/2025 6:19:28 PM [RADWEB] 0000,0100 2 US CommandField 48

4/12/2025 6:19:28 PM [RADWEB] Query On Image

4/12/2025 6:19:28 PM [RADWEB] Issue Query on Columns: DICOMImages.SOPInstanc, DICOMSeries.SeriesInst, DICOMStudies.PatientID, DICOMStudies.StudyInsta

4/12/2025 6:19:28 PM [RADWEB] Values: DICOMStudies.PatientID = E'NAKR-850694' and DICOMSeries.StudyInsta = DICOMStudies.StudyInsta and DICOMImages.SeriesInst = DICOMSeries.SeriesInst

4/12/2025 6:19:28 PM [RADWEB] RemoveFiles 0 images

4/12/2025 6:19:28 PM [RADWEB] Add to Table: DICOMImages

4/12/2025 6:19:28 PM [RADWEB] *** ERROR: duplicate key value violates unique constraint "dicomimages_pkey" DETAIL: Key (sopinstanc)=(1.2.156.112536.3.560.11000010138.1519099140640.120) already exists.

4/12/2025 6:19:28 PM [RADWEB] 0000,0002 18 UI AffectedSOPClassUID "1.2.840.10008.1.1"

4/12/2025 6:19:28 PM [RADWEB] 0000,0100 2 US CommandField 48

4/12/2025 6:19:28 PM [RADWEB] 0000,0110 2 US MessageID 1

4/12/2025 6:19:28 PM [RADWEB] Query On Image

4/12/2025 6:19:28 PM [RADWEB] Issue Query on Columns: DICOMImages.SOPInstanc, DICOMSeries.SeriesInst, DICOMStudies.PatientID, DICOMStudies.StudyInsta

4/12/2025 6:19:28 PM [RADWEB] Values: DICOMStudies.PatientID = E'NAKR-850694' and DICOMSeries.StudyInsta = DICOMStudies.StudyInsta and DICOMImages.SeriesInst = DICOMSeries.SeriesInst

4/12/2025 6:19:28 PM [RADWEB] Records = 0

4/12/2025 6:19:28 PM [RADWEB] RemoveFiles 0 images

4/12/2025 6:19:28 PM [RADWEB] Add to Table: DICOMImages

4/12/2025 6:19:28 PM [RADWEB] Columns: SOPInstanc, SOPClassUI, ImageNumbe, EchoNumber, AcqDate, AcqTime, ReceivingC, SamplesPer, PhotoMetri, QRows, QColumns, BitsStored, ImageType, ImagePat, SeriesInst, AccessTime, ObjectFile, DeviceName

4/12/2025 6:19:28 PM [RADWEB] Values: '1.2.156.112536.3.560.11000010138.1519099141437.121', '1.2.840.10008.5.1.4.1.1.4', '3', '1', '20250411', '094755', 'L_BODY', '1', 'MONOCHROME2', '512', '512', '12', E'DERIVED\\PRIMARY\\OTHER\\PK', 'NAKR-850694', '1.2.156.112536.3.560.11000010138.1519098871343.34', 1744471136, E'Images\\20250411\\NAKR-850694\\0\\40154\\1.2.156.112536.3.560.11000010138.1519099141437.121.dcm', 'MAG0'

4/12/2025 6:19:28 PM [RADWEB] 0000,0002 18 UI AffectedSOPClassUID "1.2.840.10008.1.1"

4/12/2025 6:19:28 PM [RADWEB] 0000,0100 2 US CommandField 48

4/12/2025 6:19:28 PM [RADWEB] 0000,0110 2 US MessageID 1

4/12/2025 6:19:28 PM [RADWEB] 0000,0800 2 US DataSetType 257

4/12/2025 6:19:28 PM [RADWEB] 0002,0010 17 UI TransferSyntaxUID "1.2.840.10008.1.2"

4/12/2025 6:19:28 PM [RADWEB] 9999,0400 26 LO ConquestConsoleComma "deletepatient:NAKR-850694"

4/12/2025 6:19:28 PM [RADWEB] Deleting patient: NAKR-850694

4/12/2025 6:19:28 PM [RADWEB] Query On Image

4/12/2025 6:19:28 PM [RADWEB] Issue Query on Columns: DICOMImages.SOPInstanc, DICOMSeries.SeriesInst, DICOMStudies.PatientID, DICOMStudies.StudyInsta

4/12/2025 6:19:28 PM [RADWEB] Values: DICOMStudies.PatientID = E'NAKR-850694' and DICOMSeries.StudyInsta = DICOMStudies.StudyInsta and DICOMImages.SeriesInst = DICOMSeries.SeriesInst

4/12/2025 6:19:28 PM [RADWEB] Tables: DICOMImages, DICOMSeries, DICOMStudies

4/12/2025 6:19:28 PM [RADWEB] Query Distinct Tables: DICOMImages, DICOMSeries, DICOMStudies

4/12/2025 6:19:28 PM [RADWEB] Columns : DICOMImages.SOPInstanc, DICOMSeries.SeriesInst, DICOMStudies.PatientID, DICOMStudies.StudyInsta

4/12/2025 6:19:28 PM [RADWEB] Where : DICOMStudies.PatientID = E'NAKR-850694' and DICOMSeries.StudyInsta = DICOMStudies.StudyInsta and DICOMImages.SeriesInst = DICOMSeries.SeriesInst

4/12/2025 6:19:28 PM [RADWEB] Order : (null)

4/12/2025 6:19:28 PM [RADWEB] Records = 0

4/12/2025 6:19:28 PM [RADWEB] RemoveFiles 0 images

4/12/2025 6:19:28 PM [RADWEB] Add to Table: DICOMImages

4/12/2025 6:19:28 PM [RADWEB] Columns: SOPInstanc, SOPClassUI, ImageNumbe, EchoNumber, AcqDate, AcqTime, ReceivingC, SamplesPer, PhotoMetri, QRows, QColumns, BitsStored, ImageType, ImagePat, SeriesInst, AccessTime, ObjectFile, DeviceName

4/12/2025 6:19:28 PM [RADWEB] Values: '1.2.156.112536.3.560.11000010138.1519099142218.122', '1.2.840.10008.5.1.4.1.1.4', '4', '1', '20250411', '094755', 'L_BODY', '1', 'MONOCHROME2', '512', '512', '12', E'DERIVED\\PRIMARY\\OTHER\\PK', 'NAKR-850694', '1.2.156.112536.3.560.11000010138.1519098871343.34', 1744471136, E'Images\\20250411\\NAKR-850694\\0\\40154\\1.2.156.112536.3.560.11000010138.1519099142218.122.dcm', 'MAG0'

4/12/2025 6:19:28 PM [RADWEB] *** ERROR: duplicate key value violates unique constraint "dicomimages_pkey" DETAIL: Key (sopinstanc)=(1.2.156.112536.3.560.11000010138.1519099142218.122) already exists.

4/12/2025 6:19:28 PM [RADWEB] ***Failed PGSQLExec : INSERT INTO DICOMImages (SOPInstanc, SOPClassUI, ImageNumbe, EchoNumber, AcqDate, AcqTime, ReceivingC, SamplesPer, PhotoMetri, QRows, QColumns, BitsStored, ImageType, ImagePat, SeriesInst, AccessTime, ObjectFile,

Noted.

Yes, it's not a critical feature... Nice to have.

Thank you.

Hi Marcel,

Conquest, in our setup, seems to zip logs (and other important files) daily and store them in the log folder. BTW, this is really helpful!

However, it looks like these log folders can grow quite large for a busy center.

Is there a way Conquest can automatically delete the oldest zipped log files, say after a month?

Thank you.

Looks like Conquest with Postgres behaves differently from Conquest with SQLite.

In SQLite, sending a duplicate SOP instance to Conquest does not cause any conflicts in the db. However, in Postgres, the duplicate SOP is rejected.

Here is an actual scenario that led to the attached error log messages.

We are using Conquest as a router.

Conquest forwards images over the internet, which (internet) can be unstable.

So, almost always, Conquest will receive images from modality faster than it can send.

Some files have been received into Conquest but are still in the queue for sending.

If Conquest shuts down, e.g., in this case I think it was due to a power outage, the forward queue in memory will be lost.

When the PC powers back on, there are some files that are in the Conquest database but did not reach the destination server where Conquest was to send them.

When the user notices this discrepancy, they resend the study from the modality to try to complete the image number on the destination PACS.

However, this is not possible because the images are rejected and therefore does not update the destination PACS unless the old study is deleted from db so that new one can be sent.

Conquest log:

20250411 11:06:16 ***Error saving to SQL: Images\20250403\NAKR-000111(N)\S-202504037085\4\1.2.156.14702.1.1003.64.2.20250403113829982576.dcm

20250411 11:06:16 *** ERROR: duplicate key value violates unique constraint "dicomimages_pkey"

DETAIL: Key (sopinstanc)=(1.2.156.14702.1.1003.64.2.20250403113829982576) already exists.

Postgres log:

2025-04-11 10:50:14 EAT STATEMENT: INSERT INTO DICOMImages (SOPInstanc, SOPClassUI, ImageNumbe, ImageDate, ImageTime, AcqDate, AcqTime, AcqNumber, SliceLocat, SamplesPer, PhotoMetri, QRows, QColumns, BitsStored, ImageType, ImagePat, SeriesInst, AccessTime, ObjectFile, DeviceName) VALUES ('1.2.156.14702.1.1003.64.2.20250403113832744734', '1.2.840.10008.5.1.4.1.1.2', '113', '20250403', '113832.000', '20250403', '113649.173', '4', '757.900024414063', '1', 'MONOCHROME2', '512', '512', '16', E'ORIGINAL\\PRIMARY\\AXIAL\\HELICAL', '963191(N)', '1.2.156.14702.1.1003.64.1.202504031131414741082585856828', 1744357792, E'Images\\20250403\\963191(N)\\S-202504037085\\4\\1.2.156.14702.1.1003.64.2.20250403113832744734.dcm', 'MAG0')

2025-04-11 10:50:14 EAT ERROR: duplicate key value violates unique constraint "dicomimages_pkey"

2025-04-11 10:50:14 EAT DETAIL: Key (sopinstanc)=(1.2.156.14702.1.1003.64.2.20250403113832744734) already exists.

Is there a trick we can employ to convince Postgres to behave like SQLite in this respect?

Thank you.

Thank you for your answer.

This retry helps a lot.

Actually, I believe the retry duration (probably less than 30 seconds in total) is rather short. I have not personally observed or tested this, but I believe that Postgres may take significantly longer when repairing a large database. I would have put it at 30 minutes to 1 hour total retry duration, e.g every 30 seconds 60 times. You may consider this in future.

Great!!!

Thank you Marcel.

Checking.

What is the expected behavior? Are there any settings maybe in the INI file we should create/adjust?

Thank you Marcel for your response.

This is acknowledged.

We will try figure out something, and if not possible, just use Conquest the way it is. Users can always manually resend studies if necessary.

Noted.

Thank you.

I will try the stopgap measure you have indicated for now.

We are also changing our installations to use dicom send to Conquest instead of import from folder.

Thank you.

Thank you Marcel, for your response.

Just to clarify, do you mean that:

1. There something we can do to make it retry? If so, kindly give me a pointer.

2. You could make changes to code on your end to make it retry?.. If so, thank you. We will wait for the changes.

Regards.

Conquest seems to be doing well with Postgres.

However, there is a curious error I have seen a couple of times.

When the computer restarts (sometimes after a power outage), Postgres may take a few seconds to be available.

It seems like Conquest just checks about 3 times within 1-2 seconds and gives up.

When Postgres becomes available, Conquest does not know or try to find out.

In the two scenarios in which I have encountered this issue, Conquest was set to automatically import from a watched folder. Images just remain in the watched folder even when Postgres is back online.

Restarting postgres does not make any difference.

Everything works OK again after Conquest restart.

I also noted that in Conquest's "frozen" state, although it does not process items in watched folders, it processes images sent via C-move over the network. It is like an incoming DICOM association prompts it to recheck Postgres. However, even after receiving such images via DICOM network, it does not remember to process items in the watched folder unless Conquest itself is restarted.

Attached below is a side-by-side comparison of Conquest and Postres logs. Please take note of the time stamps.

Is there a way to set Conquest so that it checks for DB availability for longer or any other way to address this issue?

Thank you Marcel!

Hi Marcel,

When forwarding images, unless there is forwarding failure, it appears that the queued items are kept in RAM.

If there is a power outage, the queue is lost, leading to partial studies on the receiving server, unless the study is resent all over again from the source.

One could keep QueueSize option in dicom.ini low, say 5, but this can cause errors when forwarding via a slow network. It means that Conquest will slow down receiving of images to keep those in memory, pending sending at only 5.

One solution to this could be to keep this queue in a file on disk. This would make a big difference. When Conquest restarts (e.g., after a power outage), it checks the file and continues from where it left off.

Have you ever considered such an option, or do you have another trick to address this issue?

Thank you.

Hi Marcel,

My apologies; I think I might have overreacted when I noticed one error with Postgres, having had quite some trouble with MySQL.

The Postgres error appears to have been an isolated incident.

I have run Postgres on 5 fairly busy servers (including the one that had the error) for two days with no more errors.

So far, it appears that Postgres is not affected, and this is good enough for us; we will just forget about Mysql for now.

In case of any more errors that we are unable to fix, we will let you know.

Thank you.

Here is a log from Posgres Installation:

20250331 07:54:53 ***Error saving to SQL on retry: Images\20250331\HOSP-\3\5\1.3.12.2.1107.5.2.20.156095.2025033107294119304102553.dcm

20250331 07:54:53 *** no connection to the server

20250331 07:54:53 *** no connection to the server

20250331 07:54:53 ***Error saving to SQL: Images\20250331\HOSP-\3\5\1.3.12.2.1107.5.2.20.156095.202503310729415760602537.dcm

20250331 07:54:53 *** no connection to the server

20250331 07:54:53 ***Error saving to SQL on retry: Images\20250331\HOSP-\3\5\1.3.12.2.1107.5.2.20.156095.202503310729415760602537.dcm

20250331 07:54:53 *** no connection to the server

20250331 07:54:53 *** no connection to the server

I restarted Postgres and Conquest on the computer that had those errors and have not seen the errors for some hours now.

I have also enabled debug mode. Will post the logs here when I get the errors.

I will also check RAM usage, though we saw the mysql errors on several Windows computers/servers with different installed amounts of RAM including one with very high reserve RAM (see attached). Note that on the server whose screenshot is attached, we had frequent errors with Mysql but no errors with Postgres for several hours now.

Thank you.

Hi Marcel,

We decided to move from SQLite in the hope of enhancing Conquest performance, especially with larger DBs.

We are using Conqeust version 1.5.0e

First, we tried Mysql 8.0.41 with legacy authentication.

We got a bunch of sql errors:

Enabling Debug in Conquest added more info, basically that its unable to add to DB and that "Mysql server has gone away."

20250328 10:35:30 ***SQL: INSERT INTO DICOMImages (SOPInstanc, SOPClassUI, ImageNumbe, ImageDate, ImageTime, AcqDate, AcqTime, AcqNumber, SliceLocat, SamplesPer, PhotoMetri, QRows, QColumns, BitsStored, ImageType, ImagePat, SeriesInst, AccessTime, ObjectFile, DeviceName) VALUES ('1.3.12.2.1107.5.1.7.168424.30000025032808523205400000613', '1.2.840.10008.5.1.4.1.1.2', '82', '20250328', '093731.373000', '20250328', '093731.373000', '301', '-1182.943', '1', 'MONOCHROME2', '1134', '512', '16', 'ORIGINAL\\PRIMARY\\AXIAL\\CT_SOM5 MPR', 'UCI-CT-', '1.3.12.2.1107.5.1.7.168424.30000025032808523205400000528', 1743183328, 'Images\\20250328\\UCI-CT-\\e37bce77-8f23-4b\\8\\1.3.12.2.1107.5.1.7.168424.30000025032808523205400000613.dcm', 'MAG0')

20250328 10:35:30 ***Error: MySQL server has gone away

20250328 10:35:30 ***Error saving to SQL on retry: Images\20250328\UCI-CT-\e37bce77-8f23-4b\8\1.3.12.2.1107.5.1.7.168424.30000025032808523205400000613.dcm

20250328 10:35:30 ***Failed MYSQLExec : INSERT INTO DICOMImages (SOPInstanc, SOPClassUI, ImageNumbe, ImageDate, ImageTime, AcqDate, AcqTime, AcqNumber, SliceLocat, SamplesPer, PhotoMetri, QRows, QColumns, BitsStored, ImageType, ImagePat, SeriesInst, AccessTime, ObjectFile, DeviceName) VALUES ('1.3.12.2.1107.5.1.7.168424.30000025032808523205400000614', '1.2.840.10008.5.1.4.1.1.2', '83', '20250328', '093731.373000', '20250328', '093731.373000', '301', '-1182.908', '1', 'MONOCHROME2', '1134', '512', '16', 'ORIGINAL\\PRIMARY\\AXIAL\\CT_SOM5 MPR', 'UCI-CT-', '1.3.12.2.1107.5.1.7.168424.30000025032808523205400000528', 1743183328, 'Images\\20250328\\UCI-CT-\\e37bce77-8f23-4b\\8\\1.3.12.2.1107.5.1.7.168424.30000025032808523205400000614.dcm', 'MAG0')

20250328 10:35:30 ***Error: MySQL server has gone away

20250328 10:35:30 ***Unable to DB.Add()

20250328 10:35:30 ***SQL: INSERT INTO DICOMImages (SOPInstanc, SOPClassUI, ImageNumbe, ImageDate, ImageTime, AcqDate, AcqTime, AcqNumber, SliceLocat, SamplesPer, PhotoMetri, QRows, QColumns, BitsStored, ImageType, ImagePat, SeriesInst, AccessTime, ObjectFile, DeviceName) VALUES ('1.3.12.2.1107.5.1.7.168424.30000025032808523205400000614', '1.2.840.10008.5.1.4.1.1.2', '83', '20250328', '093731.373000', '20250328', '093731.373000', '301', '-1182.908', '1', 'MONOCHROME2', '1134', '512', '16', 'ORIGINAL\\PRIMARY\\AXIAL\\CT_SOM5 MPR', 'UCI-CT-', '1.3.12.2.1107.5.1.7.168424.30000025032808523205400000528', 1743183328, 'Images\\20250328\\UCI-CT-\\e37bce77-8f23-4b\\8\\1.3.12.2.1107.5.1.7.168424.30000025032808523205400000614.dcm', 'MAG0')

20250328 10:35:30 ***Error: MySQL server has gone away

20250328 10:35:30 ***Error saving to SQL: Images\20250328\UCI-CT-\e37bce77-8f23-4b\8\1.3.12.2.1107.5.1.7.168424.30000025032808523205400000614.dcm

20250328 10:35:30 ***Failed MYSQLExec : INSERT INTO DICOMImages (SOPInstanc, SOPClassUI, ImageNumbe, ImageDate, ImageTime, AcqDate, AcqTime, AcqNumber, SliceLocat, SamplesPer, PhotoMetri, QRows, QColumns, BitsStored, ImageType, ImagePat, SeriesInst, AccessTime, ObjectFile, DeviceName) VALUES ('1.3.12.2.1107.5.1.7.168424.30000025032808523205400000614', '1.2.840.10008.5.1.4.1.1.2', '83', '20250328', '093731.373000', '20250328', '093731.373000', '301', '-1182.908', '1', 'MONOCHROME2', '1134', '512', '16', 'ORIGINAL\\PRIMARY\\AXIAL\\CT_SOM5 MPR', 'UCI-CT-', '1.3.12.2.1107.5.1.7.168424.30000025032808523205400000528', 1743183328, 'Images\\20250328\\UCI-CT-\\e37bce77-8f23-4b\\8\\1.3.12.2.1107.5.1.7.168424.30000025032808523205400000614.dcm', 'MAG0')

20250328 10:35:30 ***Error: MySQL server has gone away

20250328 10:35:30 ***Unable to DB.Add()

I have tried many suggested options, including increasing max packed size in Mysql, increasing timeouts in Mysql, pointing Conquest to 127.0.0.1 instead of localhost, etc.

The one I was not able to try on Mysql was the suggestion that the client app should first initiate a database connection before attempting to write data to db.

We decided to abandon Mysql and try Postgresql. We opted for V 9.6.24 so we can use legacy authentication.

Unfortunately, we are getting similar SQL errors.

Is there a way to fix this, e.g have Conquest initiate a db connected before starting to send a set of images, or any other trick ....?

Note that the data is eventually saved to db, but after some seconds/minutes of failure.

Thank you.

Emmanuel.

Thank you for the advice.

We use Conquest on several machines. A few are servers and are powered on 24/7. Nightly cleaning may work OK with these ones.

Most are regular Windows PCs, many of which are shut down in the evening and powered on again the following day. Nightly cleaning might not be ideal for these ones.

Will handle it case by case.

Regards.

Noted.

Retrying is critical to our workflow.

We will stay with export converters.

Thank you!

Outgoing JPEG-LS lossy compression seems to be working now!!

This will be very useful to us.

Thank you Marcel!

Will continue to test and let you know in case of any issue....