Database Failure (Windows 8.1)

[MTkeg]

I downloaded the latest Windows compilation from the "Actions" tab (Windows # 447) and installed the software. The installation completed successfully. When I try and run the "brewtarget.exe" I am prompted with a "Database Failure" indicating the following: Could not open SQLite DB file C:/Users/XXXXX/AppData/Roaming/brewtarget-debug/database.sqlite. Driver not loaded Driver not loaded

Once I click OK we are prompted with an "Application Terminates" window stating The application encountered a fatal error. Error message: Could not open SQLite DB file C:/Users/XXXXX/AppData/Roaming/brewtarget-debug/database.sqlite. Driver not loaded Driver not loaded

When you click OK the program terminates.

One concern I have is that the slashes in the Errors are forward slashes and not back slashes. I was able to navigate to C:\Users\XXXXX\AppData\Roaming\brewtarget-debug\database.sqlite successfully and the file opens.

I successfully have 2.3.0 running on my machine but would like to have some of the updates that 2.4.0 has to offer.

Any help would be appreciated.

[matty0ung]

Sorry to hear you're having problems.

Normally it shouldn't matter about the forward slashes in the filenames because Qt (the GUI framework on top of which we write the software) will convert them to whatever the underlying OS needs - eg backslashes on Windows.

From a quick search, it seems the "Driver not loaded Driver not loaded" might be signifying a problem with the installation of Qt - ie that the SQLite database driver DLLs are not being found even though they should normally ship with Qt.

It's good to know 2.3.0 is working as that should help narrow things down. I don't know enough about how the 2.3.0 release was put together to be sure, but it could be that it's using the "release" SQLite drivers whereas the 2.4 compilation you downloaded wants the "debug" drivers. (See for instance https://stackoverflow.com/questions/46811514/qsqldatabase-qsqlite-driver-not-loaded-only-in-debug-mode where someone else using Qt on Windows seems to be having a similar problem.) Equally, it could be some problem with how we're building the Windows package for 2.4 (though I'm not aware it's changed much since 2.3.0).

I don't have a Windows build set up, so I'm mostly just speculating here. Hopefully one of the other developers (maybe @mattiasmaahl) will be able to jump in and assist.

[mattiasmaahl]

Hello, thank you for your feedback!

A few notes on the above. the Nightly build is build with the DEBUG flag meaning that the database location is not the same as for the Release version. i.e. C:/Users/XXXXX/AppData/Roaming/brewtarget-debug/database.sqlite <- NOTE the "-debug" in the path there. the release version would look in C:/Users/XXXXX/AppData/Roaming/brewtarget/database.sqlite location. I think that is the reason I does not find the database. But if I'm remembering correctly, the application should create a new database if it does not find it... Will have to look into the code to see. maybe @matty0ung or @mikfire can shed some light on it?

as for the / slashes in the path, That's how the QT framework sees the path, regardless of the system it's on. It called "canonical path" I believe.

As for giving you a tip on how to get the Ngihtly build working as it is now I would copy the current database to the location that 2.4.0 is expecting. i.e. C:/Users/XXXXX/AppData/Roaming/brewtarget-debug/database.sqlite If I remember correctly the default database location for the 2.3.0 version was in the Programs install-directory.

[MTkeg]

Hello, thank you for your feedback!

A few notes on the above. the Nightly build is build with the DEBUG flag meaning that the database location is not the same as for the Release version. i.e. C:/Users/XXXXX/AppData/Roaming/brewtarget-debug/database.sqlite <- NOTE the "-debug" in the path there. the release version would look in C:/Users/XXXXX/AppData/Roaming/brewtarget/database.sqlite location. I think that is the reason I does not find the database. But if I'm remembering correctly, the application should create a new database if it does not find it... Will have to look into the code to see. maybe @matty0ung or @mikfire can shed some light on it?

as for the / slashes in the path, That's how the QT framework sees the path, regardless of the system it's on. It called "canonical path" I believe.

As for giving you a tip on how to get the Ngihtly build working as it is now I would copy the current database to the location that 2.4.0 is expecting. i.e. C:/Users/XXXXX/AppData/Roaming/brewtarget-debug/database.sqlite If I remember correctly the default database location for the 2.3.0 version was in the Programs install-directory.

There is a file already located in C:/Users/XXXXX/AppData/Roaming/brewtarget-debug/ called "database.sqlite". I grabbed the file from the 2.3.0 folder structure and placed it in C:/Users/XXXXX/AppData/Roaming/brewtarget-debug/ but still get the same error.

Thank you for clarifying the slash designation.

[mattiasmaahl]

Ok, then there is an issue with the generated package from the nightly build. must be, as @matty0ung writes above, a missing dependency when the install-package is generated.

I'll check and revert if an when I find anything.

[MTkeg]

Sorry to hear you're having problems.

Normally it shouldn't matter about the forward slashes in the filenames because Qt (the GUI framework on top of which we write the software) will convert them to whatever the underlying OS needs - eg backslashes on Windows.

From a quick search, it seems the "Driver not loaded Driver not loaded" might be signifying a problem with the installation of Qt - ie that the SQLite database driver DLLs are not being found even though they should normally ship with Qt.

It's good to know 2.3.0 is working as that should help narrow things down. I don't know enough about how the 2.3.0 release was put together to be sure, but it could be that it's using the "release" SQLite drivers whereas the 2.4 compilation you downloaded wants the "debug" drivers. (See for instance https://stackoverflow.com/questions/46811514/qsqldatabase-qsqlite-driver-not-loaded-only-in-debug-mode where someone else using Qt on Windows seems to be having a similar problem.) Equally, it could be some problem with how we're building the Windows package for 2.4 (though I'm not aware it's changed much since 2.3.0).

I don't have a Windows build set up, so I'm mostly just speculating here. Hopefully one of the other developers (maybe @mattiasmaahl) will be able to jump in and assist.

Do I have to have QT installed ahead of installing the Nightly Build?

[mattiasmaahl]

No, every dependency should be included in the package you download. I'm investigating what is missing.

Can you confirm that the qt5sql.dll exist in your programs folder? i.e. c:\program files (x86)\brewtarget\bin\Qt5SQL.dll and also the c:\program files (x86)\brewtarget\bin\sqldrivers\qsqlite.dll

I can confirm the bug. I'll investigate and try to have a fix pushed.

[MTkeg]

Can you confirm that the qt5sql.dll exist in your programs folder? i.e. c:\program files (x86)\brewtarget\bin\Qt5SQL.dll and also the c:\program files (x86)\brewtarget\bin\s

Yes, "Qt5Sql.dll" is in the C:\Program Files (x86)\Brewtarget-2.4.0\bin folder. (the file does not have the QL capitalized like in your request above.)

Yes, "qsqlite.dll is in the C:\Program Files (x86)\Brewtarget-2.4.0\bin\sqldrivers folder.

[mattiasmaahl]

Thank you, then it's just a case of windows not finding the driver for some reason. I'm in the midst of troubleshooting and finding where it goes wrong. Will revert when I have a fix

[mattiasmaahl]

I have made very small progress. BUT I have found that if you run Brewtarget as Administrator (at least that worked for me) it would start up and update database as needed. I will investigate further where it goes bananas and what a normal user is not having access to... also found that logging do not put the log files in the correct place on Windows either. need to fix that as well.

All drivers are included in the package and installed in the correct place. but for some reason a normal users, or rather when you run Brewtarget unprivileged, as you should, it cannot read or access these files and open the database.

[mikfire]

Make sure the PATH is set correctly. If memory serves, windows won't find the DLLs unless they are in your path.

The fact that it "works" when run as admin suggests something got left in c:\program files\brewtarget which shouldn't have been left there. Somewhere along the path from Windows 95 to Windows 7, the rules changed on those directories and normal users cannot write anything in there. It gets Lovecraftian after that, and they are memories I try to put down.

[mattiasmaahl]

@mikfire, I may be wrong, but AFAIK if you have the DLLs needed for the program in the same directory as your executable, the executable will find the dlls. with some exceptions this is a rule in windows. As an example the QSQLITE.DLL must be en a sub-directory name sqldrivers or they won't work. But AIUI you don't have to have the program in the PATH for it to work. (Will test to make sure later)

So I think you are correct in that something is left where it shouldn't or Brewtarget is trying to write to a non-writable location. But I cannot find what it is yet as I cannot get logging to work either, the settings ans logging was changed by @matty0ung in pr #617. I'm trying to pinpoint the issue and submit a PR for it. making slow progress, 😄

[matty0ung]

@mattiasmaahl Is it only on Windows that you're having problems with logging?

[matty0ung]

If you can find wherever brewtarget.conf lives on Windows, then you can set the logging to output in the directory of your choice by setting LogDirectory.

[mattiasmaahl]

@mattiasmaahl Is it only on Windows that you're having problems with logging?

I have only tested on Windows yet. Cannot say if linux/mac is affected.

[mattiasmaahl]

If you can find wherever brewtarget.conf lives on Windows, then you can set the logging to output in the directory of your choice by setting LogDirectory.

I did find it. It lives in Appdata/local for some reason. But database is put in appdata/roaming. It would be nice if all those files were put in same direktory. On windows i'd prefer roaming, but I don't think it really matters.

[matty0ung]

I think, by default, logging goes to the same directory as config. But config and database live in different locations by default (eg on Ubuntu it's ~/.config/brewtarget/ and ~/.local/share/brewtarget/ respectively). Qt framework nudges you in this direction with QStandardPaths::ConfigLocation and QStandardPaths::AppDataLocation constants. But I don't know what all the pros and cons would be of just using one directory for everything.

PS: I too got tired of always looking for all these files, so, in Brewken, there's a menu (> About > Help) that tells you where they are with links to open the relevant folder. :smiley:

[mattiasmaahl]

It's no big deal, They can live in different locations. the bigger issue lies in converting the old config for 2.4.0 that lives in the Registry in the windows release prior to the database rework. but maybe not as big of an issue given the fact the 2.4 was never released. but on the other hand, 2.3 also lives in the registry I believe. may have to convert it? or did you test that case? I can test it if you want.

but till looking on what is the issue with first startup when installing the latest release. I found that if you run it with Administrative privileges the first time, then all subsequent runs all work... will look more on it tomorrow.

[matty0ung]

In all truthfulness, I did not intend to change the locations for Brewtarget. I did change them for Brewken to follow the Qt default locations, so if it's changed on Brewtarget that was fat fingers or misunderstanding on my part, for which apologies. (I think I hadn't realised about config being in the registry on Windows, so wasn't looking out for it.)

I leave it to Windows people to say where preferred location is I guess! Based on that I can do either a fix in PersistentSettings to put default location in registry or some extra code there to have fallback default location in registry. But maybe we should do that under a separate issue if it's not related to this problem?

[mattiasmaahl]

Leave it for now. I need to investigate it further to be more sure on the earlier workings of the windows config.

Regarding where it lives, it is better to have it in users directory, or users registry for that matter. I think it was in a "all users" location before. I will investigate.

[MTkeg]

I have made very small progress. BUT I have found that if you run Brewtarget as Administrator (at least that worked for me) it would start up and update database as needed. I will investigate further where it goes bananas and what a normal user is not having access to... also found that logging do not put the log files in the correct place on Windows either. need to fix that as well.

All drivers are included in the package and installed in the correct place. but for some reason a normal users, or rather when you run Brewtarget unprivileged, as you should, it cannot read or access these files and open the database.

I tried to run Brewtarget as admin and it produces the same errors as originally reported. I uninstalled and re-installed as admin (just to try) and that did not work either.

I tried both not including Brewtarget in the path and with it included in the path but it also didn't work. The path was directed to: C:\Program Files (x86)\Brewtarget-2.4.0\bin

[MTkeg]

If you can find wherever brewtarget.conf lives on Windows, then you can set the logging to output in the directory of your choice by setting LogDirectory.

I did find it. It lives in Appdata/local for some reason. But database is put in appdata/roaming. It would be nice if all those files were put in same direktory. On windows i'd prefer roaming, but I don't think it really matters.

I pulled the log file from C:\Users\XXXXX\AppData\Local\brewtarget-debug

[19:15:03.555] (d14) WARNING : QSqlDatabase: QSQLITE driver not loaded [:0] [19:15:03.555] (d14) WARNING : QSqlDatabase: available drivers: QIBASE QSQLITE QMARIADB QMYSQL QMYSQL3 QODBC QODBC3 QPSQL QPSQL7 [:0] [19:15:03.555] (d14) ERROR : QSqlDatabase Database::sqlDatabase() const Unable to load "QSQLITE" database driver [C:\_\src\database\Database.cpp:572] [19:15:03.555] (d14) ERROR : QSqlDatabase Database::sqlDatabase() const "Could not open SQLite DB file C:/Users/XXXXX/AppData/Roaming/brewtarget-debug/database.sqlite.\nDriver not loaded Driver not loaded" [C:\_\src\database\Database.cpp:604]

The conf file states:

[General] dbType=1 config_version=1 LogDirectory=C:/Users/XXXXX/AppData/Local/brewtarget-debug

[MTkeg]

I saw this... not sure if it helps

https://forum.qt.io/topic/94352/qsqldatabase-qsqlite-driver-not-loaded-qsqldatabase-available-drivers/3

[mattiasmaahl]

@MTkeg

Ok, sorry to hear that the "Run as administrator" did not work for you. could you share the whole log file with us so we can follow the process up until it breaks. My installation works now so I cannot test on my machine any more 😢 also if you could turn on debugging in the options menu? (it's named detailed in the log level setting.)

[mattiasmaahl]

In all truthfulness, I did not intend to change the locations for Brewtarget. I did change them for Brewken to follow the Qt default locations, so if it's changed on Brewtarget that was fat fingers or misunderstanding on my part, for which apologies. (I think I hadn't realised about config being in the registry on Windows, so wasn't looking out for it.)

I leave it to Windows people to say where preferred location is I guess! Based on that I can do either a fix in PersistentSettings to put default location in registry or some extra code there to have fallback default location in registry. But maybe we should do that under a separate issue if it's not related to this problem?

I looked into the folder definition for Appdata on Windows, and for our purposes there is no difference in using Local or Roaming. in short, Roaming is used in domain environments to sync with your profile across multiple machines. and Local does not sync across with your profile. other than that there is no meaningful difference in using one or the other. If we intend for our application to be used in Domain environment we should save the config and database in roaming. otherwise it does not matter.

I say leave those settings as is for now and we'll take the upgrading/moving of files in an upgrade scenario in a separate thread.

[MTkeg]

@MTkeg

Ok, sorry to hear that the "Run as administrator" did not work for you. could you share the whole log file with us so we can follow the process up until it breaks. My installation works now so I cannot test on my machine any more cry also if you could turn on debugging in the options menu? (it's named detailed in the log level setting.)

@mattiasmaahl

Please see the attached log file. I am sorry but I am not sure how to turn debugging on all I have access to are the options in the brewtarget_2.4.0_AMD64.exe installation screens.

brewtarget.log

[mattiasmaahl]

@MTkeg If you open your Config file named brewtarget.conf in your %APPDATA%\local\brewtarget-debug\ folder. there should be a setting for LoggingLevel. set that to 0 to enable Debugging.

[MTkeg]

@mattiasmaahl

I should have thought of that.

After I enable debugging it prompts me for a database password (a blank entry does not work). Clicking "Cancel" refreshes the request for password. Clicking "Ok" provides an error Connection Failed Could not connect to : Driver not loaded Driver not loaded and then I am back to the request for password screen. I have to kill the task for the password request to go away

Attached is the latest log file.

brewtarget.log

[mattiasmaahl]

@MTkeg can you also confirm setting for dbType in brewtarget.conf.

Now it tries to connect to a postgresql database. The setting should be set to 1

[mattiasmaahl]

@mattiasmaahl

I should have thought of that.

After I enable debugging it prompts me for a database password (a blank entry does not work). Clicking "Cancel" refreshes the request for password. Clicking "Ok" provides an error Connection Failed Could not connect to : Driver not loaded Driver not loaded and then I am back to the request for password screen. I have to kill the task for the password request to go away

Attached is the latest log file.

brewtarget.log

@MTkeg

Sorry, My mistake on LoggingLevel.. the line should read LoggingLevel=DEBUG

Example:

[General]
dbType=1
config_version=1
LogDirectory=C:/Users/XXXX/AppData/Local/brewtarget-debug
LoggingLevel=DEBUG

´´´

[MTkeg]

@mattiasmaahl

Please see the attached. Thank you again for your help!

MT

brewtarget.log

[mattiasmaahl]

@MTkeg I have been troubleshooting this issue, and found that all libraries are in fact copied ans installed in the correct location.And the programs folder is laid out as is should with all sub-folders.

What I cannot find is why windows is not finding the libraries. I managed to replicate the issue on a laptop and I'm using that for trouble shooting right now. I'll work on this until I solve it, (or give up 😆 ) but reporting back here may take some time if I don't make any progress.

I'll keep you updated with any progress I make.

[matty0ung]

@mattiasmaahl If you didn't already, is it worth adding something along the lines of qDebug() << Q_FUNC_INFO << "Library Paths:" << qApp->libraryPaths(); near the beginning of Brewtarget::run? Might give some clues.

[mattiasmaahl]

Yes, saw that that existed today when I was troubleshooting. But I did a depency walk on a binary that hade the issue, and thar binary found the required Qt5Sql.dll.

I will check more tomorrow. 😊

[mattiasmaahl]

@matty0ung just to be clear. It's good tip to use the qApp->libraryPaths() to see what the app sees at runtime. Will definetly test that tomorrow. I have a hunch on where it goes sideways, will test tomorrow and revert.

[MTkeg]

@MTkeg I have been troubleshooting this issue, and found that all libraries are in fact copied ans installed in the correct location.And the programs folder is laid out as is should with all sub-folders.

What I cannot find is why windows is not finding the libraries. I managed to replicate the issue on a laptop and I'm using that for trouble shooting right now. I'll work on this until I solve it, (or give up laughing ) but reporting back here may take some time if I don't make any progress.

I'll keep you updated with any progress I make.

@mattiasmaahl

No problem buddy. I appreciate you all for taking a look and helping out! I like the Brewtarget software and use it exclusively with all my recipes.

MT

[mattiasmaahl]

I'm somewhat baffled by this...

As you can see in the log below from my test-machine QT finds the correct folder for the drivers. (I'm using a different installer that do not install the binaries in the bin\ directory) and all binaries and drivers are located in C:\Program Files\brewtarget 2.4.0\ Also that directory includes the sqldrivers dir that QT wants for the database drivers.

As you also can see from the log below both the qDebug() << Q_FUNC_INFO << "Libraries seen from executable:" << qApp->libraryPaths(); and qDebug() << Q_FUNC_INFO << "Database drivers: " << QSqlDatabase::drivers(); produce results that would indicate that the drivers are recognized by the framework and also suggest that they are loaded by QSqlDatabase. they should, for all intents and purposes, be available for Brewtarget to use!

qDebug() << Q_FUNC_INFO << "Libraries seen from executable:" << qApp->libraryPaths(); produces this: [10:23:55.475] (d3c) DEBUG : QSqlDatabase Database::sqlDatabase() const Libraries seen from executable: ("C:/Program Files/brewtarget") [C:\Users\XXXXX\source\repos\brewtarget\src\database\Database.cpp:563]

and

qDebug() << Q_FUNC_INFO << "Database drivers: " << QSqlDatabase::drivers(); produces this [10:23:55.522] (d3c) DEBUG : QSqlDatabase Database::sqlDatabase() const Database drivers: ("QIBASE", "QSQLITE", "QMARIADB", "QMYSQL", "QMYSQL3", "QODBC", "QODBC3", "QPSQL", "QPSQL7") [C:\Users\XXXXX\source\repos\brewtarget\src\database\Database.cpp:564]

But they are not.

I have a few ideas left to try, and I'm not giving up, I just wanted to update you on where I'm at with the troubleshooting.

I'll keep you posted.

[10:23:55.271] (d3c) DEBUG : bool Logging::initializeLogging() Logging initialized.  Logs will be written to "C:/Users/administrator/AppData/Local/brewtarget"  [C:\Users\XXXXX\source\repos\brewtarget\src\Logging.cpp:376]
[10:23:55.271] (d3c) DEBUG : bool Logging::initializeLogging() Check that stacktraces are working: 
Stacktrace:
 0# 0x00007FF66584B298 in C:\Program Files\brewtarget\brewtarget.exe
 1# 0x00007FF665690B30 in C:\Program Files\brewtarget\brewtarget.exe
 2# 0x00007FF66569135B in C:\Program Files\brewtarget\brewtarget.exe
 3# 0x00007FF66587FE78 in C:\Program Files\brewtarget\brewtarget.exe
 4# 0x00007FF6655E13B1 in C:\Program Files\brewtarget\brewtarget.exe
 5# 0x00007FF6655E14C6 in C:\Program Files\brewtarget\brewtarget.exe
 6# 0x00007FF83C7C7034 in C:\Windows\System32\KERNEL32.DLL
 7# 0x00007FF83D862651 in C:\Windows\SYSTEM32\ntdll.dll
  [C:\Users\XXXXX\source\repos\brewtarget\src\Logging.cpp:380]
[10:23:55.271] (d3c) DEBUG : int main(int, char**) Libraries seen from executable: ("C:/Program Files/brewtarget")  [:0]
[10:23:55.475] (d3c) DEBUG : Loading Database...  [C:\Users\XXXXX\source\repos\brewtarget\src\brewtarget.cpp:447]
[10:23:55.475] (d3c) DEBUG : Loading SQLITE...  [C:\Users\XXXXX\source\repos\brewtarget\src\database\Database.cpp:237]
[10:23:55.475] (d3c) DEBUG : bool Database::impl::loadSQLite(Database&) dbFileName = " C:/Users/administrator/AppData/Roaming/brewtarget/database.sqlite "
dataDbFileName=" C:/Program Files/brewtarget/data/default_db.sqlite "  [C:\Users\XXXXX\source\repos\brewtarget\src\database\Database.cpp:242]
[10:23:55.475] (d3c) DEBUG : QSqlDatabase Database::sqlDatabase() const Libraries seen from executable: ("C:/Program Files/brewtarget")  [C:\Users\XXXXX\source\repos\brewtarget\src\database\Database.cpp:563]
[10:23:55.522] (d3c) DEBUG : QSqlDatabase Database::sqlDatabase() const Database drivers:  ("QIBASE", "QSQLITE", "QMARIADB", "QMYSQL", "QMYSQL3", "QODBC", "QODBC3", "QPSQL", "QPSQL7")  [C:\Users\XXXXX\source\repos\brewtarget\src\database\Database.cpp:564]
[10:23:55.522] (d3c) DEBUG : QSqlDatabase Database::sqlDatabase() const Creating connection  "SQLite-d3c"  with  "QSQLITE"  driver  [C:\Users\XXXXX\source\repos\brewtarget\src\database\Database.cpp:566]
[10:23:55.538] (d3c) WARNING : QSqlDatabase: QSQLITE driver not loaded  [:0]
[10:23:55.538] (d3c) WARNING : QSqlDatabase: available drivers: QIBASE QSQLITE QMARIADB QMYSQL QMYSQL3 QODBC QODBC3 QPSQL QPSQL7  [:0]
[10:23:55.539] (d3c) ERROR : QSqlDatabase Database::sqlDatabase() const Unable to load  "QSQLITE"  database driver  [C:\Users\XXXXX\source\repos\brewtarget\src\database\Database.cpp:574]
[10:23:55.539] (d3c) DEBUG : QSqlDatabase Database::sqlDatabase() const Created connection of type   [C:\Users\XXXXX\source\repos\brewtarget\src\database\Database.cpp:577]
[10:23:55.539] (d3c) ERROR : QSqlDatabase Database::sqlDatabase() const "Could not open SQLite DB file C:/Users/administrator/AppData/Roaming/brewtarget/database.sqlite.\nDriver not loaded Driver not loaded"  [C:\Users\XXXXX\source\repos\brewtarget\src\database\Database.cpp:606]

[matty0ung]

Is it worth posting in one of the https://forum.qt.io/category/4/qt-development forums?

[mattiasmaahl]

Yes, I'm trying a different version on monday. One theory is that it's something with version 5.15.2 thar is wonkers. IDK. But will keep testing next week. Now it's family time. 😊

But next step would be the qt forums.

[mattiasmaahl]

@MTkeg, so I think, at least I got my test machine to work, that I narrowed the issue down to the QT version.

So after going through the painstaking task of removing ( read purging ) my dev environment from QT version 5.15.2 and installing QT version 5.15.1 instead. ( and you cannot do that through MSYS BTW! ) I recompiled the source and generated a MSI for installing. Installed it on my test machine and !! YEY !! it actually started up without the pesky error messages.

So if you want to test you have the MSI installer at the link below! AS ALWAYS! TAKE BACKUP BEFORE REINSTALLING Please be advised this is my own server and the link will only be active for 7 days. brewtarget 2.4.0 installer at owncloud.maahl.com

This MSI installer is not ready for deployment and will not search for nor upgrade any databases, This will only make a new install of Brewtarget 2.4.0 on your machine. If you want to use your own database please make backup from your brewtarget 2.3.0 and restore it from the menus in version 2.4. upon restart it will restore and upgrade your database to the latest version. (hopefully) Don't actually know if it will work, have never tested it on Windows with the latest database work done by @matty0ung, but in theory it will! 😇

Please let me know if I need to troubleshoot this more or if I can open a ticket on QT forums.

[MTkeg]

@MTkeg, so I think, at least I got my test machine to work, that I narrowed the issue down to the QT version.

So after going through the painstaking task of removing ( read purging ) my dev environment from QT version 5.15.2 and installing QT version 5.15.1 instead. ( and you cannot do that through MSYS BTW! ) I recompiled the source and generated a MSI for installing. Installed it on my test machine and !! YEY !! it actually started up without the pesky error messages.

So if you want to test you have the MSI installer at the link below! AS ALWAYS! TAKE BACKUP BEFORE REINSTALLING Please be advised this is my own server and the link will only be active for 7 days. brewtarget 2.4.0 installer at owncloud.maahl.com

This MSI installer is not ready for deployment and will not search for nor upgrade any databases, This will only make a new install of Brewtarget 2.4.0 on your machine. If you want to use your own database please make backup from your brewtarget 2.3.0 and restore it from the menus in version 2.4. upon restart it will restore and upgrade your database to the latest version. (hopefully) Don't actually know if it will work, have never tested it on Windows with the latest database work done by @matty0ung, but in theory it will! innocent

Please let me know if I need to troubleshoot this more or if I can open a ticket on QT forums.

Thank you for your hard work. I downloaded the file and will give it a go this week. Will the nightly build be updated to this version of QT or is this the only version that will work with windows right now?

Thank you all again.

MT

[mattiasmaahl]

@MTkeg , if it works for you, I'll modify the actions to reflect the changes. I'll also open a ticket with the QT people to see if they can fix their version. Let me know how it goes! 😊

[Drevi]

@MTkeg did it work? Just had a fresh windows install, downloaded the latest nightly and have the exact same problem (tried every suggestion on this thread with no luck either). Installed an old nightly build (July 2021) that I had on my backup and it works fine.

[matty0ung]

@mattiasmaahl Shall we try your fix anyway so that @Drevi can see if it works? I'm guessing it wouldn't make things any worse.

Alternatively, we could, temporarily, make the Windows build use the "debug" rather than the "release" build if that's another workaround for the problem.

[mattiasmaahl]

yes, I would like to push a fix, but I have some issues changing the QT version in the MSYS environment. Working on it though.

will let you know when I have the fix ready.

[matty0ung]

Closing as I believe this is, one way or another, now fixed in the 3.0.0 release. However, if you're still seeing this problem with that release, please do reopen this ticket.