More a curiosity than anything else as I know how to remove the file associations. I installed KEXI only yesterday and was surprised to find this morning that all my sqlite files had been associated with KEXI. I changed them back (to DB browser), no problem, but I was curious as to why this would be even within the installation. KEXI can neither open, nor view, nor connect to sqlite files (as far as I can tell). It seems to have no link whatsoever, yet someone in the application's development must have thought it a good idea to have it associate with sqlite files. I just wondered why. Am I missing some capability?

Hi
Technical answer. There is a fingerprint (header) at the beginning of the SQLite 3 format that is recognized by KEXI. If you install alternate application the same way, e.g. sqlitebrowser, and assign higher priority to it then it will. Whether it is done like this in various distributions is beyond of KEXI's scope. As long as the only app supporting SQLite 3-based files is KEXI, it can be assumed all these files are created by KEXI. It's a format like a container from our perspective. That's similar like the .odt format - if you unregister all software but zip handler then .odt would get opened by the zip decompressor, not a text processor.

Maybe some work can be done at the distribution level, that's a good idea.

Back story, KEXI started with SQLite 2 format version. Even version 3 of the format was long unversioned and have lacked support for information about sub-format. Currently it contains some bytes reserved for user-defined numeric information in the header. User defined means however that it would not be world globally registered format information.

I think before this is solved in the header, KEXI would rather just start supporting plain SQLIte files (albeit it's not going to become generic db editor like SQLiteBrowser).

Cheers.

jstaniek wrote:Technical answer. There is a fingerprint (header) at the beginning of the SQLite 3 format that is recognized by KEXI. If you install alternate application the same way, e.g. sqlitebrowser, and assign higher priority to it then it will. Whether it is done like this in various distributions is beyond of KEXI's scope. As long as the only app supporting SQLite 3-based files is KEXI, it can be assumed all these files are created by KEXI. It's a format like a container from our perspective. That's similar like the .odt format - if you unregister all software but zip handler then .odt would get opened by the zip decompressor, not a text processor.

Maybe some work can be done at the distribution level, that's a good idea.

Back story, KEXI started with SQLite 2 format version. Even version 3 of the format was long unversioned and have lacked support for information about sub-format. Currently it contains some bytes reserved for user-defined numeric information in the header. User defined means however that it would not be world globally registered format information.

I think it before this is solved in the header, KEXI would rather just start supporting plain SQLIte files (albeit it's not going to become generic db editor like SQLiteBrowser).

Thanks for such an exhaustive answer.