View Issue Details

IDProjectCategoryView StatusLast Update
00032482 - Next Dev List (Holding Area)Bugpublic2019-06-15 11:36
ReporterK7ZCZAssigned ToK7ZCZ 
Status resolvedResolutionfixed 
Summary0003248: bad parameters for ODBC recordsets throughout Logbook
The Logbook application uses recordsets to access the database. ODBC recordsets have several parameters which govern their behavior. Almost all locations where a recordset is opened use either semantically incorrect or syntactically incorrect parameters.
Steps To Reproduce
Here's an example:

            CRecordsetCount rs1(&db, strDisplayColumn, QSO_TABLE_NAME, m_strSQL);

                rs1.Open(CRecordset::snapshot, NULL, CRecordset::forwardOnly       | 
                                                     CRecordset::readOnly          | 
                                                     CRecordset::noDirtyFieldCheck | 
                                                     CRecordset::useExtendedFetch  | 
            catch(CDBException* pEx)

                AddResult(_T("Error"), _T("Getting record count -"));
                AddResult(_T(""),      _T("Error:  %s"), pEx->m_strError);
                AddResult(_T(""),      _T("Filter: %s"), m_strSQL);

The first parameter is an open mode, and should be one of: dynaset, snapshot, dynamic, or forwardOnly.

This mode defines the management of the recordset, but also defines locking and concurrency behaviour. "snapshot" is the most restrctive, least performant access path. Either all records are locked (so they can't be changed by other processes) or a copy of those records is made (maybe in memory, maybe versioned on disk, maybe some other way).

The third parameter is a set of options. There are many, but "forwardOnly" isn't one of them -- that's actually an open mode and totally incompatible with the "snapshot" mode.

We're lucky this combination of options work at all, since they're invalid.

There's no reason for the application to use snapshot isolation. There's only one spot where the application writes to the database; any reads can take dirty reads of any type and not have an issue with concurrency. Since transactions aren't used by the database (and recordsets aren't even carefully closed) the cope of the locks placed by snapshot isolation are left around, consuming resources, and impedede performance.

We should review all the spots where recordsets are opened and make sure they don't have bogus parameters.
TagsNo tags attached.
TestingNot Started


related to 0003299 new 1 - Backlog V6.5.0.207 Connecting to DX cluster locks Logbook 



2019-04-17 13:06

administrator   ~0007869

Fixed with this checkin to the 6.7 branch:


2019-05-25 12:16

administrator   ~0007947

too aggressive around the recordset that adds an ALE entry, so I've fixed it with this checkin:

Issue History

Date Modified Username Field Change
2019-03-18 00:04 K7ZCZ New Issue
2019-04-17 09:40 K7ZCZ Relationship added related to 0003299
2019-04-17 13:06 K7ZCZ Assigned To => K7ZCZ
2019-04-17 13:06 K7ZCZ Status new => resolved
2019-04-17 13:06 K7ZCZ Resolution open => fixed
2019-04-17 13:06 K7ZCZ Note Added: 0007869
2019-05-25 12:16 K7ZCZ Note Added: 0007947
2019-06-15 11:36 WA9PIE Project 3 - Current Dev List => 2 - Next Dev List (Holding Area)