View Issue Details

IDProjectCategoryView StatusLast Update
00032482 - Next Dev List (Holding Area)Bugpublic2019-06-15 11:36
ReporterK7ZCZAssigned ToK7ZCZ 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Summary0003248: bad parameters for ODBC recordsets throughout Logbook
Description
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);

            try
            {
                rs1.Open(CRecordset::snapshot, NULL, CRecordset::forwardOnly       | 
                                                     CRecordset::readOnly          | 
                                                     CRecordset::noDirtyFieldCheck | 
                                                     CRecordset::useExtendedFetch  | 
                                                     CRecordset::executeDirect);
            }
            catch(CDBException* pEx)
            {
                pEx->m_strError.Remove(_T('\n'));

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


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.
ModuleLogbook
Sub-ModuleData
TestingNot Started

Relationships

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

Activities

K7ZCZ

2019-04-17 13:06

administrator   ~0007869

Fixed with this checkin to the 6.7 branch:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4954

K7ZCZ

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:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4993

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)