New to SQL, SQLite, and the Delphi wrapper I'm using to
talk to sqlite.dll.
A couple of questions:
1. How can I get the dll to return JUST the desired data?
When I send the following SQL, for example,
select colEntry from tblEntry where colNum = 3
the textbox shows
I have a CREATE TABLE sql command with DEFAULT values. I would like
to BIND the default values, but it seems it is not supported. Is this
so?
I am using SQLITE3..
Any help appreciated.
Randall Fox
On Sat, 20 Nov 2004 08:08:48 -0500, you wrote:
>So to answer your questions:
>
> No, this is not a serious bug. You just need to be prepared to
> reissue any SQL statement that returns SQLITE_SCHEMA.
>
> Yes, this issue is fixed in version 3.0.
Thank you..
It seems the original poster
-Original Message-
From: Darren Duncan [mailto:[EMAIL PROTECTED]
Sent: Saturday, November 20, 2004 3:14 PM
To: [EMAIL PROTECTED]
Subject: RE: [sqlite] sqlite project--working with table structure
-- Darren Duncan
ok Darren. Thank you and the other posters for helping.
I will think
Hi Michael,
Michael Hunley wrote:
Hi,
I am currently using SQLite v 2.8.13 for a commercial product for Palm
Handhelds. I am noticing some performance issues; most notably when I
do a database validate() to verify my integrity at app open and
close. I see that version 3.0.8 has some code
Hi,
I am currently using SQLite v 2.8.13 for a commercial product for Palm
Handhelds. I am noticing some performance issues; most notably when I do a
database validate() to verify my integrity at app open and close. I see
that version 3.0.8 has some code optimizations, but am unsure if
At 5:40 AM -0500 11/20/04, j-marvin wrote:
Darren, this is cool. I can't wait to pass this along to a person
at my job who works with DB's at his full-time job.
Thanks, I appreciate it. Note also that another release of
SQL::Routine should be posted on CPAN either today or tomorrow.
I had
Ulrik Petersen wrote:
> [T]he way I understand SQLite, if you delete a row with the DELETE
> statement, the row will not actually be deleted, only marked as
> deleted. Then the next time you insert a row, the row may be reused.
> At least that's how I understand it... could somebody please
Randall Fox wrote:
I believe VACUUM changes the schema version numbering. After you
VACUUM, your sqlite3 struct holds information about your previous
database version. Solution: reopen the database and SQLite will pick up
the new changes. After that, INSERT will not report an error (until you
Hi Jim,
> hi-
>
> i was hoping to get a little feedback on an idea i had.
>
> the create table statement can get complex with its variable number
> field constraints and table constraints etc. etc.
> when i first tackled the problem i tried to parse it. now i have a
> different idea. what if i
Have a look here: http://search.cpan.org/dist/SQL-Routine/
That's part of a project I'm working on. With it, each database
table, as well as every other kind of thing you could possibly put in
a schema or use with a database, is represented as a cross-referenced
hierarchy of atomic-value
At 3:37 AM -0500 11/20/04, j-marvin wrote:
hi-
i was hoping to get a little feedback on an idea i had.
the create table statement can get complex with its variable number
field constraints and table constraints etc. etc.
when i first tackled the problem i tried to parse it. now i have a
different
>I believe VACUUM changes the schema version numbering. After you
>VACUUM, your sqlite3 struct holds information about your previous
>database version. Solution: reopen the database and SQLite will pick up
>the new changes. After that, INSERT will not report an error (until you
>VACUUM again,
13 matches
Mail list logo
