An open DView instance will prevent new eplusout.sql from being written

[evanweaver]

From @eringold on November 14, 2017 21:38

Steps to replicate:

1. Open DView to review results of a simulated OpenStudio project
2. Make a change in that same project and re-simulate
3. eplusout.sql in the project folder will not be over-written with the new results (can be verified with the file time stamp, or with queries of the sql returning old stale results).

From a practitioner POV, model troubleshooting sometimes involves repeatedly running simulations and comparing results. This was easy with ResultsViewer, where old results would be retained while new ones could be examined side-by-side in a new instance. A DView instance which locks the sql file from being over-written makes this process much more difficult. Additionally, the OS Results measure will show updated results, but other measures that rely on the project folder eplusout.sql will be returning out of date results.

Copied from original issue: NREL/OpenStudio#2845

[eringold]

I linked the OS one here too: #40

Thanks for looking into this!

[evanweaver]

No worries @eringold. Just FYI, we are now putting tickets for PAT, DView, server, etc in their respective GitHub repos. If you are getting a lot of emails about moving tickets, it's because of this new approach. THanks, Evan.

[eringold]

@evanweaver No problem; Dan advised to put an issue in both, so that's what I did.

FYI I dug into this a little when I first opened the issue, and found this difference in how DView opens the SQLite database file here:

wex/src/dview/dvfilereader.cpp

Line 995 in 16b812b

int success = sqlite3_open_v2(filename.c_str(), &db, SQLITE_OPEN_READONLY | SQLITE_OPEN_EXCLUSIVE, nullptr);

versus how (maybe) ResultsViewer was doing it:
https://github.com/jasondegraw/ResultsViewer/blob/60cdea41668cabd06a397f6516498abbae0f2a77/src/SqlFile.hpp#L113 .

Perhaps the use of the flag SQLITE_OPEN_READONLY (vs SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE) could be causing the problem?

[evanweaver]

@eringold thanks for the legwork!

[jmarrec]

I just tried that on Ubuntu 16.04 with DView (wxWidgets 3.1.1) Version Mar 21 2018.
Had a SQL file open in DView, rerun the simulation, and I see the timestamp did change just fine.

The line @eringold pointed to is still the same in current develop, so this might be a platform-specific problem.