View Issue Details

IDProjectCategoryView StatusLast Update
0003248Ham Radio DeluxeBugpublic2019-11-08 02:32
ReporterK7ZCZAssigned ToWA9PIE 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version6.5.0.197 
Target VersionFixed in Version6.7.0.244 
Summary0003248: bad parameters for ODBC recordsets throughout Logbook
DescriptionThe 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 ReproduceHere'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
Testing N/A

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

K7ZCZ

2019-08-31 11:37

administrator   ~0008480

Turns out the official MySQL drivers don't support dynasets (!) so this checkin backs off to snapshot.
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5154

WA9PIE

2019-09-22 19:24

administrator   ~0008585

Is there any way we can test this? If not, I'm willing to accept the developer's work as complete.

K7ZCZ

2019-09-24 20:53

administrator   ~0008645

The tests would be to comprehensively exercise the logbook product's database interactions throughout, at least once, against each of the three supported back ends: Access, SQL Server, and MySQL.

WA9PIE

2019-09-24 22:48

administrator   ~0008650

I've tested it with Access.

g3ucq

2019-10-23 03:48

viewer   ~0008920

Unable to test

WA9PIE

2019-10-23 03:52

administrator   ~0008922

Due to the nature of this change, it is difficult to repro/test. Therefore, I'll accept it as complete and close it.

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)
2019-08-30 13:40 K7ZCZ Project 2 - Next Dev List (Holding Area) => 3 - Current Dev List
2019-08-30 13:54 K7ZCZ Fixed in Version => 6.7.0.226
2019-08-31 11:37 K7ZCZ Note Added: 0008480
2019-09-22 19:24 WA9PIE Note Added: 0008585
2019-09-24 20:53 K7ZCZ Note Added: 0008645
2019-09-24 22:48 WA9PIE Note Added: 0008650
2019-10-21 17:01 K7ZCZ Fixed in Version 6.7.0.226 => 6.7.0.235
2019-10-23 03:48 g3ucq Note Added: 0008920
2019-10-23 03:52 WA9PIE Assigned To K7ZCZ => WA9PIE
2019-10-23 03:52 WA9PIE Status resolved => closed
2019-10-23 03:52 WA9PIE Description Updated View Revisions
2019-10-23 03:52 WA9PIE Steps to Reproduce Updated View Revisions
2019-10-23 03:52 WA9PIE Testing Not Started => N/A
2019-10-23 03:52 WA9PIE Note Added: 0008922
2019-11-08 02:12 WA9PIE Fixed in Version 6.7.0.235 => 6.7.0.244
2019-11-08 02:32 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe