Proposed enhancement to the sqlite3.exe command-line shell

classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Proposed enhancement to the sqlite3.exe command-line shell

Richard Hipp-3
The Problem:

Many new users (especially university students taking a "database 101"
class) download the "sqlite3.exe" file from the SQLite website,
double-click on the "sqlite3" icon to get a command-line shell, then start
typing SQL statements.  But when they exit the shell, they are distressed
to discover that their database has disappeared.

Proposed Change To Address The Problem:

When launching sqlite3.exe with a double-click, have it open a standard
database in a standard place instead of an in-memory database as you would
get when launching sqlite3.exe with no arguments.  Possibly also give
additional hints, such as references to the ".open" command, when launching
by double-click.

(1) Detect double-click launch by looking at argc and argv.  On a
double-click launch, argc==1 and argv[0] contains the full pathname of the
executable.  On a command-line launch, argv[0] contains whatever the user
typed, which is usually not the full pathname

(2) This change would be for Windows only.  The code to implement it would
be enclosed in #ifdef _WIN32 ... #endif

(3) Announce the name of the "standard" database file in the banner.

Questions:

(4) What should the name of the "standard" database file be?

(5) In what folder should the "standard" database file be created?

--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed enhancement to the sqlite3.exe command-line shell

Simon Slavin-3

On 10 Feb 2014, at 3:23pm, Richard Hipp <[hidden email]> wrote:

> When launching sqlite3.exe with a double-click, have it open a standard
> database in a standard place instead of an in-memory database as you would
> get when launching sqlite3.exe with no arguments.  Possibly also give
> additional hints, such as references to the ".open" command, when launching
> by double-click.

If the shell does have to make up its own filepath it should tell the user what it did, where to find the path, and perhaps also how to specify their own path in future.

> [snip] (2) This change would be for Windows only.

Why ?  I suspect some Mac user would find it just as useful.  And then why leave Unix users out ?

> (5) In what folder should the "standard" database file be created?


I suspect the problem is knowing where a 'safe' location would be to create a file.  Could this be added as a variable inside the VFS ?  The VFS for HFS+ would presumably be able to assume you are on a Mac and produce a Mac-appropriate default pathname.  The VFS used inside an Android phone would, again, be a good place to do it.

Is that how the path for temporary files (not journal files, but /really/ temporary files) is decided ?

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed enhancement to the sqlite3.exe command-line shell

Stephan Beal-3
On Mon, Feb 10, 2014 at 4:41 PM, Simon Slavin <[hidden email]> wrote:

> Why ?  I suspect some Mac user would find it just as useful.  And then why
> leave Unix users out ?
>

Speaking as a member of the Unix-only crowd: please don't! While i admit
that the current behaviour has caused minor amounts of annoyance on my part
(my own fault, as i've been using it long enough to know better), i also
feel that the current behaviour is "correct." i think it's an interesting
idea for Windows, though. Don't have an opinion on Apple installations.

If it could be configured via environment variable, i'd be happy to see it
in Unix, too. e.g. SQLITE3_DEFAULT_DB, if set to a non-empty string, would
be the db which gets automatically opened at startup IFF 1==argc (or some
similar heuristic - maybe always load it if no filename args are provided).


--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed enhancement to the sqlite3.exe command-line shell

David Bicking-2
The first time I saw sqlite demonstrated at a linux user group, the presenter didn't realize he was using a memory database. I had to explain why all his work was lost, then proceeded to continue the demo since I knew more about the product. (This was years ago, I think we were still at sqlite 2 at the time.)

Personally, I don't like the idea of a default db. I would rather see a warning message sent to the console if no filename was specified saying that data is being saved in memory and will be lost on exit. And perhaps suggesting how to open a file if that is how they want to proceed.

I really don't like a bizarre solution that has sqlite3.exe or (sqlite3 on linux/mac) behaving differently between a double click or from the command line. That just seems wrong to me.

David

--------------------------------------------
On Mon, 2/10/14, Stephan Beal <[hidden email]> wrote:

 Subject: Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line shell
 To: "General Discussion of SQLite Database" <[hidden email]>
 Date: Monday, February 10, 2014, 10:46 AM
 
 On Mon, Feb 10, 2014 at
 4:41 PM, Simon Slavin <[hidden email]>
 wrote:
 
 > Why ?  I
 suspect some Mac user would find it just as useful.  And
 then why
 > leave Unix users out ?
 >
 
 Speaking
 as a member of the Unix-only crowd: please don't! While
 i admit
 that the current behaviour has
 caused minor amounts of annoyance on my part
 (my own fault, as i've been using it long
 enough to know better), i also
 feel that the
 current behaviour is "correct." i think it's
 an interesting
 idea for Windows, though.
 Don't have an opinion on Apple installations.
 
 If it could be configured via
 environment variable, i'd be happy to see it
 in Unix, too. e.g. SQLITE3_DEFAULT_DB, if set
 to a non-empty string, would
 be the db which
 gets automatically opened at startup IFF 1==argc (or some
 similar heuristic - maybe always load it if no
 filename args are provided).
 
 
 --
 -----
 stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal
 "Freedom is sloppy. But since
 tyranny's the only guaranteed byproduct of
 those who insist on a perfect world, freedom
 will have to do." -- Bigby Wolf
 _______________________________________________
 sqlite-users mailing list
 [hidden email]
 http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
 
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed enhancement to the sqlite3.exe command-line shell

Richard Hipp-3
In reply to this post by Richard Hipp-3
What if, instead of opening a standard database, the sqlite3.exe
command-line shell just issued a warning message reminding the user that
they are working on a transient in-memory database and suggesting the use
of the ".open" command to connect to a persistent on-disk database.  Like
in this patch:

     http://www.sqlite.org/src/info/90e9deae4a


--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed enhancement to the sqlite3.exe command-line shell

Dominique Devienne
In reply to this post by Richard Hipp-3
On Mon, Feb 10, 2014 at 4:23 PM, Richard Hipp <[hidden email]> wrote:

> Proposed Change To Address The Problem:
>
> When launching sqlite3.exe with a double-click, have it open a standard
> database in a standard place instead of an in-memory database as you would
> get when launching sqlite3.exe with no arguments.  Possibly also give
> additional hints, such as references to the ".open" command, when launching
> by double-click.
>

Personally, I don't care much for this change... I noticed you didn't ask
for +1 / -1 on this, but most REPLs behave like sqlite3 does now, i.e. pure
in-memory changes, and you need to explicitly do something to persist your
experimentations. My $0.02. --DD

Questions:
>
> (4) What should the name of the "standard" database file be?
>

In keeping with sqlite_master, I'd name it sqlite_default.db


> (5) In what folder should the "standard" database file be created?
>

It depends on the Windows version I'm afraid. On Win7,
%HOMEDRIVE%\%HOMEPATH% seems like a sensible default, or perhaps
%USERPROFILE% too. Didn't remember the previous Windows / DOS equivalents
for Vista, XP, and earlier. --DD

C:\Users\DDevienne>set USER
USERDNSDOMAIN=...
USERDOMAIN=...
USERNAME=DDevienne
USERPROFILE=C:\Users\DDevienne

C:\Users\DDevienne>set HOME
HOMEDRIVE=C:
HOMEPATH=\Users\DDevienne
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed enhancement to the sqlite3.exe command-line shell

Gabor Grothendieck
In reply to this post by Richard Hipp-3
On Mon, Feb 10, 2014 at 10:23 AM, Richard Hipp <[hidden email]> wrote:
> The Problem:
>
> Many new users (especially university students taking a "database 101"

The other features that would make teaching a bit easier would be to support
left join explicitly and support the rfc4180 standard for csv files.

> class) download the "sqlite3.exe" file from the SQLite website,
> double-click on the "sqlite3" icon to get a command-line shell, then start
> typing SQL statements.  But when they exit the shell, they are distressed
> to discover that their database has disappeared.
>
> Proposed Change To Address The Problem:
>
> When launching sqlite3.exe with a double-click, have it open a standard
> database in a standard place instead of an in-memory database as you would
> get when launching sqlite3.exe with no arguments.  Possibly also give
> additional hints, such as references to the ".open" command, when launching
> by double-click.
>
> (1) Detect double-click launch by looking at argc and argv.  On a
> double-click launch, argc==1 and argv[0] contains the full pathname of the
> executable.  On a command-line launch, argv[0] contains whatever the user
> typed, which is usually not the full pathname
>

I assume that means that if you do not keep sqlite3 on your path then you must
use:

   /path/to/sqlite3 :memory:

to call sqlite3 with an in-memory database. I am not so enthusiastic about this.

How about as an alternative that it works as it does now but when you
exit it asks you
if you want to save the database.  That seems more consistent with how
other programs
(editors, word processors, spreadsheets, etc.) work.

> (2) This change would be for Windows only.  The code to implement it would
> be enclosed in #ifdef _WIN32 ... #endif
>
> (3) Announce the name of the "standard" database file in the banner.
>
> Questions:
>
> (4) What should the name of the "standard" database file be?
>
> (5) In what folder should the "standard" database file be created?
>

%appdata%\sqilte
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed enhancement to the sqlite3.exe command-line shell

Simon Slavin-3
In reply to this post by Richard Hipp-3

On 10 Feb 2014, at 4:15pm, Richard Hipp <[hidden email]> wrote:

> What if, instead of opening a standard database, the sqlite3.exe
> command-line shell just issued a warning message reminding the user that
> they are working on a transient in-memory database and suggesting the use
> of the ".open" command to connect to a persistent on-disk database.

I find that equally acceptable, given the difficulty of squeezing in the 'Guess the acceptable path' routine at this stage.

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed enhancement to the sqlite3.exe command-line shell

Dominique Devienne
In reply to this post by Richard Hipp-3
On Mon, Feb 10, 2014 at 5:15 PM, Richard Hipp <[hidden email]> wrote:

> What if, instead of opening a standard database, the sqlite3.exe
> command-line shell just issued a warning message reminding the user that
> they are working on a transient in-memory database and suggesting the use
> of the ".open" command to connect to a persistent on-disk database.  Like
> in this patch:
>
>      http://www.sqlite.org/src/info/90e9deae4a


Sounds better to me. Although I'd still prefer a terser 1-liner is
possible. --DD
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed enhancement to the sqlite3.exe command-line shell

Jay Kreibich
In reply to this post by Richard Hipp-3

On Feb 10, 2014, at 10:15 AM, Richard Hipp <[hidden email]> wrote:

> What if, instead of opening a standard database, the sqlite3.exe
> command-line shell just issued a warning message reminding the user that
> they are working on a transient in-memory database and suggesting the use
> of the ".open" command to connect to a persistent on-disk database.  Like
> in this patch:
>
>     http://www.sqlite.org/src/info/90e9deae4a


I think a warning is the best solution.  In addition to the .open reminder,  I would add a ".save" shell command that dumps the current main database to a file.  This might be a simple alias to the .backup command.

  -j

--  
Jay A. Kreibich < J A Y  @  K R E I B I.C H >

"Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson




_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed enhancement to the sqlite3.exe command-line shell

John McKown
In reply to this post by Richard Hipp-3
Being a UNIX (Linux) partisan, and somewhat tacky towards Windows users,
why not go the normal Windows route of having a "pop up" dialog box (or at
least a message) similar to what normal Windows applications say about
possible loss of data. Something along the lines of "You are exiting
sqlite3, but there is data in one or more memory resident tables which will
be lost. Proceed (Y or N)?"


On Mon, Feb 10, 2014 at 10:15 AM, Richard Hipp <[hidden email]> wrote:

> What if, instead of opening a standard database, the sqlite3.exe
> command-line shell just issued a warning message reminding the user that
> they are working on a transient in-memory database and suggesting the use
> of the ".open" command to connect to a persistent on-disk database.  Like
> in this patch:
>
>      http://www.sqlite.org/src/info/90e9deae4a
>
>
> --
> D. Richard Hipp
> [hidden email]
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



--
Wasn't there something about a PASCAL programmer knowing the value of
everything and the Wirth of nothing?

Maranatha! <><
John McKown
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed enhancement to the sqlite3.exe command-line shell

Stephen Chrzanowski
I was just going to suggest that John.  Short of hitting CTRL-C to break
out of the program, the user may have to "double-quit" if no file path has
been given to be saved to, just for confirmation.

> .q
!!Warning - In-Memory Database not saved.  Quit again to exit without saving
> .q
C:\Users\Default User> _

Or, use ".qq" to force quit and ignore the warning.


On Mon, Feb 10, 2014 at 11:22 AM, John McKown
<[hidden email]>wrote:

> Being a UNIX (Linux) partisan, and somewhat tacky towards Windows users,
> why not go the normal Windows route of having a "pop up" dialog box (or at
> least a message) similar to what normal Windows applications say about
> possible loss of data. Something along the lines of "You are exiting
> sqlite3, but there is data in one or more memory resident tables which will
> be lost. Proceed (Y or N)?"
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed enhancement to the sqlite3.exe command-line shell

Jay Kreibich
In reply to this post by Jay Kreibich

On Feb 10, 2014, at 10:20 AM, Jay Kreibich <[hidden email]> wrote:

> On Feb 10, 2014, at 10:15 AM, Richard Hipp <[hidden email]> wrote:
>
>> What if, instead of opening a standard database, the sqlite3.exe
>> command-line shell just issued a warning message reminding the user that
>> they are working on a transient in-memory database and suggesting the use
>> of the ".open" command to connect to a persistent on-disk database.  Like
>> in this patch:
>>
>>     http://www.sqlite.org/src/info/90e9deae4a
>
>
> I think a warning is the best solution.  In addition to the .open reminder,  I would add a ".save" shell command that dumps the current main database to a file.  This might be a simple alias to the .backup command.
>

Actually... let me amend this.  I like the suggestion of having an .quit warning when "main" is an in-memory database.

In addition, I'd suggest a .save shell command that dumps the current main database to disk, and then opens the file as the new main.  This would provide a "document" model that many desktop users are already used to dealing with.


>   -j
>
> --  
> Jay A. Kreibich < J A Y  @  K R E I B I.C H >
>
> "Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson
>
>
>
>

--  
Jay A. Kreibich < J A Y  @  K R E I B I.C H >

"Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson




_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed enhancement to the sqlite3.exe command-lineshell

Tony Papadimitriou
In reply to this post by Richard Hipp-3
I second the idea of a kind of "WARNING: All your work will be lost, are you
sure you want to quit? (y/N)" on trying to exit, but *ONLY* if the
application was started by (double-)clicking on it, otherwise the warning
will be a nuisance when running test scripts.

-----Original Message-----
From: Richard Hipp
Sent: Monday, February 10, 2014 6:15 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Proposed enhancement to the sqlite3.exe
command-lineshell

What if, instead of opening a standard database, the sqlite3.exe
command-line shell just issued a warning message reminding the user that
they are working on a transient in-memory database and suggesting the use
of the ".open" command to connect to a persistent on-disk database.  Like
in this patch:

     http://www.sqlite.org/src/info/90e9deae4a


--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users 

_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed enhancement to the sqlite3.exe command-lineshell

Richard Hipp-3
On Mon, Feb 10, 2014 at 12:51 PM, <[hidden email]> wrote:

> I second the idea of a kind of "WARNING: All your work will be lost, are
> you sure you want to quit? (y/N)" on trying to exit, but *ONLY* if the
> application was started by (double-)clicking on it, otherwise the warning
> will be a nuisance when running test scripts.
>

I think I know how to detect a double-click launch versus a command-line
launch on windows.  But I don't know how to do this, or even if it is
possible to do, on Mac or Linux.  Anybody have any ideas?


--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed enhancement to the sqlite3.exe command-line shell

Mike King-6
In reply to this post by Richard Hipp-3
Why not show the warning on exit only if an in memory database is in use.
Likewise by default open in memory unless a path is specified.

On Monday, 10 February 2014, Richard Hipp <[hidden email]> wrote:

> On Mon, Feb 10, 2014 at 12:51 PM, <[hidden email] <javascript:;>> wrote:
>
> > I second the idea of a kind of "WARNING: All your work will be lost, are
> > you sure you want to quit? (y/N)" on trying to exit, but *ONLY* if the
> > application was started by (double-)clicking on it, otherwise the warning
> > will be a nuisance when running test scripts.
> >
>
> I think I know how to detect a double-click launch versus a command-line
> launch on windows.  But I don't know how to do this, or even if it is
> possible to do, on Mac or Linux.  Anybody have any ideas?
>
>
> --
> D. Richard Hipp
> [hidden email] <javascript:;>
> _______________________________________________
> sqlite-users mailing list
> [hidden email] <javascript:;>
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed enhancement to the sqlite3.exe command-line shell

Richard Hipp-3
On Mon, Feb 10, 2014 at 1:11 PM, Mike King <[hidden email]> wrote:

> Why not show the warning on exit only if an in memory database is in use.
>
>

Because on windows, the likely "exit" will be when the user clicks the big
red X in the upper right-hand corner, closing the terminal window down, so
there is no opportunity to display a warning nor ask for confirmation.

--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed enhancement to the sqlite3.exe command-lineshell

Kevin Martin
In reply to this post by Richard Hipp-3

On 10 Feb 2014, at 17:57, Richard Hipp <[hidden email]> wrote:

> I think I know how to detect a double-click launch versus a command-line
> launch on windows.  But I don't know how to do this, or even if it is
> possible to do, on Mac or Linux.  Anybody have any ideas?

For me, It's not so much how it is launched that matters, but whether it is running interactively. I would only want the behaviour altered if stdin is a terminal. What about something as simple as

isatty(STDIN_FILENO);

Thanks,
Kevin

 
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed enhancement to the sqlite3.exe command-line shell

Petite Abeille-2
In reply to this post by Gabor Grothendieck

On Feb 10, 2014, at 5:19 PM, Gabor Grothendieck <[hidden email]> wrote:

> The other features that would make teaching a bit easier would be to support
> left join explicitly and support the rfc4180 standard for csv files.

Hmmm?

Left join:
http://www.sqlite.org/syntaxdiagrams.html#join-operator

RFC-4180 compliant .import:
http://sqlite.org/releaselog/3_8_0.html


_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposed enhancement to the sqlite3.exe command-line shell

R Smith
In reply to this post by John McKown

On 2014/02/10 18:22, John McKown wrote:
> Being a UNIX (Linux) partisan, and somewhat tacky towards Windows users,
> why not go the normal Windows route of having a "pop up" dialog box (or at
> least a message) similar to what normal Windows applications say about
> possible loss of data. Something along the lines of "You are exiting
> sqlite3, but there is data in one or more memory resident tables which will
> be lost. Proceed (Y or N)?"

Being a Windows partisan and somewhat untacky to downright loving of all other systems and uses, allow me to explain the way Windows
works quickly - it has a kernel which runs services and programs, just like unix/linux/etc, and then it has a very standardized very
elaborate graphical user interface system which attaches graphical areas (commonly known as "Forms") to underlying processes - much
like OSX etc.

Running a process as a command-line or shell process means it can be really lightweight and devoid of any of the mentioned graphical
user-interfacy stuff, with the added benefit that, a few specific adaptations aside, you can use much the same C codebase to make it
run on linux or whatever else, much like the discussed slite3 tool. As such, attaching a pop-up anything to the process requires it
to have evolved into a GUI-supporting system so it has parent windows to have the popped-up handles attached to - a change which is
simple, but would see the exe auto-double in size.  So to answer your suggestion - no, that's not a good idea.

To further this point, there must be a quadrillion free full graphical-interface SQLite tools on every OS out there... why on earth
do students not simply use any of those?

FWIW, my vote goes with the current mainstream opinion, leave as is, warn when quitting, possibly provide a .save command. Forcing
the shell-window closed (Alt-F4, Click close, Alt-SPACE->C, Task manager, whatever) will steal any opportunity for ever having a
warning of any kind - but then, this is true for any other shell tool, why would it be a special requirement for sqlite3.exe? I
don't think anybody would expect to have their DB saved if they forcibly shutdown ANY app, only when exiting normally, one should be
at least warned of a potential loss.

_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
123