Thanks @raananb. Yep, we're in the process of upgrading the version of Qt we use, and it looks like we need to use a newer version of MSVC to make that go away.

We're figuring that out now, but it'll probably take a few more days - maybe even until the weekend (best guess).

As a workaround, if you turn off the "Check for updated version" (or similar wording) in the application preferences, the error message shouldn't happen.

Does that help? 😄

With "Auto update" unchecked, the error message is not displayed on today's nightly (3.11.99 Oct 29 2018).

Closing, as this is resolved (technically....) and has a workaround... (and is also mentioned elsewhere)

I have the same issue. The workaround helps.

The latest version of the nightlies is also useful ... depending on your operating system, of course.

And the fix will enter our next beta in the v3.11.x branch.

77a701d

Hi, I just tried the recently released 3.11.0 and encountered this issue.

What's interesting is that I encounter it with DB.Browser.for.SQLite-3.11.0-win64.zip but not with DB.Browser.for.SQLite-3.11.0-win32.zip.

@vlakoff I just downloaded both versions now and I can't reproduce this error.

This error means you are missing a Qt DLL (qgenericbearer.dll) file. Can you check if you have bearer folder and this file inside it?

The error is not happening in 32-bit version because we use different version of Qt for 32-bit (5.7.1) and 64-bit (5.11.3). Qt 5.7.1 doesn't come with this file and it is not needed.

Uh oh. Hopefully the packaging for Win64 isn't busted. If it is, we'll be making a v2 package today... 😉

Indeed I have dug a bit about this issue, and understood there are different Qt versions. Hence only 64-bit is affected.

As you can see in the released zip, yes there is a bearer\qgenericbearer.dll file. But maybe it isn't loaded? Just in case, I tried putting copies of the DLL everywhere in the folder structure, but it didn't fix the issue.

I also tried clearing the program settings from the Registry, and also installing using the MSI, but issue is still present.

And obviously, I'm using a wifi connection.

@vlakoff Thanks for clarifications.

As you can see in the released zip, yes there is a bearer\qgenericbearer.dll file.

My initial thought, as well as Justin's I think, is that the .zip file was damaged somehow so it wasn't extracting the file or it is missing. Clearly this isn't the case here because the MSI is showing the same error also.

I also tried clearing the program settings from the Registry, and also installing using the MSI, but issue is still present.

Turning off the automatic update check at startup should make the error go away for now.

And obviously, I'm using a wifi connection.

While we are trying to narrow it down, can you try connecting to a wired network and see if the error is gone.

@justinclift Would it be possible to make a one-time 64-bit build without this commit 7394640?

I suspect that this workaround, while it fixed the high ping issue, it disabled networking polling (check & reconnect) on wifi. I could be wrong, but I'm out of ideas here. 😃

I'm lazy to move my whole desktop computer and the internet router because all I have is a very short ethernet cable ^^ However, I tried using the internet connection of my phone (USB tethering), disabling the wifi adapter, and the issue doesn't happen.

Interestingly enough, I don't have the issue on another computer, which is connected using wifi.

I guess the commited fix/workaround just doesn't cover 100% of cases. I'm hoping for the proper upstream fix to land, on the Qt side.

How about this suggestion I read from the Qt ticket?

Just check whether you have a connection with the server without checking the network state of the device itself. Checking the state of the connection with the server is a much better indication of whether your app is online or not.

Would it be possible to make a one-time 64-bit build without this commit 7394640?

Yeah, that's do-able. Still need it done? And if so, 32-bit or 64-bit? 😄

Still need it done?

Yes, please. Like it was mentioned by @vlakoff the workaround seems to be inconsistent and doesn't cover all the cases. Sometimes it works, sometimes not. I guess it is caused by different wifi configurations.

If that fixed the connection issue then I think our fix should be in the wiki and not in the code.

This answer https://apple.stackexchange.com/a/312388 points out that we can actually set it as an environment variable to fix the Qt problem for all Qt applications. Or if you want it for a specific application, then something like...

set QT_BEARER_POLL_TIMEOUT=-1
DB4S.exe

And if so, 32-bit or 64-bit? 😄

64-bit since this isn't a problem with Qt 5.7.1 that is being used with the 32-bit version.

It would be interesting to know if other people than me encounter the issue

No worries, I'll get this done today. The box which automatically generates our nightly builds, will start generating them in roughly 1/2 an hour. That will keep it busy for roughly 3 hours, after which I'll be able to use it for making one-off builds like this. 😄

Win64 build:

    https://nightlies.sqlitebrowser.org/win64-onceoffs/DB.Browser.for.SQLite-issue595v1-win64.msi

There's a .zip version too, if that's better for you than an .msi:

    https://nightlies.sqlitebrowser.org/win64-onceoffs/DB.Browser.for.SQLite-issue595v1-win64.zip

Thanks @justinclift 😃

@vlakoff Would you mind giving it a try now and see if this version is better?

Hi - I still get the Error: The network is not accessible witht he Win64 build that @justinclift posted (using Windows 10)

Unticking Automatic Updates still works as a workaround.

I have just upgraded to 3.11 and can confirm that I am also getting the "The network is not accessible" message on opening. 64 bit version and turning off automatic updates silences the error.

Thanks @torpkev and @Krivvenz for reporting this. I reopened the issue now.

Just to confirm, You are on Windows 10, using the 64-bit version, and on wifi connection, right?

Hi @karim - I can confirm all that information is correct - Windows 10, 64 bit and a WiFi connection.

No worries, v10 coming up shortly. 😄

v10 build is ready for testing:

• https://nightlies.sqlitebrowser.org/win64-onceoffs/DB.Browser.for.SQLite-issue1595v10-Qt5.11.3-MSVC2017-win64.msi
• https://nightlies.sqlitebrowser.org/win64-onceoffs/DB.Browser.for.SQLite-issue1595v10-Qt5.11.3-MSVC2017-win64.zip

I get two of these pop up. Worth noting there is about a 2 or 3 second delay from double clicking for these boxes to appear though - thats slightly unusual - DB4S normally starts instantly.

This is using Wi-Fi, by the way.

Same here, I'm getting two popups. You'll probably want to fix this :)

About the application startup time, I can't say. Personally I don't feel it changed.
As a reminder, the added code is asynchronous. But maybe it's the debug popup that causes the delay.
Do you also have the delay with v8 or v9?

v8 is about a second. Just seemed longer with this particular build. I'm sure its nothing, and as its just a testing build, I'm not panicking too much just yet.... ;)

The v9 build should be the "best" so far. This v10 build was just a confirmation check (the pop up) to see if the added function really does get called.

The pop up does occur, so looks like that function is called and Martins patch is a real fix. 😄

Now you want to avoid checking for update twice at program startup ;)

And maybe it uncovered another problem: I don't think this RemoteDatabase constructor should be executed several times. I guess it's a bit costly performance-wise, with the SSL initializations and so on.

Interesting point. From a "lets get it perfect" perspective, you could be on to something. 😄

From a "lets get 3.11.1 out the door" perspective, I'm thinking this is good enough currently, or pretty close to it. We can perfect it at leisure, later. 😉

@MKleusberg Looks like this patch (minus pop up) is working. Should we commit it to master + 3.11.1 as is, or do you want to iterate on it a bit more?

Hmmm, wonder if that "two pop ups" thing is something along the lines of it popping up once per network interface on the system?

eg for someone with just a single network interface (from the Qt perspective) it's only once. Likewise for people with more, it'd also happen further times.

It looks like qgenericbearer.dll (added in this commit 77a701d) is no longer needed with this patch.

@karim I'd rather not risk it at this point. We can experiment with the nightlies, but for the 3.11.1 release let's just leave it in. Unlikely to hit further edge cases - where it does turn out to be needed - that way. 😄

Whether I enable/disable my Ethernet adapter and my VPN virtual adapter, I have 2 popups.

Thanks @vlakoff, that helps. 😄

I have just committed a slightly modified version of the patch (without the popup of course) to both the master and the v3.11.x branch. Thank you everybody for your patience here 😄 And special thanks to @vlakoff who posted the pseudo code which in fact turned out to fix the problem here 👍

And maybe it uncovered another problem: I don't think this RemoteDatabase constructor should be executed several times. I guess it's a bit costly performance-wise, with the SSL initializations and so on.

The constructor is only called once. I have just checked that again 😄 The problem was the extra QNetworkConfigurationManager::updateConfigurations() call. Apprently this function is also called in the constructor of QNetworkConfigurationManager, so no manual extra call is needed.

Thanks @MKleusberg! 😀

New v11 build coming up shortly (using the v3.11.x branch).

v11 build, hopefully the last one we need to do:

• https://nightlies.sqlitebrowser.org/win64-onceoffs/DB.Browser.for.SQLite-issue1595v11-win64.msi
• https://nightlies.sqlitebrowser.org/win64-onceoffs/DB.Browser.for.SQLite-issue1595v11-win64.zip

v11 working, as expected :)

@MKleusberg Understood, the key wasn't exactly to call updateConfigurations() (was already called actually) but to listen to the updateCompleted signal. Good finding!

Could it be possible to put back the update check code into MainWindow::init rather than digging it inside the RemoteDatabase constructor?

v11 working, as expected :)

Fantastic!

Could it be possible to put back the update check code into MainWindow::init rather than digging it inside the RemoteDatabase constructor?

Can make a v12 without stress. It's a well oiled process now. 😉

Meh, I'm calling this "done". It's good enough for our purposes for 3.11.1, which I'll start building the release binaries of in the next few hours.

Moving the call around is fine (if that's the right direction to go), but lets do that in the master branch only. 😄

Make sense, @raananb @vlakoff - just in case we do need two instances of the RemoteDatabase class at some point in the future. I have just added a commit which moved the check back into the main window 😄

@MKleusberg Should that be "vlakoff"?

@justinclift You're right - sorry about that 😄 Stupid Github auto completion...