View Issue Details

IDProjectCategoryView StatusLast Update
00027201 - BacklogBugpublic2020-07-16 04:32
ReporterK7ZCZAssigned ToK7ZCZ 
Status assignedResolutionreopened 
PlatformIntel i7-5960XOSWindows 10 Professional x64OS Version16299
Summary0002720: Logbook: Poor error handling when database opening fails
DescriptionIf the Logbook tries to open a database and that database can't be opened, error handling is very poor. This should be cleaned up.
Steps To Reproduce1) Setup a data source on a server in the Logbook; SQL Server, Oracle, MySQL, whatever you'd like.
2) Build a logbook database on it
3) Close the logbook
4) Stop the database server
5) Restart logbook
6) The Logbook, at restart, will try to open that database. It can't, since the server is stopped.

BUG#1) The timeout for opening the database is very long; it doesn't need to be. The user sits around and wonders what's happening.

7) An error appears that the database couldn't be opened.

BUG#2) It's pretty hard to understand and isn't completely accurate; "The data source 'MySQLTest1' does not exist. (#2 - Connect = DSN=MySQLTest1)". The data source actually does exist; it just couldn't be opened.

8) The logbook opens a view associated with that database. It's blank, since the connection failed, but the user doesn't know that. This state is pretty bad, since it implies that their data is gone; and allows them to try to do work against a database that isn't connected.

BUG#3) The view shouldn't be opened.

BUG#4) In this state, the logbook isn't at all stable. Eventually, a background task or user action will try to access the broken database connection and cause a crash.

TagsNo tags attached.
TestingNot Started


related to 0002316 closedK7ZCZ Ham Radio Deluxe Intermittement API reports data added when data NOT added 



2018-05-24 13:07

developer   ~0005104

Addressed with this checkin;


2018-05-29 11:28

reporter   ~0005133

On trying to open a second (MySQL) database, logbook crashed and mini-dump produced.

HRDLogbook_20180529_162054.mdmp (801,381 bytes)


2018-05-29 20:57

developer   ~0005147

It doesn't look like the provided dump is related to this change. I've opened 2752 to track it.

I don't think that report should block shipping the beta.

Issue History

Date Modified Username Field Change
2018-05-15 13:04 K7ZCZ New Issue
2018-05-18 09:26 K7ZCZ Relationship added related to 0002316
2018-05-24 13:07 K7ZCZ Assigned To => K7ZCZ
2018-05-24 13:07 K7ZCZ Status new => resolved
2018-05-24 13:07 K7ZCZ Resolution open => fixed
2018-05-24 13:07 K7ZCZ Note Added: 0005104
2018-05-26 23:27 K7ZCZ Fixed in Version =>
2018-05-29 11:28 g3ypp File Added: HRDLogbook_20180529_162054.mdmp
2018-05-29 11:28 g3ypp Note Added: 0005133
2018-05-29 15:18 WA9PIE Status resolved => assigned
2018-05-29 15:18 WA9PIE Resolution fixed => reopened
2018-05-29 15:18 WA9PIE Fixed in Version =>
2018-05-29 15:18 WA9PIE Testing Not Started => Beta Failed
2018-05-29 20:57 K7ZCZ Note Added: 0005147
2019-02-10 22:19 WA9PIE Severity major => crash
2019-09-25 18:19 K7ZCZ Testing Beta Failed => Not Started
2020-07-02 02:11 WA9PIE Project 3 - Current Dev List => 2 - Next Dev List (Holding Area)
2020-07-16 04:32 WA9PIE Project 2 - Next Dev List (Holding Area) => 1 - Backlog