spatialite_gui: '.db' as an accepted db-extention

[mj10777]

Although, of course not unique, something.db is often used as an extension for sqlite3 databases

- and it is truly a pain that one has to select 'All Files' while using such Open-Dialogs as 'Attach DataBase' to select one

Looking at:

http://www.file-extensions.org/db-file-extension

the *.db' extention is defined as follows:

The db file extension is used by various applications for database. Database is a structured collection of records or data that is stored in a computer system. The structure is achieved by organizing the data according to a database model. The model in most common use today is the relational model. Other models such as the hierarchical model and the network model use a more explicit representation of relationships.

So it would be save to assume, while using spatialite_gui, the user will not be attempting (in most cases at least) to open one of the following:

- ArcView object database file

- DIGIBooster module

- Various data files

- Corel Paradox database file

- data by Smartware

- Synopsys Design Compiler data file

- Microsoft Works file

- Progress database file

- Microsoft Windows thumbnail database file format

- S.T.A.L.K.E.R. X-Ray engine database file

- Psion Series 3 database file

- dBASE IV/dBFast configuration file

- Mozilla (Netscape) client certificate file

- Novell GroupWise address book database file

- Windows XP thumbnail database

- Apple Safari cache database file

- Atari Jaguar debugger script file

- WhatsApp Messenger message database file

Mark

[a.fu...@lqt.it]

On Thu, 18 Jun 2015 00:28:52 -0700 (PDT), mj10777 wrote:
> Although, of course not unique, something.db is often used as an
> extension for sqlite3 databases
> - and it is truly a pain that one has to select 'All Files' while
> using such Open-Dialogs as 'Attach DataBase' to select one
>

Hi Mark,

what you say is surely true; unhappily SQLite lacks any standard
definition about an eventual suffix/extension to be used for its
db-files.
users are absolutely free to create e.g. "data.jpg", "db.mdb",
"mydata.doc", "test.pdf", "repository.sqlite" or "myapp.db", and
all them can be absolutely valid SQLite3 database file names.

I personally always use ".sqlite" for all SQLite3 db-files
but I prefer ".fossil" for all Fossil repositories although
they actually are standard SQLite3 dbs.
Anyway different users can easily adopt different conventions,
and there is nothing intrinsically wrong in this.

A better and safest way to correctly recognize all SQLite3
db-files could be the one based on internal "magic number"
analysis: exactly as the standard Linux "file" command does.
Unhappily such a functionality is not directly supported by
standard GUI file section dialogs and doesn't seems easy to
be implemented.

> So it would be save to assume, while using spatialite_gui, the user
> will not be attempting (in most cases at least) to open one of the
> following:
>
> - ArcView object database file
> - DIGIBooster module
> - Various data files
> - Corel Paradox database file
> - data by Smartware
> - Synopsys Design Compiler data file
> - Microsoft Works file
> - Progress database file
> - Microsoft Windows thumbnail database file format
> - S.T.A.L.K.E.R. X-Ray engine database file
> - Psion Series 3 database file
> - dBASE IV/dBFast configuration file
> - Mozilla (Netscape) client certificate file
> - Novell GroupWise address book database file
> - Windows XP thumbnail database
> - Apple Safari cache database file
> - Atari Jaguar debugger script file
> - WhatsApp Messenger message database file
>

this is not a real issue: any attempt to connect a "wrong
file" will be immediately rejected by the sqlite3_open()
API, because it carefully checks the internal "magic number"
before going further on.
consequently the user will simply get a failure notification;
it will be surely annoying (and possibly confusing for noobs),
but it doesn't poses any serious trouble.

short conclusion: including ".db" to the standard list of
"reasonable extensions" could be a valid solution.
and adding a small validation routine directly checking the
internal magic numbers and eventually displaying some
"Sorry, this is not a valid SQLite3 database"
message could probably be even better.

bye Sandro