Hi,
Thanks I've tried building using the options below (compiler cmd line) -Dxxx
The object files will be built, but it appears that none of the
required objects are being created.
Using only these functions:
sqlite3_open()
sqlite3_exec()
sqlite3_free()
sqlite3_close()
Here's the compiler ou
tim <[EMAIL PROTECTED]> wrote:
>
> I would be very curious to know how exactly you leave out optional features.
>
Compiler command-line options. Ex: -DSQLITE_OMIT_TRIGGER=1
Here are all of the options:
SQLITE_OMIT_ALTERTABLE
SQLITE_OMIT_ANALYZE
SQLITE_OMIT_AUTHORIZATION
SQLITE_O
"When I compile on my linux box (SuSE 10.1) using GCC 4.1.0
and leaving out all the optional featuers of SQLite, I get
a library size of less than 166 KiB."
I would be very curious to know how exactly you leave out optional features.
If I write even a simple program using only the barest of cal
Dave Gierok <[EMAIL PROTECTED]> wrote:
> So, how is data represented in a :memory: db? Are :memory: db's different =
> in the way they store their data in memory vs. the way a file db stores its=
> data to file? Or is it as simple as instead of writing to file, it writes=
> to memory? If they
So, how is data represented in a :memory: db? Are :memory: db's different in
the way they store their data in memory vs. the way a file db stores its data
to file? Or is it as simple as instead of writing to file, it writes to
memory? If they are the same, are :memory: db's still cached?
Tha
tim <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm developing on an arm-elf platform that uses a flat binary (elf2flt)
> (mmu-less processor) and the smallest executable I'm able to generate
> runs about 599k. Also it tends to want an equal amount of memory at
> run-time, which the board
> will not su
Dennis Cote <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Dave Gierok <[EMAIL PROTECTED]> wrote:
> >
> >> It looks like the size of a Sqlite DB ends up being much larger
> >> (more than 2x) than size that I calculate for its data set.
> >>
> >> A simple test shows that when creating
Hi,
I'm developing on an arm-elf platform that uses a flat binary (elf2flt)
(mmu-less processor) and the smallest executable I'm able to generate
runs about 599k. Also it tends to want an equal amount of memory at
run-time, which the board
will not support (on top of the already running process
[EMAIL PROTECTED] wrote:
Dave Gierok <[EMAIL PROTECTED]> wrote:
It looks like the size of a Sqlite DB ends up being much larger
(more than 2x) than size that I calculate for its data set.
A simple test shows that when creating one table with one integer
column and filling it with 1 row
Thanks for the quick answer. I'm working on a game where memory is a precious
commodity, and we use a :memory: db. Is there a relatively easy way to do any
of:
- Make Sqlite use 32-bit floats instead of 64-bit doubles. Our DB contains a
lot of floating point data.
- Make Sqlite use 32-bit in
Jonas Sandman <[EMAIL PROTECTED]>
wrote:
Okay, now that I finally can get LIKE to work, my update seems to act
up instead.
It seems as if I sometimes get a SQLITE_LOCKED back from
sqlite3_reset(...).
Even though I try calling reset again, the actual insertion with
sqlite3_step(...) still return
Dave Gierok <[EMAIL PROTECTED]> wrote:
> It looks like the size of a Sqlite DB ends up being much larger
> (more than 2x) than size that I calculate for its data set.
>
> A simple test shows that when creating one table with one integer
> column and filling it with 1 rows, I get a DB size of
Okay, now that I finally can get LIKE to work, my update seems to act up
instead.
It seems as if I sometimes get a SQLITE_LOCKED back from sqlite3_reset(...).
Even though I try calling reset again, the actual insertion with
sqlite3_step(...) still returns error.
(1) SQL logic error or missing da
It looks like the size of a Sqlite DB ends up being much larger (more than 2x)
than size that I calculate for its data set.
A simple test shows that when creating one table with one integer column and
filling it with 1 rows, I get a DB size of 92KB instead of what I'd expect
to be around 40
On Tue, 31 Oct 2006 [EMAIL PROTECTED] wrote:
> No need to call in a preemtive Slashdot bombardment just yet.
> Let's give diplomacy a chance...
>
> --
> D. Richard Hipp <[EMAIL PROTECTED]>
<$.02> As was mentioned previously, why *not* add a prominent section
under the sqlite.org web site, which
Thanks you for all information, i am using turbo delphi, exists a function
UTF8Decode, i am using it for solve de problem, it function convert of
UTF-8 to WideString.
> Hello [EMAIL PROTECTED],
>
>> I am using SQliteSpy 1.5.5 for to execute de sql statement for fill the
>>table.
>
> SQLiteSpy is f
At 22:59 31/10/2006, you wrote:
I have to second this idea. It worked well for Poul-Henning Kamp.
He published an open letter
(http://net127.com/2006/04/07/open-letter-to-d-link-about-their-ntp-vandalism/
) to Dlink on 2006-04-07 which was linked to from many sites such as
slashdot, the regis
Robert L Cochran <[EMAIL PROTECTED]> wrote:
> I believe I overwrote my Fedora Core 5 version of sqlite (that's
> 3.3.3-1.2.x86_64) for the second time this year. I downloaded
> sqlite-3.3.8 and compiled it with this configure string:
>
> ../configure --prefix=/usr/local/sqlite-3.3.8 --libdir=/u
Hello [EMAIL PROTECTED],
> I am using SQliteSpy 1.5.5 for to execute de sql statement for fill the
>table.
SQLiteSpy is fully Unicode enabled, including the SQL editor. Hence, it
correctly stores text in whatever UTF format your database uses. This includes
tilde as well as French accented char
19 matches
Mail list logo