Mirth Connect Database Reader polling issues come from four places: a poll interval shorter than the query's execution time causing overlapping polls, a missing or incorrect post-process update query, a select query with no WHERE clause to exclude processed rows, or database load spikes causing query timeouts. Fix it by spacing the poll interval beyond worst-case query time, fixing the update query's targeting, adding a status column and filter to the select query, and increasing the query timeout while optimizing the query itself. Prevent recurrence by testing under peak load, logging row counts per poll, and alerting on poll failures.
Quick answer
Mirth Connect Database Reader polling issues usually show up as rows being processed twice, skipped entirely, or a java.sql.SQLTimeoutException in the server log when a poll takes too long to finish. Unlike a connector that fails outright, a misbehaving poll often keeps running while quietly getting the wrong rows, which makes it easy to miss until someone notices missing or duplicated data downstream.
Below is what actually causes a Database Reader to poll incorrectly, the fix for each cause, and how to verify it's working correctly. Our free Mirth Health Check can review your poll and update queries directly — part of the Mirth Connect support work we do for US healthcare teams.
What Causes Database Reader Polling Problems?
A Database Reader depends on its poll interval, its select query, and its post-process update query all working together correctly, and a mismatch between any two of these produces a different but related symptom, from overlapping polls to rows that are never marked as handled at all.
Poll Interval Set Shorter Than Query Execution Time
If the configured poll interval is shorter than how long the select query actually takes to run under load, polls can overlap and pick up the same rows twice before the first pass has finished marking them as processed.
Missing or Incorrect Post-Process Update Query
If the update query that marks rows as processed doesn't run reliably, or targets the wrong column, the same rows will be picked up again on the next poll even though they were already sent successfully once.
Select Query Missing a WHERE Clause to Exclude Processed Rows
A select query without a status or timestamp filter will return every matching row on every poll, relying entirely on the update query to prevent reprocessing, which fails immediately if that update query has any issue at all.
Database Load Spikes Causing Poll Queries to Time Out
Under heavy load elsewhere on the database, the Database Reader's own poll query can time out before completing, throwing java.sql.SQLTimeoutException and skipping that poll cycle entirely without picking up any new rows.
How to Fix Database Reader Polling Issues
Confirm which of the four causes matches your actual symptom — duplicates, skipped rows, or timeouts — before changing any setting, since the fix for overlapping polls is different from the fix for a query that's simply too slow.
Space Poll Interval Beyond Worst-Case Query Time
Measure how long the select query actually takes under peak load, not average load, and set the poll interval comfortably beyond that worst-case time so consecutive polls never overlap even during a busy period.
Fix the Post-Process Query to Reliably Mark Rows
Review the update query's WHERE clause and confirm it targets the exact same rows the select query just returned, using the same identifying column, so every processed row is reliably marked before the next poll runs.
Add a Status Column and Filter to the Select Query
Add an explicit status or processed-flag column to the source table if one doesn't exist, and filter the select query on it directly, so the query itself excludes already-processed rows rather than relying solely on the update step.
Increase Query Timeout and Optimize the Poll Query
Raise the connector's query timeout to accommodate genuine load spikes, and review the select query's execution plan for missing indexes that would otherwise make every poll slower than it needs to be.
How to Prevent Polling Issues From Recurring
Since polling problems often develop gradually as message volume grows, prevention is mostly about catching a query that's gotten slower or an update that's stopped working before it causes visible duplicates or gaps in the data.
Test Polling Under Peak Load Before Going Live
Run the channel against a realistic peak load in staging before deploying to production, since a poll interval that looks fine against light test data can overlap badly once real volume hits the same query.
Log Every Poll's Row Count for Trend Visibility
Logging how many rows each poll returns gives you a simple trend line that flags an unusual spike or drop immediately, well before someone downstream notices data is missing or duplicated.
Review the Update Query Whenever the Table Schema Changes
Any change to the source table's columns should trigger a review of both the select and update queries, since a renamed or restructured column can silently break the update without throwing any error at all.
Alert on Poll Failures Immediately
Set an alert for timeout or SQL exceptions on the Database Reader connector specifically, so a failing poll cycle is caught within minutes rather than discovered once a gap in the data has already grown for days.
When to call for help
If duplicates or gaps keep appearing after fixing the interval and update query, the cause is often a subtle mismatch between the select and update queries' identifying columns that's easy to miss on a manual review. Our free Mirth Connect health check reviews your poll and update queries directly as part of the standard diagnostic.
Have the exact error? Send us the log, or check pricing for ongoing support plans.
Polling behavior looking off right now? Free Mirth health check — a written 12-point audit report in 48 hours, no cost.