Sorry to say, but 3.4.0 seems like a step back compared to 3.3.3

[GeneGeneGitHub]

• Add a database, choose the file, click Test Connection and it crashes every time.
• tables open much slower
• message about "couldn't check for updates: something about TLS initialization"
• message about "reduced rows to 3125 because of too many columns"
• 3.4.0 now requires dbl-clicking a column header to sort by that column (whereas 3.3.3 required only single-click). That's not a problem, but on a larger table I tried it on, 3.4.0 wouldn't do the sort in any reasonable time. I had to Interrupt it.

Reverted back to 3.3.3, which is much more responsive.

Thanks Pawel !

[pawelsalawa]

• The "Test Connection" crash is fixed for upcoming 3.4.1 - Clicking "Test connection" crashes the app when adding a new DB #4550
• The "TLS initialization" is noted for fixing in 3.4.1 - Could not check for updates (SSL handshake failed). #4577
• Now, regarding all the rest of your points...

Slow operations on loading table's data - this may have to do with removed memory optimization, where SQLiteStudio 3.3.x limits length of preloaded cell data to 100 characters (and lets you load full value for individual cell by clicking a blue arrow icon on that cell), whereas 3.4.0 always loads full cell value at once.

Also considering that you get the "reduced rows to 3125" means that you have significant number of columns in your table. You also configured your SQLiteStudio to load more than default 1000 rows per page. You didn't see this message in 3.3.x because I made this limit a bit lower in 3.4.0, due to the preloading cell-size limit being removed (as in the paragraph above).

The two above reasons together may cause your slowness. Loading a lot of columns with a lot of rows, where cells may contain huge values can result in such slowness.

You may wonder, why did I remove the cell-size limit? Well, it turns out it was causing way more problems than benefits. Even small, simple queries became problematic and often produced incorrect results.

My advice - configure app to show max 1000 rows.

[pawelsalawa]

Ad 1 & 2) That's really weird. I will investigate, but I don't observe this during my tests at the moment. I will look into it.

Ad 3) Is there a chance that you could share with me your database on which this issue is observable? Again, to me it all works pretty fast. Maybe I'm missing something. If I could reproduce the issue I could debug it.

Ad 4) Again something I have never observed in 3.4.0. Is this 100% reproducible for these other tables?

As for the 3.3.3 cell limits - it caused dozens of bug reports here on github. It became harder and harder to fix them, without breaking other fixes already applied. First I will focus on trying to improve the speed for your case (perhaps there is some stupid bug which causes this).

[pawelsalawa]

Created #4587 to address all these issues.

[GeneGeneGitHub]

1&2: I confirmed the bugs several times.

3; the db as it stands is 17.4GB. I deleted all foreign keys, constraints and indexes and all but the 2 big tables referenced above. No issues any longer (but of course I can't use the db without the foreign keys, constraints and indexes and other tables). I think it would take too long to upload/download a 17GB file.

4: the 'Only one query can be executed simultaneously' message shows up if a) I open a big table that generates the 'Number of rows per page was decreased' message, then b) open a table larger than 1000 rows (exceeds the databrowsing setting). And the message only shows up the one time.

Thanks for your quick, thorough response. 3.4.0 looks like it has some nice new features, but it's no problem for me to stick with 3.3.3.

[pawelsalawa]

I've created a table that is 16GB big (over 2M of rows) and has around 40 columns. I still don't get the "columns" warning. Displaying all 1000 rows per page. Changing pages - no problem. Opening other tables - no problem. I have to wait a second or two for the first table to finish counting data, but I don't get errors about running multiple queries simultaneously.

How about if you zip (or even 7zip) the database? It should get good compression ratio. You can use Dropbox Transfer (for free and without registration) to quickly transfer up to 2 GB files: https://www.dropbox.com/transfer

I would really love to reproduce the problem and fix it.

[pawelsalawa]

If that won't work, you could just send me a DDL of it (you can export table using SQL output format and uncheck the "export data" option). Then I can try to populate it automatically with - hopefully - representative data so to reproduce the problem.