At 2:03 PM -0600 8/26/04, Dennis Cote wrote:
Multiple use, single bind named parameters are the preferred way to go. You
even say they are "ideal".
The implementation cost of this is a trivially more complex than straight
positional parameters. A simple loop calling strcmp() to match the parameter
Or try:
.mode lines
.null
select * from tablename limit 1;
The output is more readable if tablename has many columns and also provides
some example data for each column.
rayB
|-+--->
| | "Griggs, Donald"|
| |
Subject: [sqlite] How can i get the column's names from a table with the
sqlite.exe command line ?
Bonjours, Christian.
As far as I know, you could either:
Parse them from the output of
.schema tablename
or, more simply, if the table is non-empty:
.headers on
Michael Roth wrote:
I create a prepared statement with this:
local db = sqlite3.open("somefilename")
local stmt_a = db:prepare("SELECT * FROM test WHERE id=?1")
local stmt_b = db:prepare("XYZ ?1 XYZ ?2 XYZ ?1")
local id = 123
local str = "Hello World"
stmt_a:bind(id)
Darren Duncan wrote:
> In answer to both Michael Roth and Dennis Cote, I will try to explain
> the logic in what D. Richard Hipp presented as the way things
> currently are, as I understand the explanation.
>
> I interpret what DRH said in that SQLite 3 is still using plain
> vanilla positional
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Darren Duncan wrote:
| Each instance of the various formats he allows in SQL like ?|:|$ etc are
| just alternative format markings for a sequential placeholder/wildcard,
| and each location in a SQL string is given a unique sequential number in
| 1..N
I did, but the schema is about 4 times smaller than the DB file; also
the SQL script should be more comprimable than the db file.
This is obvious, because the db file also contain the SQL schema
queries, so it must be larger than the only SQLite schema :)
Paolo
I think you have to do some
At 2:39 PM +0100 8/26/04, Matt Sergeant wrote:
I already support sqlite3's numeric placeholders via the standard
DBI API. Switching to non-numeric placeholders will be more complex
(I'll have to use a hash instead of an array to store the
placeholders) but quite doable.
In case I was giving off
I think you have to do some VACUUM'ing in order to shrink the database.
--Keith
-Original Message-
From: Paolo Vernazza [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 26, 2004 9:56 AM
To: [EMAIL PROTECTED]
Subject: Re: [sqlite] .db file size is not changing
Unnikrishnan Nair wrote:
D. Richard Hipp wrote:
> Parameters can be in any of three forms:
>
> *
> *
> *
I repeat the other calls for continued (or added) support of the ?n style of
numbered parameters. They can of course be replaced by named parameters
using names like :Pn but that involves extra
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
one more glitch in the API:
nearly all sqlite3_xxx api calls takes or return simply 'const char *'
pointer. But two API functions return 'const unsigned char *':
sqlite3_column_text()
sqlite3_value_text()
All other API functions take or return
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
D. Richard Hipp wrote:
| Parameters can be in any of three forms:
|
| *
| *
| *
|
| Each parameter is assigned a number. Numbers are sequential from left
| to right and begin with 1. The parameter number is used to bind values
| to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
D. Richard Hipp wrote:
| All core features have been thoroughly tested. I'm looking for problems
| with the API. Do we need new parameters on some functions? Do we need
| to change the semantics of some functions?
Yes! I discoverd an issue with the
13 matches
Mail list logo
