Suppose this where to
change in version 3.3.0 so that the actual error code
was returned by sqlite3_step().
Would it still be necessary to call sqlite3_finalize?
If so then I don't see the point of the API change.
Then when a schema change occurred, the statement was
automatically recompiled
API changes for SQLite are fine with me as long as the PHP folks keep up
with SQLite in terms of implementing SQLite hooks.
I'm not real experienced with SQLite, but I'm starting to learn a lot. I
use it with PHP 5.1 and PDOs. I find myself compiling the latest SQLite
CVS and the latest
> -Original Message-
> From: Darren Duncan [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 03, 2005 6:28 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Request for comment: Proposed SQLite API changes
>
> At 4:22 PM -0700 11/3/05, Robert Simpson wrote:
> >It's 100,000 more
At 4:22 PM -0700 11/3/05, Robert Simpson wrote:
It's 100,000 more memory allocations and about 4.6mb of string
copies SQLite is doing behind the scenes. Every time SQLite
prepares a statement it allocates and copies the string. If you're
inserting a million rows into a database using the
Thanks all!
I'll give those a go.
-Richard.
If your table is defined as
CREATE TABLE table0 (col1 INTEGER, col2 TEXT, col3 INTEGER)
I believe the correct syntax would be:
SELECT col1, quote(col2) AS col2, col3 FROM table0;
Instead of * you list the columns, separated by comma. Since you're using
quote() around col2, you probably need
Richard Boyd wrote:
Use the built-in quote() function.
--
Ok I think I found it. (http://www.sqlite.org/lang_expr.html)
I'm not really familiar with this method of calling a function in an
expression. Is there away to have it only quote the TEXT columns and not the
INTEGER columns,
"Richard Boyd" <[EMAIL PROTECTED]> wrote:
> >>Use the built-in quote() function.
> --
>
> Ok I think I found it. (http://www.sqlite.org/lang_expr.html)
> I'm not really familiar with this method of calling a function in an
> expression. Is there away to have it only quote the TEXT columns and not
Robert Simpson wrote:
This is one gives me pause. I see lots of people doing things like
this in their code (Using C# since I address this in my wrapper's
helpfile and its convenient):
using (SQLiteCommand mycommand = new SQLiteCommand(myconnection))
{
int n;
for (n = 0; n < 10; n
>>Use the built-in quote() function.
--
Ok I think I found it. (http://www.sqlite.org/lang_expr.html)
I'm not really familiar with this method of calling a function in an
expression. Is there away to have it only quote the TEXT columns and not the
INTEGER columns, or does it do this anyway by
- Original Message -
From: <[EMAIL PROTECTED]>
As currently implemented, when an error occurs during
sqlite3_step(), the function returns SQLITE_ERROR. Then
you have to call either sqlite3_reset() or sqlite3_finalize()
to find the actual error code. Suppose this where to
change in
>>Use the built-in quote() function.
--
Just what I'm after (huge sigh of relief) Is it sqlite3_quote?
I had a search through the documentation and didn't come up with anything.
Obviously I didn't look hard enough. I'll go back and look again.
Thanks very much for the quick response and
At 02:17 PM 11/3/2005, Fred Williams wrote:
>Has somebody got amnesia or something? I think I've seen this question
>going on four or five times now.
There was a problem with my subscription so I didn't see
my own posts. Not seeing it, I expected it got eaten by
a spam filter and sent it again.
"Richard Boyd" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Is there anyway to get Sqlite to add 'quotes' around text strings when it is
> returning data from a select command?
>
Use the built-in quote() function.
--
D. Richard Hipp <[EMAIL PROTECTED]>
Hi,
Is there anyway to get Sqlite to add 'quotes' around text strings when it is
returning data from a select command?
For example:
I have a table called table0 which is created using
CREATE TABLE table0 (col1 INTEGER, col2 TEXT, col3 INTEGER);
I have a row in the table
1|this is a text
Has somebody got amnesia or something? I think I've seen this question
going on four or five times now.
> -Original Message-
> From: Dave Dyer [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 03, 2005 12:40 PM
> To: sqlite-users@sqlite.org
> Subject: [sqlite] basic question about
I guess I have the same attitude as an old Main Framer I tried to sell a
Datapoint Arc Net long, long ago. His summation of the presentation
was, " I have enough damn trouble with one CPU. Why would I want a
whole network full of them!" I can barely keep one release of a
database running, why
To summarize my thoughts on this thread so far:
1. None of the stuff being discussed should cause a major version
change, such as to 4.x.y; a big leap like that should only be taken
for large and sweeping changes, such as incompatible file formats or
paradigm shifts.
Mainly, they should be
Dennis Cote wrote:
I think both of these proposed changes are useful enhancements to SQLite.
I also think it would be better to add a new sqlite3_step_v2() API
function that does this. This will eliminate the need to change the base
version number, since existing code can continue to use the
Ah, yes, I didn't consider that one. Thanks for pointing that out.
BEGIN TRANSACTION a;
[various DML commands]
BEGIN TRANSACTION b;
[various DML commands]
ROLLBACK;
[various DML commands]
COMMIT;
Should commit "a", but not "b".
That's a scenario I hadn't encountered before. I use classes
On 3 Nov 2005, at 08:18, [EMAIL PROTECTED] wrote:
As currently implemented, when an error occurs during
sqlite3_step(), the function returns SQLITE_ERROR. Then
you have to call either sqlite3_reset() or sqlite3_finalize()
to find the actual error code. Suppose this where to
change in version
If I designed a sqlite database to be used by a bunch of independent
applications, for example a group of CGI scripts each of which
opened the database, did some processing, and exited, would
that be (a) safe (b) effecient ?
From: "Marcus Welz" <[EMAIL PROTECTED]>
Reply-To: sqlite-users@sqlite.org
To:
Subject: RE: [sqlite] BEGIN TRANSACTION name
Date: Thu, 3 Nov 2005 12:46:39 -0500
I actually have a question regarding nested transactions. Maybe I'm missing
something, but isn't it true that
Marcus Welz wrote:
So, couldn't SQLite simply internally keep track of nested transaction
through a counter that is incremented every time "BEGIN TRANSACTION"
is encountered and decremented whenever "COMMIT" is encountered, and
only truly COMMIT when that counter has reached 0 again?
Commits
Fred Williams wrote:
Thanks. I guess I never considered using two different releases of
any product within the same executable. Wonder how many use this
feature and why?
SQLite2 and SQLite3 have incompatible database formats. Neither can read
the databases produced by the other. One might
:-) A very nice description of C. Unfortunately, it's the best
cross-platform/cross-language tool available for such a library.
Java and C++ have a whole other mess of compatibility problems - even
on the same platform. Try using a C++ shared library compiled in
GCC 2.9.x with code from GCC
On 11/3/05, Dennis Cote <[EMAIL PROTECTED]> wrote:
> I agree that moving away from the standard is a bad thing, but this
> change does not in any way merit forking SQLite or changing its name.
> SQLite currently deviates from the standard in much more significant
> ways than this proposed (well
I actually have a question regarding nested transactions. Maybe I'm missing
something, but isn't it true that the outermost transaction must be
committed successfully in order for any of the nested transactions to also
be committed successfully?
For example if I have:
BEGIN TRANSACTION a;
BEGIN
If I am not mistaken, you can configure Sqlite to not use floating point at
all. Divisions in such
an environment ought to be truncated integers without additional effort. But I
could be wrong.
--- Dennis Cote <[EMAIL PROTECTED]> wrote:
> I also think we should consider the use of SQLite in
Try using the ANALYZE command prior to querying under the latest version of
Sqlite. If that does
not work, please consider writing up a small test case and posting it to the
mailing list.
--- Preston Z <[EMAIL PROTECTED]> wrote:
> Any other hints about what is in the works for 3.3.0? I haven't
Jay Sprenkle wrote:
Since SQL conformance is hard to legitimately define (Are we
going to conform to cj date, mysql, oracle, etc.) you're right,
it would be hard.
I believe my original suggestion still has value:
If DRH is going to radically change SQLite (removing/redefining typing
and
Rob Lohman wrote:
Another proposal: Suppose that when creating an
sqlite3_stmt using sqlite3_prepare, the original SQL
text was stored in the sqlite3_stmt. Then when a
schema change occurred, the statement was automatically
recompiled and rebound. There would no more SQLITE_SCHEMA
errors.
In actual version, the optional transaction name is ignored because
SQLite currently does not allow nested transactions.
Any plan to change this behavior in the near future?
Thanks,
Marco Bambini
On 11/3/05, Rob Lohman <[EMAIL PROTECTED]> wrote:
>
> Does anyone runs code that actually changes the schema of
> your database as the normal process in an application? If so,
> for what reason?
I believe the automatic vacuum can cause a schema change event.
[EMAIL PROTECTED] wrote:
What about this change? Is it a worth-while tradeoff?
Personally, I would like to see both of these changes.
On Thu, 3 Nov 2005, Rob Lohman wrote:
>>
>> I'm a big fan of this change. We do quite a lot of bookkeeping in our
>> own code to do exactly the same thing at the moment. It would make me
>> very happy to delete that code.
>
>This is not directly a question for you, Eric, but does anyone
>actually
Yes I use SQLite for replicating a main oracle database.
Occasionally (and I mean occasionally) a schema change in Oracle needs
to be propagated to the SQLite database. So this situation does arise
for me.
-Original Message-
From: Rob Lohman [mailto:[EMAIL PROTECTED]
Sent: 03 November
Another proposal: Suppose that when creating an
sqlite3_stmt using sqlite3_prepare, the original SQL
text was stored in the sqlite3_stmt. Then when a
schema change occurred, the statement was automatically
recompiled and rebound. There would no more SQLITE_SCHEMA
errors. But sqlite3_stmts
On Thu, 3 Nov 2005 [EMAIL PROTECTED] wrote:
>As currently implemented, when an error occurs during
>sqlite3_step(), the function returns SQLITE_ERROR. Then
>you have to call either sqlite3_reset() or sqlite3_finalize()
>to find the actual error code. Suppose this where to
>change in version
I would be in favor of both changes.
Any other hints about what is in the works for 3.3.0? I haven't upgraded
past 3.2.2 because the optimizer changes made my application hang and i
haven't had a chance to re-write & test all of my queries. Any changes in
3.3.0 that would allow me to upgrade
Clay, I like stick-shifts, I drive motorcycles *and* stick-shifts, and I
was about to buy a Z4, but the wife stopped me (judging, correctly, that
it is a girl-trap).
I even write assembly now and then, when absolutely needed. I cant say
it is fun, though.
the thing is, I never have seen a single
[EMAIL PROTECTED] wrote:
Another proposal: Suppose that when creating an
sqlite3_stmt using sqlite3_prepare, the original SQL
text was stored in the sqlite3_stmt. Then when a
schema change occurred, the statement was automatically
recompiled and rebound. There would no more SQLITE_SCHEMA
the ...> indicates uou are continuing a statement, from you r example it looks
like you are lost. at this point you need to do what is needed to complete a
statement, even though the statement is garbage, try typing a ; (to end a sql
statemtent. you could be inside a quote so type a "; or '; to
Cariotoglou Mike said:
> a crappy .H file. these people (c programmers) live in wasteland, I
> really admire them for the constructive way they use header files,
> include files, defines, make files, configure files and what not,and
> still manage to write code that is write-once, compile
Chris Hanson wrote:
On Nov 2, 2005, at 7:36 AM, [EMAIL PROTECTED] wrote:
Am I alone in thinking that a division operator that does
different things depending on the declared datatype of a
column is an abomination?
I don't think you're alone. I do think you're wrong.
By declaring column a
> .quit
bash$
That should probably take care of you.
Clay Dowling
Tero Vihavainen said:
> yes I'm newbie ... :)
>
> ** clip ***
>
> [EMAIL PROTECTED]:/public$ ./sqlite3-3.2.7.bin
> SQLite version 3.2.7
> Enter ".help" for instructions
> sqlite> ^[[A^[[A^[[B^[[Bqqqccc
> ...> qq
>
since you work in D7, as I do, you already have namespaces (in the form
of units), so this was never an issue, even if you wanted to have two
versions of the same code built-in. as to why, well, consider a database
managent tool that has to open both 2.x and 3.x databases, and the only
tool to
You might be right.
It might be a good thing though. If nobody wants the
compliance/efficiency version then the other branch isn't burdened
with all the compliance code.
It's DRH's decision and I've put in my two cents worth.
Hopefully nobody has gone away with hard feelings.
On 11/3/05, Fred
ok, the sqlite_Schema thing can (and has) been wrapped. however, the
error code issue is there, I believe that we have agreed in the past
that it was bad design, but it could not be changed because of
compatibility issues. I,for one, am willing to comb my code and re-code
for this, so yes, please
[EMAIL PROTECTED] wrote:
As currently implemented, when an error occurs during
sqlite3_step(), the function returns SQLITE_ERROR. Then
you have to call either sqlite3_reset() or sqlite3_finalize()
to find the actual error code. Suppose this where to
change in version 3.3.0 so that the actual
I hate to duplicate code! How 'bout looking at a "STRICT SQL" Pragma?
Still sounds like a lot of work, and some level of footprint bloat, but
at least work continues on a single code base. I predict that both
branches of the proposed spilt will suffer and one or both will
eventually wither and
Since SQL conformance is hard to legitimately define (Are we
going to conform to cj date, mysql, oracle, etc.) you're right,
it would be hard.
I believe my original suggestion still has value:
If DRH is going to radically change SQLite (removing/redefining typing
and redoing the expression
The first proposal seems to me a very good one and contributes to
clarity in programs. The second one is of dubious value and a poor
tradeoff in my opinion.
JS
[EMAIL PROTECTED] wrote:
As currently implemented, when an error occurs during
sqlite3_step(), the function returns SQLITE_ERROR.
Brass Tilde wrote:
The problem with the grade-school rule is that, assuming the
last digit is uniformly distributed, you'll be rounding up 5
times out of 9 and rounding down 4 times out of 9.
No, if the last digit is uniformly distributed, then 0 is as likely as any
other. You round down
Thanks. I guess I never considered using two different releases of any
product within the same executable. Wonder how many use this feature
and why?
> -Original Message-
> From: Joe Wilson [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 03, 2005 8:54 AM
> To:
Your suggestions would require a lot of work. Considering this
free software I thought you would like to spearhead this SQL
conformance effort. I think it would be very valuable.
--- Jay Sprenkle <[EMAIL PROTECTED]> wrote:
> > We look forward to your standards compliance branch, Jay.
> >
Ah, that explains why I get all those bugs in each new release of Oracle
:-)
> -Original Message-
> From: Jay Sprenkle [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 03, 2005 8:44 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Request for comment: Proposed SQLite API
Henry Miller wrote:
On 11/1/2005 at 21:59 [EMAIL PROTECTED] wrote:
John Stanton <[EMAIL PROTECTED]> wrote:
Users love such a number system because it is natural and works like
the
Arithmetic they learned in Grade School.
I find the idea of dividing two integers stored in binary form
BCD goes back to the early days of computing. The COBOL "COMP3" type
was the mainstay of commercial data processing for decades. Commercial
computers had BCD decimal arithmetic instructions and could handle
accurate tabulations efficiently.
These days storage is not so expensive so we have
> Just curious, why is this being done anyway? I think this is the only
> software product I have used that has this "feature." I fail to see the
> usefulness from way up here above the source code, and I don't have time
> to look deeper. But still curious as to why everybody has to rename all
> We look forward to your standards compliance branch, Jay.
> Please tell us when we can expect to download your version.
DRH suggested a change, I put in my two cents since his message
included a call for commentary. If you don't like the suggestion please
feel free to ignore it or give a
Just curious, why is this being done anyway? I think this is the only
software product I have used that has this "feature." I fail to see the
usefulness from way up here above the source code, and I don't have time
to look deeper. But still curious as to why everybody has to rename all
their
My suggestion is aimed at simplicity. It proposes one human-readable
number format by default, not a constant interchange of underlying
types. To me it is very much in the spirit of the Sqlite paradigm.
JS
Andrew Piskorski wrote:
On Wed, Nov 02, 2005 at 06:43:31AM -0600, John Stanton wrote:
On 11/3/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Joe Wilson <[EMAIL PROTECTED]> wrote:
> >
> > With the recent numeric/integer/division change, the working
> > check clause and this proposed API changed shouldn't the version
> > number should be bumped to 4.0.0 to indicate
sqlite> .exit
The "-->" indicates a line continuation. Usually you can terminate it
with a semicolon or by closing a quote. This gets you back to the
"sqlite>" prompt where you can type ".help" and ".exit".
Shawn M. Downey
MPR Associates
10 Maxwell Drive, Suite 204
Clifton Park, NY 12065
On 11/2/2005 at 16:13 Eric Bohlman wrote:
>Henry Miller wrote:
>> As for 5/2, my grade school teachers taught me that if I round it at
>> all, the answer is 3, NEVER 2. It is only latter in life that I
>> learned about bankers rounding which sometimes is 2, sometimes 3.
I
>> have never seen
yes I'm newbie ... :)
** clip ***
[EMAIL PROTECTED]:/public$ ./sqlite3-3.2.7.bin
SQLite version 3.2.7
Enter ".help" for instructions
sqlite> ^[[A^[[A^[[B^[[Bqqqccc
...> qq
...> ^[
...>
...> ^X^X^X
...>
...>
...>
...> .exit
...>
...>
...> .quit
...> .bye
Dan Kennedy <[EMAIL PROTECTED]> wrote:
> > Another proposal: Suppose that when creating an
> > sqlite3_stmt using sqlite3_prepare, the original SQL
> > text was stored in the sqlite3_stmt. Then when a
> > schema change occurred, the statement was automatically
> > recompiled and rebound.
>
>
Joe Wilson <[EMAIL PROTECTED]> wrote:
>
> With the recent numeric/integer/division change, the working
> check clause and this proposed API changed shouldn't the version
> number should be bumped to 4.0.0 to indicate incompatibility with
> past versions?
>
That would compel me to change *all*
> Another proposal: Suppose that when creating an
> sqlite3_stmt using sqlite3_prepare, the original SQL
> text was stored in the sqlite3_stmt. Then when a
> schema change occurred, the statement was automatically
> recompiled and rebound.
This seems pretty handy, but it can be done in a
I'm for both changes...
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 03 November 2005 13:18
To: sqlite-users@sqlite.org
Subject: [sqlite] Request for comment: Proposed SQLite API changes
As currently implemented, when an error occurs during sqlite3_step(),
We look forward to your standards compliance branch, Jay.
Please tell us when we can expect to download your version.
--- Jay Sprenkle <[EMAIL PROTECTED]> wrote:
> I proposed splitting the project into two branches so people who wanted
> standards compliance and the people who wanted ease of
I vote for the cleaner API changes even though they are
not 100% backwards compatible. Alternatively you could
have a brand new step function, leaving the old versions with
the same functionality.
With the recent numeric/integer/division change, the working
check clause and this proposed API
As currently implemented, when an error occurs during
sqlite3_step(), the function returns SQLITE_ERROR. Then
you have to call either sqlite3_reset() or sqlite3_finalize()
to find the actual error code. Suppose this where to
change in version 3.3.0 so that the actual error code
was returned by
> MS SQL 2000 wil alsol insert (5, NULL)
Unless you additionally constrain the fields with "not null", but that's
a violation the "not null" constraint, not the "x < y" constraint.
Oracle 9.2
CREATE TABLE ex1(
x INTEGER,
y NUMBER(21,18),
CHECK( xmailto:[EMAIL PROTECTED]
Sent: 02 November 2005 23:31
To: sqlite-users@sqlite.org
Subject: [sqlite] CHECK constraints
In a CHECK constraint, if the expression is NULL (neither true nor
false) does the constraint
Hi,
In DB2 7.x the insert statement is also ok.
On 11/3/05, Nemanja Corlija <[EMAIL PROTECTED]> wrote:
>
> > Does the check constraint fail or not? Or do different
> > database engines do different things?
> In Firebird 1.5 it does fail.
>
> Though I agree with Darren's remarks, so not failing
77 matches
Mail list logo