On Thursday 08 April 2004 01:49 pm, Stathy G Touloumis wrote:
> Hi,
>
> We are working on a potential architecture by which many sqlite databases
> are created. There may be a need to aggregate data between databases and I
> was wondering if it's possible to quickly just 'cat' the databases
Hi,
We are working on a potential architecture by which many sqlite databases
are created. There may be a need to aggregate data between databases and I
was wondering if it's possible to quickly just 'cat' the databases together
or will they need to be recreated into a single sqlite file.
D. Richard Hipp wrote:
> The 1st and 3rd APIs above will work, but not the second. Remember,
> SQLite 3.0 will have manifest typing, which means that type of the
> data can change from one row to the next. Type is not associated
> with a column, as in standard SQL. So there is no way to know
> >
> > A statement's parameter values would be reset to null
> values when the
> > statement is reset.
> >
>
> Is that really the desired behavior? If you want to reset
> parameters on a statement reset, wouldn't it be better to do
> so explicitly. That way, if a statement has 10
Ulrik Petersen wrote:
I see that in 2.8.13, there are stubs for an encryption layer, but the
encryption itself seems not to have been made publicly available. Any
chance of this becoming public in the next release?
Form what I understand of the description on the SQlite site, encryption
is
Ulrik Petersen wrote:
I see that in 2.8.13, there are stubs for an encryption layer, but the
encryption itself seems not to have been made publicly available. Any
chance of this becoming public in the next release? If not, is there
any chance that the stubs could be documented so that one can
Dennis Cote wrote:
The API should provide functions that allow the application to inspect the
number, type, and names of the parameters that were discovered while parsing
the SQL. These functions could be called any time after the statement is
prepared.
int sqlite3_param_count(sqlite3_stmt*
D. Richard Hipp wrote:
> A design proposal for SQLite version 3.0 can be found at:
>
> http://www.sqlite.org/prop2.html
>
Richard,
I read your proposal and it all look very promising to me.
I would like to propose some additions to the API to support named
parameters in the SQL statement.
I've looked at the proposed changes for SQLite V3, and, whilst it all looks
reasonable, it does absolutely nothing for me...
The things I'd like would be more at the 'lower' levels of the database.
I'd like to see the query engine be able to use multiple indices if
appropriate, rather than
The proposal for version 3.0 looks very promising and I hope all the major
changes
will be implemented. Most of the enhancements seem to add flexibility and
scalability to
to the "C" based api. This is great as at the "C" api call level you can do
anything you want.
But I do not see any changes
Yes, that is right, my database consists of mainly numbers. Some of them
have 10 digits, some have less. This would explain part of the
difference. I was also wondering if Access perhaps has some type of
index comprimation, like cutting pre- and postfixes in the B-tree.
Jakub
Simon Berthiaume
Ben,
I think you're asking for is a mechanism to define the nature of the primary
key.
e.g. If you could define the primary key as some kind of function or to use
a specific integer field, then the table will be naturally ordered by that
field.
I don't know about other SQL engines, but our baby
> Could we please see the current behaviour set in stone? I'd like to know
> that generated keys will always fit into 32 bits (provided I don't
> exceed ~4.3 billion records, naturally).
I think that it's a dangerous precent to fix these things in stone, certainly at the
source level.
I have an application which depends on INTEGER PRIMARY KEY values
fitting into 32 bits.
I know that currently, the keys are generated with MAX()+1, but this
behaviour is "undocumented and liable to change.: Now that rowid's are
going 64 bit, a truly random INTEGER PRIMARY KEY may not fit into
14 matches
Mail list logo
