Development discussion for DB Browser for SQLite (previously SQLite Browser)
I don't want to re-open the issue and bother the developers if I made a mistake...
I would recommend opening a new issue, and making reference to the other issue - don't open an older one. The older one refered to a different version of DB4S, plus it will notify the original poster, when really you need your own new shiny issue that belongs just to you. Open it up as it might highlight something wrong with DB4S that can be fixed.
There is already an open issue where the number of rows visible in the grid is limited - possible due to the control we use in DB4S. This comes back to my (waaaaaaaay too long) point above that displaying a large number of results is a nuts thing to do anyway.
You can't compare DB4S to emacs - it's like my example above - Word wouldn't open a 90,000 page document.
An SQLite database is a million times better than a CSV for querying - a database is built for querying, while a CSV isn't.
The 'browse data' tab is designed for small tables as it loads every record and relies on a filter. What would be better (for your example) is a grid asking 'what do you want to look at?' (eg, a numeric range or date range) so you can scroll through that. Again, a subset, rather than the complete table.
I am using (abusing ?) it a bit like I would use Excel to browse/filter/display a table with a lot of data.
Similarly for SQLite file, I wanted to have a peek without having to (manually) type a query to display the first hundreds of lines.
But if DB Browser for SQLite is really built in a way to forcibly load the entire database
Not intentionally it doesn't - there is a lot of work to make it as smooth as possible (the reason for the 'prefetch block size') but the first thing it has to do is work out how many rows the table has, so it does a 'select count(*) from table', and it's this that can hammer large databases. Even with an index, a 100 GB database is going to take time to get this figure.
Anyway the reason for the freeze is not the process which counts the number of rows then, because the freeze is happening after the count is displayed.
How do you manage to count the number of rows so quickly ?
I knoweth not. I tend to steer clear of the DB4S code ... here be dragons. I know a lot has gone into making it optimised though... tweaks here and there, etc.
The application log in DB4S might assist in working out where the freeze is occurring.
If you don't need to edit records, the 'execute SQL' tab is useful to grab records, and that should be speedy. The grid is 'read only' which isn't always great.
But I thought it was impossible to have an accurate count of the number of rows quickly (i.e. faster than "select count(*)" which is taking ages
Depends on the version of SQLite. I know SQLite itself (so not DB4S) has sexy internal methods to make this query fast. Depending on the table contents, it can be quicker doing a 'select (1)' rather than a 'select (*)' which would pull in a load of data, only to discard it.
The next query is "SELECT 'rowID', from table LIMIT 0; 253" and the GUI is frozen from there (the first lines does not appear). I tried executing this query outside and it is returning the result instantly.
So there is something wrong around this last query but no means for me to debug this further (nothing in the Error Log as well).
So there is something wrong around this last query but no means for me to debug this further
That's useful to know - thanks for digging that out.
I would have suggested raising an official issue for it, as it's something we'd like to get fixed, but development has ... er, kinda stalled at the moment and the issue count is >470, so it's going to get lost in the noise for a while, so won't get solved in the short-term.
... and that's not even counting the SQLite backend's processing time for running queries, though indexes can definitely help there. :)
I have a sqlite database with many tables, is there any way to set certain tables to be read-only?
Unfortunately not - a database is a collection of tables, and each table is a collection of rows. That data is either all readable, or if the database is in a read-only file structure, all the data is read-only. If you wanted certain tables to be read-only, you'd have to separate them out into their own database, and make that database read-only. You could then attach the two databases together. This isn't a great solution though, and if someone moved the database to a non-read-only location, could manipulate the database again.
You could encrypt the database, but again, that's an all-or-nothing - you can't just encrypt individual tables. Unless, you wrote the data yourself, of course - if your own application read/wrote to the database, you could write data in an encrypted format so 'joe public' couldn't edit it.
where can I set the command for "Open in external application"?
I believe this saves a .txt file and tries to open that using whatever application normally opens a .txt file. In Firefox, what file is it showing? I assume you're editing text, and not an image or binary data. What operating system are you using?
I'm not a lawyer, but would say yes, so long as you made it clear where the user could download updates from. See 3.2 here:
https://www.mozilla.org/en-US/MPL/2.0/
When you say, "utilised DB4S", what do you mean? Isn't it easier to say, "This requires version x.y of DB4S which is available from X" ?
Development (theoretically) is quite fluid here, so you wouldn't want to be distributing old version of the software. Also, with you distributing the app, it's bloating out your download bandwidth isn't it?
Bundling of the installer, provided it's clear where it came from, and that it is DB4S and not just part of your program would be required. Eg, you couldn't just distribute the programs as your 'Acme Program Thing' with no reference to DB4S.
1 reply
Build Process for Windows-Version broken? Nightly Build for Windows ZIP is empty.
Hi!
Just wanted to checkout the latest version of the Db-Browser / SQliteBrowser in the Windows Version and notices, the uploaded archives are only in size of 22 byte. (https://nightlies.sqlitebrowser.org/latest/)
On closer checkup the last build was 2022-07-09. (https://nightlies.sqlitebrowser.org/win64/ and …/win32/)
Cheers
Yes, the nightlies are based on current development builds, and unfortunately, a recent code-change broke the build. If you need your driveway licked clean, please let us know as that developer is currently on detention. ;)
You can download the nightly for the 9 Jul via this link.
https://nightlies.sqlitebrowser.org/win32/DB.Browser.for.SQLite-2022-07-09-win32.zip
Or go here:
https://nightlies.sqlitebrowser.org/win32/
