On 2014/02/21 11:54, _ph_ wrote:
Suggestion: Warning banner, and a .saveas command that copies the db to a
file.
(I haven't read the entire thread, sorry if this already came up.)
There is usually no call to read an entire thread, unless you decide to
actually post an opinion, in which case
Suggestion: Warning banner, and a .saveas command that copies the db to a
file.
(I haven't read the entire thread, sorry if this already came up.)
--
View this message in context:
http://sqlite.1065341.n5.nabble.com/Proposed-enhancement-to-the-sqlite3-exe-command-line-shell-tp73827p74071.html
On Tue, 11 Feb 2014 16:49:50 -0500
Stephen Chrzanowski wrote:
> I don't like the idea of letting the software decide what should be
> done based on a configuration file.
Hmm, isn't it the other way around? Does the user tell the software
what to do via a configuration file?
~/.sqliterc alr
On 11 Feb 2014 at 21:49, Stephen Chrzanowski wrote:
> I don't like the idea of letting the software decide what should be done
> based on a configuration file.
The .sqliterc file already exists, so you're too late.
> Linux and Windows both can isolate processes from each other, be
> completely
Lets not throw honey at the problem when a bear is around. Some of the
things I've seen in this thread just makes it sound like the kitchen sink
should be included in this application.
I don't like the idea of letting the software decide what should be done
based on a configuration file. Linux a
On Mon, Feb 10, 2014 at 10:30 PM, Simon Slavin wrote:
> On 11 Feb 2014, at 4:06am, James K. Lowden wrote:
>
>> ${HOME}/.sqlite/db would be my choice.
>
> Since the objective is not to let a naive user unexpectedly lose the data, it
> might seem a bad idea to put the file in a directory which is
On Tue, Feb 11, 2014 at 5:06 AM, James K. Lowden
wrote:
> > (1) Detect double-click launch by looking at argc and argv.
>
> Why make this a special case? If no database name is provided,
> the behavior should be the same regardless of how launched or what OS.
> Easier to explain; easier to unders
)
>-Original Message-
>From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-
>boun...@sqlite.org] On Behalf Of Nico Williams
>Sent: Monday, 10 February, 2014 21:36
>To: General Discussion of SQLite Database
>Subject: Re: [sqlite] Proposed enhancement to the sqlite3.exe co
On Mon, Feb 10, 2014 at 10:06 PM, James K. Lowden
wrote:
James proposes that when no DB is named on the command-line argument
list then a [user-specific] default be used, and that the user be
told.
I like it. I admit that I often rely on the shell keeping no state
when run with no arguments (I
On 11 Feb 2014, at 4:06am, James K. Lowden wrote:
> ${HOME}/.sqlite/db would be my choice.
Since the objective is not to let a naive user unexpectedly lose the data, it
might seem a bad idea to put the file in a directory which is hidden from naive
users.
Just another example of why constr
On Mon, 10 Feb 2014 10:23:57 -0500
Richard Hipp wrote:
> Proposed Change To Address The Problem:
Thank you for addressing this. I for one think you're getting a lot of
unhelpful advice. A database application that loses data? As a
feature?
> (1) Detect double-click launch by looking at argc
On Mon, Feb 10, 2014 at 1:56 PM, Petite Abeille
wrote:
>
> On Feb 10, 2014, at 7:39 PM, Gabor Grothendieck
> wrote:
>
>> That should have read right join.
>
> My personal opinion? Anyone even considering using a right outer join should
> be cursed into repeating their first day at high school.
On Feb 10, 2014, at 7:39 PM, Gabor Grothendieck wrote:
> That should have read right join.
My personal opinion? Anyone even considering using a right outer join should be
cursed into repeating their first day at high school. For ever. Groundhog Day,
The High School Years.
_
On 2014/02/10 20:31, Petite Abeille wrote:
On Feb 10, 2014, at 4:23 PM, Richard Hipp wrote:
Proposed Change To Address The Problem:
What’s the problem exactly? CS101 students distress? That’s way beyond SQLite
reach.
My 2¢: don’t create a default persistent database. This is not helpful to
That should have read right join. Its a nuisance when you are trying
to show someone SQL and trying to keep things simple that you have to
add the complexity of switching the arguments around.
I am still on 3.7.17 which is the version that currently ships with
the software I am using but its nice
of SQLite Database
> Subject: Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line
> shell
>
> On Mon, Feb 10, 2014 at 1:11 PM, Mike King wrote:
>
> > Why not show the warning on exit only if an in memory database is in use.
> >
> >
>
> Because on wi
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 alon
Good day,
I'd rather the warning be in the text when you open the sqlite tool with an
implied in memory database. Put an extra \n if you want the warning to
stand out.
Adam
On Mon, Feb 10, 2014 at 1:26 PM, Petite Abeille wrote:
>
> On Feb 10, 2014, at 5:19 PM, Gabor Grothendieck
> wrote:
>
On Feb 10, 2014, at 4:23 PM, Richard Hipp wrote:
> Proposed Change To Address The Problem:
What’s the problem exactly? CS101 students distress? That’s way beyond SQLite
reach.
My 2¢: don’t create a default persistent database. This is not helpful to
anyone.
_
On Feb 10, 2014, at 5:19 PM, Gabor Grothendieck 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 compl
On Mon, Feb 10, 2014 at 1:11 PM, Mike King 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 oppo
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 wrote:
> On Mon, Feb 10, 2014 at 12:51 PM, > wrote:
>
> > I second the idea of a kind of "WARNING: All your work will
On Feb 10, 2014, at 10:20 AM, Jay Kreibich wrote:
> On Feb 10, 2014, at 10:15 AM, Richard Hipp 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 d
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\Defa
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, bu
On Feb 10, 2014, at 10:15 AM, Richard Hipp 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
:
Subject: Re: [sqlite] Proposed enhancement to the sqlite3.exe command-line
shell
To: "General Discussion of SQLite Database"
Date: Monday, February 10, 2014, 10:46 AM
On Mon, Feb 10, 2014 at
4:41 PM, Simon Slavin
wrote:
> Why ? I
suspect some Mac user would find it ju
On Mon, Feb 10, 2014 at 5:15 PM, Richard Hipp 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 t
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
On Mon, Feb 10, 2014 at 10:23 AM, Richard Hipp 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.
> clas
On 10 Feb 2014, at 4:15pm, Richard Hipp 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 con
On Mon, Feb 10, 2014 at 4:23 PM, Richard Hipp 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 argument
On Mon, Feb 10, 2014 at 4:41 PM, Simon Slavin 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 o
On 10 Feb 2014, at 3:23pm, Richard Hipp 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 a
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
t
35 matches
Mail list logo