> I believe that by 'template files' you mean some example databases for common > applications, for instance invoicing, a list of the albums you have, a recipe > database, etc..
Yes, that is correct. > That's because what you seek does not exist. Well, it does exist if people share their SQLite database files ;-) > User interfaces are separate from the rdbms back end. Well, yes, I guess that's true. But an SQLite database file is a standalone database file that can be opened by any SQLite browser/management tool, such as the sqlite3 command line tool or any of the GUI tools listed here: http://www.tandb.com.au/sqlite/compare/ It is possible to design, say, a general invoicing database using the sqlite3 command line tool or a SQLite GUI tool and then open it in a completely different GUI tool. If the database designer has imbedded all the necessary logic in the SQL itself (such as through triggers and views), then the database file is a portable repository for information. I understand that in many cases, the SQLite database developed are intrinsically tied to and designed for the application framework in which they reside. However, even those SQLite database files can be opened and manipulated by a SQLite GUI tool or the sqlite3 command line tool. In fact, the developer of those probably highly specialized database files no doubt created the databases using a GUI or command line tool. > The UI depends on the application (accounting, addressbook, spatial analyses) In its basic form, the UI is just data viewing and entry into columns in rows. A generic GUI tool does that. > the language used for development (python, ruby, perl, C, Common LISP, object > COBOL), and the intended user base. If the logic is built into the SQL itself, then the other development language is not an issue. I can open my SQLite database files in a GUI tool written in Objective-C or the command line tool written in C, or a PHP front end to a web page, etc. > You also need to write the middleware that validates data entry, translates > between the human-readable UI widgets and the desired dbms action (INSERT, > DELETE, UPDATE, SELECT) using embedded SQL (a set-based language, not a > procedural one). That depends on the tool used. At the most basic level data validation should be enforced at the SQL level and the GUI tool should show any SQl generated errors. At a basic minimum, the GUI tool only has to facilitate basic SQL statement execution. If it has some nice GUI elements for update, insert etc, all the better. Thanks for the input, Tom BareFeetWare _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
