Re: [sqlite] Compatability issues with DBD::SQLite and SQLite v3.3.3 and 3.3.4

[Eric Bohlman]

Nathan Kurz wrote:

On Mon, Mar 06, 2006 at 06:24:13PM -0800, Steve Green wrote:

Hi,

I'm hoping that someone can shed some light on the following issue that
I'm seeing.  When I attempt to create a temp table using DBD::SQLite (v1.11)
and either SQLite v3.3.3 or v3.3.4, I get the following error:

DBD::SQLite::db do failed: not an error(21) at dbdimp.c line 398 at 


Same failures here on Linux 2.4.29.  I didn't have time to debug it,
so I decided just to downgrade to a copy of 3.2.7 that I had around,
and things were fine thereafter.  I presume that some recent change to
sqlite is not yet reflected in DBD::SQLite.  'make test' for
DBD::SQLite is another fine test program that fails.


You'll need to go into dbdimp.c and change the two calls to 
sqlite3_prepare() so that the third argument is -1 rather than zero. 
This is due to the change in check-in 3047.

[sqlite] recompiled source code, make test failed

[yklin]

Hi,
I recompiled sqlite (3.2.7) source in RedHat 9 (I upgrade kernel to 
2.4.31).  After all, "make test" reports lock test failed, why ? Is 
there any option in kernel need to turn on ? Do anyone have the same 
problem ?


thank you

yk

RE: [sqlite] Coverity Open Source Defect Scan of SQLite

[Alex Yeryomin]

It would be interesting to know how the result of Coverity analysis
changes resulting from your fixes.

> I got a login and have studied all 31 defects reported by your
> tool against SQLite.  This is a report of my findings:
> You can see my changes at
> D. Richard Hipp   <[EMAIL PROTECTED]>

Re: [sqlite] Compatability issues with DBD::SQLite and SQLite v3.3.3 and 3.3.4

[Nathan Kurz]

On Mon, Mar 06, 2006 at 06:24:13PM -0800, Steve Green wrote:
> Hi,
> 
> I'm hoping that someone can shed some light on the following issue that
> I'm seeing.  When I attempt to create a temp table using DBD::SQLite (v1.11)
> and either SQLite v3.3.3 or v3.3.4, I get the following error:
> 
> DBD::SQLite::db do failed: not an error(21) at dbdimp.c line 398 at 

Same failures here on Linux 2.4.29.  I didn't have time to debug it,
so I decided just to downgrade to a copy of 3.2.7 that I had around,
and things were fine thereafter.  I presume that some recent change to
sqlite is not yet reflected in DBD::SQLite.  'make test' for
DBD::SQLite is another fine test program that fails.

Nathan Kurz
[EMAIL PROTECTED]

Re: [sqlite] Database locks up on AMD64/PHP

[Firman Wandayandi]

On 3/7/06, Stefan de Konink <[EMAIL PROTECTED]> wrote:
> Hello,
>
>
> We are running SQLite 2.8.16 together with PHP5 on Linux. And it runs
> our TV Newspaper System. It was running on a PIII-1GHz but due some
> shifts for rendering performance increase (Inkscape SVG -> PNG) we moved
> the complete application to an AMD64.
>
> The last weeks it seems the database got locked very often, and made the
> apache/php system 'hang', not on query but on insert. Restarting Apache
> solves the problem making me wonder what I can do to visualize the
> problem or even fix it.
>
> As temporary fix I already tried to decrease the database size (now at
> 7MB). But this only increase speed (for now).
>

What's this meant?

--
Firman Wandayandi
Never Dreamt Before: http://firman.dotgeek.org/
Wishlist: http://www.amazon.com/gp/registry/1AAN8NZBHW2W9

[sqlite] Merging of like databases to a single master database

[Dale Qualls]

Okay, here's a strange one.  I have sqlite dbs for every day of the week.  
Every db is the same (contains 4 tables) as far as structure goes.
 
Is there a method from the command line (on a win32 box) that I can use the 
sqlite.exe to merge 10 days (so 10 dbs) worth of data into a single "master" 
database?  I was accomplishing this with 40 separate queries (4 for each of the 
10 days) within Access 2k but it takes an ungodly amount of time.
 
Just wondering if it was possible from the cmd line to speed it up.  A vacuum 
takes a large amount of time as well, each of the database files range from 
800-1200MB.
 
This is 2.x by the way.
 
Any help would be most appreciated.  The archives didn't lend much help.
 
ciao!






**
The preceding message and any attachments may contain confidential
information protected by the attorney-client or other privilege.  If you
believe that it has been sent to you in error, please reply to the sender
that you received the message in error and then delete it.  Nothing in
this email message, including the typed name of the sender and/or this
signature block, is intended to constitute an electronic signature unless
a specific statement to the contrary is included in the message.
**

[sqlite] Compatability issues with DBD::SQLite and SQLite v3.3.3 and 3.3.4

[Steve Green]

Hi,

I'm hoping that someone can shed some light on the following issue that
I'm seeing.  When I attempt to create a temp table using DBD::SQLite (v1.11)
and either SQLite v3.3.3 or v3.3.4, I get the following error:

DBD::SQLite::db do failed: not an error(21) at dbdimp.c line 398 at 

With trace level 9:

DBI::db=HASH(0x8475c88) trace level set to 0x0/9 (DBI @ 0x0/0) in DBI 
1.50-nothread (pid 9238)
2006-03-07 00:32:32.899578 create temp table distributors_tmp
-> do in DBD::_::db for DBD::SQLite::db (DBI::db=HASH(0x84758e0)~0x8475c88 
'create temp table distributors_tmp(
 d_id INT4 PRIMARY KEY,
 r_id INT2,
 m_id INT2,
 isp TEXT,
 city TEXT,
 country TEXT,
 type TEXT,
 notes TEXT)')
>> prepare DISPATCH (DBI::db=HASH(0x8475c88) rc1/2 @3 g0 ima2201 
pid#9238) at /usr/lib/perl5/site_perl/5.6.1/i386-linux/DBI.pm line 1551 via 
./distributor-import.pl line 134
1   -> prepare for DBD::SQLite::db (DBI::db=HASH(0x8475c88)~INNER 'create temp 
table distributors_tmp(
 d_id INT4 PRIMARY KEY,
 r_id INT2,
 m_id INT2,
 isp TEXT,
 city TEXT,
 country TEXT,
 type TEXT,
 notes TEXT)' undef)
dbih_setup_handle(DBI::st=HASH(0x8475d9c)=>DBI::st=HASH(0x8475ed4), 
DBD::SQLite::st, 8475da8, Null!)
dbih_make_com(DBI::db=HASH(0x8475c88), 0x84f3c58, DBD::SQLite::st, 124, 
(nil)) thr#(nil)
dbih_setup_attrib(DBI::st=HASH(0x8475ed4), Err, DBI::db=HASH(0x8475c88)) 
SCALAR(0x841c950) (already defined)
dbih_setup_attrib(DBI::st=HASH(0x8475ed4), State, DBI::db=HASH(0x8475c88)) 
SCALAR(0x841c9b0) (already defined)
dbih_setup_attrib(DBI::st=HASH(0x8475ed4), Errstr, DBI::db=HASH(0x8475c88)) 
SCALAR(0x841c980) (already defined)
dbih_setup_attrib(DBI::st=HASH(0x8475ed4), TraceLevel, 
DBI::db=HASH(0x8475c88)) 9 (already defined)
dbih_setup_attrib(DBI::st=HASH(0x8475ed4), FetchHashKeyName, 
DBI::db=HASH(0x8475c88)) 'NAME' (already defined)
dbih_setup_attrib(DBI::st=HASH(0x8475ed4), HandleSetErr, 
DBI::db=HASH(0x8475c88)) undef (not defined)
dbih_setup_attrib(DBI::st=HASH(0x8475ed4), HandleError, 
DBI::db=HASH(0x8475c88)) undef (not defined)
sqlite trace: prepare statement: create temp table distributors_tmp(
 d_id INT4 PRIMARY KEY,
 r_id INT2,
 m_id INT2,
 isp TEXT,
 city TEXT,
 country TEXT,
 type TEXT,
 notes TEXT)
1   <- prepare= DBI::st=HASH(0x8475d9c) at 
/usr/lib/perl5/site_perl/5.6.1/i386-linux/DBI.pm line 1551 via 
./distributor-import.pl line 134
>> execute DISPATCH (DBI::st=HASH(0x8475d9c) rc1/1 @1 g0 ima1041 
pid#9238) at /usr/lib/perl5/site_perl/5.6.1/i386-linux/DBI.pm line 1552 via 
./distributor-import.pl line 134
-> execute for DBD::SQLite::st (DBI::st=HASH(0x8475d9c)~0x8475ed4)
sqlite trace: Execute returned 0 cols

sqlite error 21 recorded: not an error at dbdimp.c line 398
!! ERROR: 21 'not an error(21) at dbdimp.c line 398' (err#0)
<- execute= undef at /usr/lib/perl5/site_perl/5.6.1/i386-linux/DBI.pm line 
1552 via ./distributor-import.pl line 134
!! ERROR: 21 'not an error(21) at dbdimp.c line 398' (err#0)
<- do= undef at ./distributor-import.pl line 134 via 
./distributor-import.pl line 131
DBD::SQLite::db do failed: not an error(21) at dbdimp.c line 398 at 
./distributor-import.pl line 134.
-> DESTROY for DBD::SQLite::st (DBI::st=HASH(0x8475ed4)~INNER)
   ERROR: 21 'not an error(21) at dbdimp.c line 398' (err#0)
<- DESTROY= undef at ./distributor-import.pl line 212
DBD::SQLite::db do failed: not an error(21) at dbdimp.c line 398 at 
./distributor-import.pl line 134.
-> DESTROY for DBD::SQLite::db (DBI::db=HASH(0x8475c88)~INNER)
   ERROR: 21 'not an error(21) at dbdimp.c line 398' (err#0)
<- DESTROY= undef

The perl code that generates this error is simply

my $dbh = DBI->connect( "dbi:SQLite:dbname=:memory:" );
die( "Can't connect to SQLite server: $DBI::errstr" ) unless( $dbh );

$dbh->{'RaiseError'} = 1;

eval
{
$dbh->do( "create temp table d_tmp(
 d_id INT4 PRIMARY KEY,
 r_id INT2,
 m_id INT2,
 isp TEXT,
 city TEXT,
 country TEXT,
 type TEXT,
 notes TEXT)" );
};
die ( $@ ) if ( $@ );

$dbh->disconnect();
exit 0;

When this code is run using SQLite v3.3.2 (or apparently any older version; we
also tried 3.3.1, 3.3.0, 3.2.7 and 3.2.0), there is no error.  No modifications
to any of the installations were made.

We are using perl 5.6.1 on Linux 2.6.12.6-nfs #1 SMP.

Thanks for any help 

Re: [sqlite] Problems compiling SQLite 3.3.4 on Mac OS X

[Tito Ciuro]

Hi James!

Even though I dragged the entire directory, os.c and shell.c were the  
only two files no included in the project. Weird...


Thanks so much!

-- Tito

On 06/03/2006, at 17:11, James W. Walker wrote:


Tito Ciuro <[EMAIL PROTECTED]> wrote:

When I create an Xcode project in Mac OS X and put all the SQLite  
files there, it doesn't compile:


ld: warning prebinding disabled because of undefined symbols
ld: Undefined symbols:
_sqlite3OsCheckReservedLock
_sqlite3OsClose
_sqlite3OsFileSize
_sqlite3OsLock
_sqlite3OsOpenDirectory
_sqlite3OsRead
_sqlite3OsSeek
_sqlite3OsSetFullSync
_sqlite3OsSync
_sqlite3OsTruncate
_sqlite3OsUnlock
_sqlite3OsWrite
/usr/bin/libtool: internal link edit command failed


Those are link errors, not compile errors, right?

It used to compile fine in the past. I see that these symbols are  
defined in os.h, which is included in the project. Any ideas?


The symbols are *declared* in os.h, but *defined* in os.c.  Is os.c  
in the project?

--
  James W. Walker, ScriptPerfection Enterprises, Inc.
  

Re: [sqlite] Problems compiling SQLite 3.3.4 on Mac OS X

[James W. Walker]

Tito Ciuro <[EMAIL PROTECTED]> wrote:

When I create an Xcode project in Mac OS X and put all the SQLite 
files there, it doesn't compile:


ld: warning prebinding disabled because of undefined symbols
ld: Undefined symbols:
_sqlite3OsCheckReservedLock
_sqlite3OsClose
_sqlite3OsFileSize
_sqlite3OsLock
_sqlite3OsOpenDirectory
_sqlite3OsRead
_sqlite3OsSeek
_sqlite3OsSetFullSync
_sqlite3OsSync
_sqlite3OsTruncate
_sqlite3OsUnlock
_sqlite3OsWrite
/usr/bin/libtool: internal link edit command failed


Those are link errors, not compile errors, right?

It used to compile fine in the past. I see that these symbols are 
defined in os.h, which is included in the project. Any ideas?


The symbols are *declared* in os.h, but *defined* in os.c.  Is os.c 
in the project?

--
  James W. Walker, ScriptPerfection Enterprises, Inc.
  

Re: [sqlite] Problems compiling SQLite 3.3.4 on Mac OS X

[Tito Ciuro]

Hello Marcel,

I should have been more specific. Sorry about that: when I ./ 
configure and then make, everything is fine. It passes all the tests.  
Cool. When I create an Xcode project in Mac OS X and put all the  
SQLite files there, it doesn't compile:


ld: warning prebinding disabled because of undefined symbols
ld: Undefined symbols:
_sqlite3OsCheckReservedLock
_sqlite3OsClose
_sqlite3OsFileSize
_sqlite3OsLock
_sqlite3OsOpenDirectory
_sqlite3OsRead
_sqlite3OsSeek
_sqlite3OsSetFullSync
_sqlite3OsSync
_sqlite3OsTruncate
_sqlite3OsUnlock
_sqlite3OsWrite
/usr/bin/libtool: internal link edit command failed

It used to compile fine in the past. I see that these symbols are  
defined in os.h, which is included in the project. Any ideas?


Thanks,

-- Tito

On 06/03/2006, at 12:52, Marcel Strittmatter wrote:


Hi

On my PowerMac G4 with Tiger 10.4.5 (Build 8H14), it works.
You can download an archive with finished configure and make steps  
from the following address:


http://www.dinoware.com/mailinglists/sqlite-3.3.4.tar.gz

You can look at the configure.log and make.log files to check for  
differences on your system.


Marcel

On 06.03.2006, at 21:11, [EMAIL PROTECTED] wrote:


Tito Ciuro <[EMAIL PROTECTED]> writes:


Hello,

SQLite 3.3.4
Mac OS X Tiger 10.4.5

After ./configure and make SQLite 3.3.4, I see that some files have
disappeared:

os_test.c
os_test.h
os_unix.h
os_win.h

This results in a few undefined symbols:

sqlite3OsClose
sqlite3FileSize
sqlite3OsLock
...

Any ideas?


First guess would be that 'configure' isn't detecting that OS X is  
Unix-like.
I suspect you might get a hint of what's going on if you carefully  
inspect the
output from 'configure' to see what supported OS it's detecting  
(if any).


Derrell

[sqlite] cannot commit transaction - SQL statements in progress

[Markus Kolb]

Hello,

I open one connection to a sqlitedb and do a few successful autocommited
sqlite3_exec() calls.
Then I want to use the db handle to call another sqlite3_exec() with SQL
  code for a transaction.
Before I close the connection I call again sqlite3_exec() with SQL
COMMIT to end the transaction.
This produces the sqlite error: cannot commit transaction - SQL
statements in progress

I don't use statements and/or threading in my code but sqlite is
compiled with threading enabled.

I don't understand why there are statements in progress?

In my code below I've used a while loop for the commit and this loops
endless, always reporting the SQL statements in progress error.

So what is going on there? What should I know?

Bye
Markus

Part my code with transaction:

strcpy(sql, "BEGIN EXCLUSIVE; INSERT INTO tbl_d (id) SELECT id FROM
tbl_o WHERE bs LIKE '32' AND bd < '1141078718' AND id NOT IN ( SELECT id
FROM tbl_d ); UPDATE tbl_o SET bs='64' WHERE bs LIKE '32' AND bd <
'1141078718'");

if ((dberr = sqlite3_exec(gdbh, sql, NULL, NULL, )) != SQLITE_OK) {
msg(MSG_ERROR, "(%d) %s", dberr, errmsg);
if (errmsg != NULL) sqlite3_free(errmsg);
strcpy(sql, "ROLLBACK");
if ((dberr = sqlite3_exec(gdbh, sql, NULL, NULL, )) !=
SQLITE_OK) {
msg(MSG_ERROR, "(%d) %s", dberr, errmsg);
if (errmsg != NULL) sqlite3_free(errmsg);
}
if (errmsg != NULL) sqlite3_free(errmsg);
return;
}
if (errmsg != NULL) sqlite3_free(errmsg);

strcpy(sql, "COMMIT");

while ((dberr = sqlite3_exec(gdbh, sql, NULL, NULL, )) !=
SQLITE_OK) {
if (errmsg != NULL) sqlite3_free(errmsg);
}
if (errmsg != NULL) sqlite3_free(errmsg);

[sqlite] Optional sqlite3 egg update

[Thomas Chust]

Hello,

the SQLite3 bindings got a big update and now support user defined 
collation sequences and SQL functions written in Scheme. They also do 
automagical recompilation of stale statements now.


For technical reasons I had to break the "valid NULL statement" workaround 
for these changes, though. If you are using a CVS version of SQLite3 
anyway, this is no problem for you, if not, you should maybe wait with the 
update of the sqlite3 egg until the next SQLite3 release comes out.


The updated documentation and egg can be found at
  http://www.chust.org/projects/sqlite3-1.5.html
  http://www.chust.org/projects/sqlite3-1.5.egg

cu,
Thomas

Re: [sqlite] Compound queries parenthesis

[Dennis Cote]

Boris Popov wrote:


I didn't get much traction on this issue last time around, so I apologize to
those who may think my persistence is annoying.

Why is it that this works,

SELECT DISTINCT * FROM (SELECT t1.ID, t1.STREET, t1.HOUSE_NUM
FROM GR_ADDRESS t1
WHERE t1.ID = 1 UNION ALL SELECT t1.ID, t1.STREET, t1.HOUSE_NUM
FROM GR_ADDRESS t1
WHERE t1.ID = 2) t1

but this doesn't?

SELECT DISTINCT * FROM (SELECT t1.ID, t1.STREET, t1.HOUSE_NUM
FROM GR_ADDRESS t1
WHERE (t1.ID = 1)) UNION ALL (SELECT t1.ID, t1.STREET, t1.HOUSE_NUM
FROM GR_ADDRESS t1
WHERE (t1.ID = 2)) 


Don't you think its strange?

Thanks!

-Boris

 


Boris,

That is just the way the SELECT statement syntax is specified as 
http://www.sqlite.org/lang_select.html shows.


What you have is

   SELECT DISTINCT * FROM table_list

Where your table list is a single table, and that table is the result of 
a subselect


   (SELECT ...)

In the first case you give the subselect an alias name, t1, and in the 
second you do not.


The first subselect is parsed as

   (
   SELECT ... FROM ... WHERE ...
   UNION ALL
   SELECT ... FROM ... WHERE ...
   }

This is a select with a single instance of

   SELECT ...
   [compound-op select]*

Notice that the second select statement is not  a subselect, and it 
can't be surrounded by (). That syntax is only allowed for subselects 
that are acting as table.


This is what you are trying to do with your second statement:

   (
   SELECT ... FROM ... WHERE ...
   )
   UNION ALL
   (  
   SELECT ... FROM ... WHERE ...

   }

and that syntax is not allowed so it generates a syntax error.

HTH
Dennis Cote

Re: [sqlite] Coverity Open Source Defect Scan of SQLite

[drh]

Ben Chelf <[EMAIL PROTECTED]> wrote:
> 
>So I'm basically asking for people who want to play around with some
> cool new technology to help make source code better. If this interests
> you, please feel free to reach out to me directly. And of course, if
> there are other packages you care about that aren't currently on the
> list, I want to know about those too.
> 

I got a login and have studied all 31 defects reported by your
tool against SQLite.  This is a report of my findings:

  *  A single potential segfault was located.  If you passed an
 invalid format letter with a large precision into
 sqlite3_mprintf() you could get it to core.  Example: 
 sqlite3_mprintf("%12345.12347y").  Of course, there are 
 lots of easier ways to get a segfault by misusing any 
 printf()-like routine (such as passing it an invalid pointer)
 so I do not see this as a serious problem. I did fix it,
 though.

  *  Two resource leaks were found:  failures to fclose() following
 a malloc() failure in the command-line shell and in the TCL
 interface.  I patched them both.  But neither was important since
 after a malloc() failure your process is going to be exiting
 soon anyhow.  Once again, both have been fixed.

  *  There were two reports of memory leaks in the lemon parser
 generator.   As this tools is purely a code generator for
 the SQLite parser and is not part of the SQLite deliverable,
 minor memory leaks there are not a big concern.  I did not
 try to fix them.

  *  The "parse.c" source file in SQLite is automatically generated
 code from "parse.h" using Lemon.  This seemed to get the
 static analysis tool really confused.  I was not able to
 understand any of the defects reported against parse.c.

  *  There were numerous cases found of conditionals that are
 always true or always false.  I removed all of those
 conditionals and replace them with asserts().

  *  There were some situations which were safe but which are
 clearly beyond the ability of a static analysis tool to
 prove safe.  For example, a function might be passed two
 parameters A and B where either both A and B are NULL or
 both are valid pointers but where you never have the case
 of A==0 and B!=0.  The analysis has no way to be aware of
 this constraint and thus found that there is a potential
 dereference of a null pointer if A==0 and B!=0.  I added
 assert()s to make these constraints clear, but I do not
 think the tool is able to reason about assert()s.

In summary, out of 31 defects reports, I found no serious bugs, one
potential segfault if sqlite3_mprintf() is misused, 2 resource leaks
following an out-of-memory condition and a dozen or so cases of
dead code that could be removed.

You can see my changes at

   http://www.sqlite.org/cvstrac/chngview?cn=3126

I was very favorably impressed by the quality of the output from
the analysis tool.  Even though no serious defects where found,
lots of minor problems were detected and the tool also found many
situations which would be difficult for human readers to 
understand and are thus worthy of additional assert()
statements and comments. Unlike the mindless and bothersome
warning messages that spew forth from microsoft compilers, the
"defects" found by the Coverity tool were all actually worth
looking into - every one of them.

--
D. Richard Hipp   <[EMAIL PROTECTED]>

Re: [sqlite] Problems compiling SQLite 3.3.4 on Mac OS X

[drh]

Tito Ciuro <[EMAIL PROTECTED]> wrote:
> Hello,
> 
> On 06/03/2006, at 12:44, [EMAIL PROTECTED] wrote:
> 
> > I build the OS-X version for the website on Tiger using
> > the ./configure script in the TEA version of SQLite.  You
> > might try it as a work-around.
> >
> > http://www.sqlite.org/sqlite-3.3.4-tea.tar.gz
> 
> I get a "document not found" error.
> 

I mistyped the link.  Should be:

  http://www.sqlite.org/sqlite-3_3_4-tea.tar.gz

--
D. Richard Hipp   <[EMAIL PROTECTED]>

Re: [sqlite] Problems compiling SQLite 3.3.4 on Mac OS X

[Tito Ciuro]

Hello,

On 06/03/2006, at 12:44, [EMAIL PROTECTED] wrote:


I build the OS-X version for the website on Tiger using
the ./configure script in the TEA version of SQLite.  You
might try it as a work-around.

http://www.sqlite.org/sqlite-3.3.4-tea.tar.gz


I get a "document not found" error.

Thanks,

-- Tito

Re: [sqlite] Problems compiling SQLite 3.3.4 on Mac OS X

[Tito Ciuro]

Hello Manfred,

On 06/03/2006, at 12:43, Manfred Bergmann wrote:


What source package did you download?


http://www.sqlite.org/sqlite-3.3.4.tar.gz



Were these files missing bevor configure and make, too?


Yes.

Thanks,

-- Tito

Re: [sqlite] Problems compiling SQLite 3.3.4 on Mac OS X

[Tito Ciuro]

Hi Derrell,

On 06/03/2006, at 12:11, [EMAIL PROTECTED] wrote:

First guess would be that 'configure' isn't detecting that OS X is  
Unix-like.
I suspect you might get a hint of what's going on if you carefully  
inspect the
output from 'configure' to see what supported OS it's detecting (if  
any).


Derrell


I don't see anything bizarre. Here's the output:


Last login: Mon Mar  6 13:10:04 on ttyp1
Welcome to Darwin!
da0304a-dhcp158:~ tciuro$ cd /Users/tciuro/Desktop/sqlite-3.3.4/
da0304a-dhcp158:~/Desktop/sqlite-3.3.4 tciuro$ ./configure
checking build system type... i686-apple-darwin8.5.1
checking host system type... i686-apple-darwin8.5.1
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for a sed that does not truncate output... /usr/bin/sed
checking for egrep... grep -E
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... no
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -p
checking whether ln -s works... yes
checking how to recognise dependent libraries... pass_all
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking how to run the C++ preprocessor... g++ -E
checking for g77... no
checking for f77... no
checking for xlf... no
checking for frt... no
checking for pgf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for f90... no
checking for xlf90... no
checking for pgf90... no
checking for epcf90... no
checking for f95... no
checking for fort... no
checking for xlf95... no
checking for ifc... no
checking for efc... no
checking for pgf95... no
checking for lf95... no
checking for gfortran... no
checking whether we are using the GNU Fortran 77 compiler... no
checking whether  accepts -g... no
checking the maximum length of command line arguments... 65536
checking command to parse /usr/bin/nm -p output from gcc object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking if gcc static flag  works... yes
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fno-common
checking if gcc PIC flag -fno-common works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (/usr/bin/ld) supports shared  
libraries... yes

checking dynamic linker characteristics... darwin8.5.1 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by g++... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... no
checking whether the g++ linker (/usr/bin/ld) supports shared  
libraries... yes

checking for g++ option to produce PIC... -fno-common
checking if g++ PIC flag -fno-common works... yes
checking if g++ supports -c -o file.o... yes
checking whether the g++ linker (/usr/bin/ld) supports shared  
libraries... yes

checking dynamic linker characteristics... darwin8.5.1 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
appending configuration tag "F77" to libtool
checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
Version set to 3.3
Release set to 3.3.4
Version number set to 3003004
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ANSI C... (cached) none needed
checking switches for the host compiler... -g -O2
checking target compiler... gcc
checking switches on the target compiler... -g -O2
checking target linker... gcc
checking switches on the target compiler... checking for ranlib...  
(cached) ranlib

-g -O2
checking if host and target 

Re: [sqlite] sqlite3_prepare() returns SQLITE_ROW ???

[Jarl Friis]

[EMAIL PROTECTED] writes:

> Jarl Friis <[EMAIL PROTECTED]> wrote:
>> What does does it mean when sqlite3_prepare() returns SQLITE_ROW.
>> 
>> It seems like this is just another valid (successful) return code from
>> sqlite3_prepare().
>> 
>> Can anyone ellaborate on this? please.
>> 
>
> sqlite3_prepare() should never return SQLITE_ROW.  If you have
> a reproducible test case where it does, we'd appreciate seeing
> it so that we can fix the bug.

Sorry... My fault it was rc from sqlite3_step(), and I do know what
that means. Thank you anyway.

Jarl

-- 
Jarl Friis
Softace ApS
Omøgade 8, 2.sal
2100 København Ø.
Denmark
Phone:  +45 26 13 20 90
E-mail: [EMAIL PROTECTED]
LinkedIn: https://www.linkedin.com/in/jarlfriis

Re: [sqlite] Problems compiling SQLite 3.3.4 on Mac OS X

[Marcel Strittmatter]

Hi

On my PowerMac G4 with Tiger 10.4.5 (Build 8H14), it works.
You can download an archive with finished configure and make steps  
from the following address:


http://www.dinoware.com/mailinglists/sqlite-3.3.4.tar.gz

You can look at the configure.log and make.log files to check for  
differences on your system.


Marcel

On 06.03.2006, at 21:11, [EMAIL PROTECTED] wrote:


Tito Ciuro <[EMAIL PROTECTED]> writes:


Hello,

SQLite 3.3.4
Mac OS X Tiger 10.4.5

After ./configure and make SQLite 3.3.4, I see that some files have
disappeared:

os_test.c
os_test.h
os_unix.h
os_win.h

This results in a few undefined symbols:

sqlite3OsClose
sqlite3FileSize
sqlite3OsLock
...

Any ideas?


First guess would be that 'configure' isn't detecting that OS X is  
Unix-like.
I suspect you might get a hint of what's going on if you carefully  
inspect the
output from 'configure' to see what supported OS it's detecting (if  
any).


Derrell

Re: [sqlite] Problems compiling SQLite 3.3.4 on Mac OS X

[drh]

Tito Ciuro <[EMAIL PROTECTED]> wrote:
> Hello,
> 
> SQLite 3.3.4
> Mac OS X Tiger 10.4.5
> 
> After ./configure and make SQLite 3.3.4, I see that some files have  
> disappeared:
> 
> os_test.c
> os_test.h
> os_unix.h
> os_win.h
> 
> This results in a few undefined symbols:
> 
> sqlite3OsClose
> sqlite3FileSize
> sqlite3OsLock
> 
> 
> Any ideas?
> 

I build the OS-X version for the website on Tiger using
the ./configure script in the TEA version of SQLite.  You
might try it as a work-around.

http://www.sqlite.org/sqlite-3.3.4-tea.tar.gz

--
D. Richard Hipp   <[EMAIL PROTECTED]>

Re: [sqlite] Problems compiling SQLite 3.3.4 on Mac OS X

[Manfred Bergmann]

Hi.

I haven't had any problems compiling under Mac OSX 10.4.5. Even  
making a universal binary was no problem at all, except that the  
"normal" (not the tcl) install process does not work properly and I  
had to link all object files myself with libtool.
What source package did you download? Were these files missing bevor  
configure and make, too?



Best regards,
Manfred


Am 07.03.2006 um 07:02 schrieb Tito Ciuro:


Hello,

SQLite 3.3.4
Mac OS X Tiger 10.4.5

After ./configure and make SQLite 3.3.4, I see that some files have  
disappeared:


os_test.c
os_test.h
os_unix.h
os_win.h

This results in a few undefined symbols:

sqlite3OsClose
sqlite3FileSize
sqlite3OsLock
...

Any ideas?

Thanks,

-- Tito







___ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: [sqlite] sqlite3_prepare() returns SQLITE_ROW ???

[drh]

Jarl Friis <[EMAIL PROTECTED]> wrote:
> What does does it mean when sqlite3_prepare() returns SQLITE_ROW.
> 
> It seems like this is just another valid (successful) return code from
> sqlite3_prepare().
> 
> Can anyone ellaborate on this? please.
> 

sqlite3_prepare() should never return SQLITE_ROW.  If you have
a reproducible test case where it does, we'd appreciate seeing
it so that we can fix the bug.
--
D. Richard Hipp   <[EMAIL PROTECTED]>

[sqlite] sqlite3_prepare() returns SQLITE_ROW ???

[Jarl Friis]

What does does it mean when sqlite3_prepare() returns SQLITE_ROW.

It seems like this is just another valid (successful) return code from
sqlite3_prepare().

Can anyone ellaborate on this? please.

Jarl

-- 
Jarl Friis
Softace ApS
Omøgade 8, 2.sal
2100 København Ø.
Denmark
Phone:  +45 26 13 20 90
E-mail: [EMAIL PROTECTED]
LinkedIn: https://www.linkedin.com/in/jarlfriis

Re: [sqlite] Problems compiling SQLite 3.3.4 on Mac OS X

[Derrell . Lipman]

Tito Ciuro <[EMAIL PROTECTED]> writes:

> Hello,
>
> SQLite 3.3.4
> Mac OS X Tiger 10.4.5
>
> After ./configure and make SQLite 3.3.4, I see that some files have
> disappeared:
>
> os_test.c
> os_test.h
> os_unix.h
> os_win.h
>
> This results in a few undefined symbols:
>
> sqlite3OsClose
> sqlite3FileSize
> sqlite3OsLock
> ...
>
> Any ideas?

First guess would be that 'configure' isn't detecting that OS X is Unix-like.
I suspect you might get a hint of what's going on if you carefully inspect the
output from 'configure' to see what supported OS it's detecting (if any).

Derrell

[sqlite] Problems compiling SQLite 3.3.4 on Mac OS X

[Tito Ciuro]

Hello,

SQLite 3.3.4
Mac OS X Tiger 10.4.5

After ./configure and make SQLite 3.3.4, I see that some files have  
disappeared:


os_test.c
os_test.h
os_unix.h
os_win.h

This results in a few undefined symbols:

sqlite3OsClose
sqlite3FileSize
sqlite3OsLock
...

Any ideas?

Thanks,

-- Tito

[sqlite] Database locks up on AMD64/PHP

[Stefan de Konink]

Hello,


We are running SQLite 2.8.16 together with PHP5 on Linux. And it runs 
our TV Newspaper System. It was running on a PIII-1GHz but due some 
shifts for rendering performance increase (Inkscape SVG -> PNG) we moved 
the complete application to an AMD64.


The last weeks it seems the database got locked very often, and made the 
apache/php system 'hang', not on query but on insert. Restarting Apache 
solves the problem making me wonder what I can do to visualize the 
problem or even fix it.


As temporary fix I already tried to decrease the database size (now at 
7MB). But this only increase speed (for now).



Yours Sincerely,

Stefan de Konink

Re: [sqlite] DEFAULT values replace explicit NULLs?

[Dennis Cote]

[EMAIL PROTECTED] wrote:


Dennis Cote <[EMAIL PROTECTED]> wrote:
 

It is worth noting that SQLite's behavior is not completely consistent. 
If the column is declared to be an 'integer primary key', then SQLite 
will insert a "default" value even when the user explicitly supplies a 
NULL value in an insert statement.


   



Remember that PRIMARY KEY implies NOT NULL.
--
D. Richard Hipp   <[EMAIL PROTECTED]>


 

Yes it does, so to follow the letter of the law, SQLite should throw an 
error when the user tries to insert a NULL into an "integer primary key" 
column. It doesn't do that, and I don't think it should be changed either.


I was just pointing out that a NULL doesn't always get inserted just 
because the user EXPLICITLY entered that value in an insert statement as 
was suggested by Derrell and others.


Dennis Cote

Re: [sqlite] Plugin help requested

[Jay Sprenkle]

I've read that message and spent a lot of time trying to figure out
why my code was broken, only to find out it wasn't my code. It was
annoying enough I remembered it ;)

Good luck

On 3/6/06, cstrader <[EMAIL PROTECTED]> wrote:
> Yes, was that ever obvious.  My dependency checker just didn't pick it up.  
> Thanks, Jay!!
>

Re: [sqlite] DEFAULT values replace explicit NULLs?

[Jay Sprenkle]

On 3/6/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Dennis Cote <[EMAIL PROTECTED]> wrote:
> >
> > It is worth noting that SQLite's behavior is not completely consistent.
> > If the column is declared to be an 'integer primary key', then SQLite
> > will insert a "default" value even when the user explicitly supplies a
> > NULL value in an insert statement.
> >
>
> Remember that PRIMARY KEY implies NOT NULL.

That's not 100% true.
In ms sql server this behaviour is a user option. You can set the 'identity'
property for a table. This allows you to explicitly specify the key column
on insert (unique constraint still applies), or the server inserts the value
for you and fails the insert if you specify a key value. It's primarily
used in replication so the related keys don't change.

Re: [sqlite] DEFAULT values replace explicit NULLs?

[drh]

Dennis Cote <[EMAIL PROTECTED]> wrote:
> 
> It is worth noting that SQLite's behavior is not completely consistent. 
> If the column is declared to be an 'integer primary key', then SQLite 
> will insert a "default" value even when the user explicitly supplies a 
> NULL value in an insert statement.
> 

Remember that PRIMARY KEY implies NOT NULL.
--
D. Richard Hipp   <[EMAIL PROTECTED]>

Re: [sqlite] DEFAULT values replace explicit NULLs?

[Dennis Cote]

Thomas Chust wrote:


On Fri, 3 Mar 2006, [EMAIL PROTECTED] wrote:


[EMAIL PROTECTED] writes:


Is the DEFAULT value for a column suppose to replace
an explicit NULL value?  Or does the DEFAULT value only
get used if no values for an insert is specified?  What
is the correct SQL behavior?

SQLite does the latter - the DEFAULT value is only used
if no value is given for the column.  If you insert an
explicit NULL value then a NULL value is inserted instead
of the DEFAULT value.  Ticket #1705 says this is
incorrect.

Which is right?  The current SQLite implementation or
ticket #1705?



I don't know which is "right" but I certainly have a strong 
preference.  If I
explicitly insert a value into a column, it's because I want *that* 
value
inserted -- even if the value I insert is NULL.  If I don't insert 
any value,
then I expect the DEFAULT value, if one is specified for the column 
to be

inserted in that column.

Derrell



Hello,

I can only second this statement. I would consider it very 
counterintuitive to have another values inserted instead of the 
explicitly specified one.


cu,
Thomas

I believe that SQLite's current behavior matches the SQL standard and 
should not be changed.


It is worth noting that SQLite's behavior is not completely consistent. 
If the column is declared to be an 'integer primary key', then SQLite 
will insert a "default" value even when the user explicitly supplies a 
NULL value in an insert statement.


   sqlite> create table t(a integer primary key, b);
   sqlite> insert into t values(NULL, NULL);
   sqlite> insert into t values(NULL, 1);
   sqlite> select * from t;
   1|
   2|1

In this case SQLite does not insert the explicitly supplied NULL value. 
It substitutes a "default" value that it determines internally.


To be completely consistent SQLite would have to be changed to require 
these insert statments to be entered  with a column list as below. Now 
the user has not supplied an explicit NULL value for column a, and it is 
more consistent for SQLite to substitute its rowid value.


   sqlite> insert into t(b) values(NULL);
   sqlite> insert into t(b) values(1);

I don't think any such change should be made, since it will probably 
break many applications, but it worth noting.


Dennis Cote

Re: [sqlite] Temporary Tables

[Jay Sprenkle]

> > > Can anyone help me with creating temporary tables in place of the views,
> > > which are available during runtime, which have the same fields and data
> > > as my view such that when one table is updated, the results are appended
> > > to the temporary table
> >
> > Why not just insert the content of the view into the temp table?
> >
> > insert into tmp_view_1
> >   select * from view_1

Temp tables will not be updated unless you do it manually.
You might talk to whoever is providing your software to connect the
report writer
to the database and ask them why views don't seem to work.

Re: [sqlite] Temporary Tables

[Roger]

The reason i am using views is that these tables change very often so if
i create the temp table, i do not know if it will be updated after the
original table is updated

On Mon, 2006-03-06 at 07:56 -0600, Jay Sprenkle wrote:

> > Can anyone help me with creating temporary tables in place of the views,
> > which are available during runtime, which have the same fields and data
> > as my view such that when one table is updated, the results are appended
> > to the temporary table
> 
> Why not just insert the content of the view into the temp table?
> 
> insert into tmp_view_1
>   select * from view_1

Re: [sqlite] Plugin help requested

[Jay Sprenkle]

Do you get the message 'the dll or one of it's component's can't be found'?
If so, check that all the required pieces (the sqlite dll), are either
in the current app
run directory, or the windows directory

Re: [sqlite] Temporary Tables

[Jay Sprenkle]

> Can anyone help me with creating temporary tables in place of the views,
> which are available during runtime, which have the same fields and data
> as my view such that when one table is updated, the results are appended
> to the temporary table

Why not just insert the content of the view into the temp table?

insert into tmp_view_1
  select * from view_1

[sqlite] Temporary Tables

[Roger]

Hello everyone.

I am using sqlite to create a web application. I am currently in the
process of writing reports using Agata.I had created views because i had
some tables whose rows i had to concatenate in order for the reports to
make any sense.

But the problem i have now is that Agata does not want to see or query
from the views. 

Can anyone help me with creating temporary tables in place of the views,
which are available during runtime, which have the same fields and data
as my view such that when one table is updated, the results are appended
to the temporary table

Re: [sqlite] Plugin help requested

[cstrader]

that doesn't seem to be it - I have the same problem with this code.

#include 
#include  

#define _SQLITE3_H_  extern "C" 

#define PLUGINAPI2 extern "C" 

PLUGINAPI2 typedef struct sqlite3 sqlite3;

PLUGINAPI2 int sqlite3_open(
  const char *filename, 
  sqlite3 **ppDb  
);

PLUGINAPI2 int main (){
  sqlite3 *db;
  int rc;
  
  //**THIS LINE RUNS FINE IN CONSOLE MODE BUT
  //WHEN IT IS UNCOMMENTED AB NO LONGER FINDS THE .DLL
  rc = sqlite3_open("C:\\test2.db", );  
}

Re: [sqlite] field length

[drh]

=?iso-8859-1?Q?Thomas_R=F8nshof?= <[EMAIL PROTECTED]> wrote:
> Is there a maximun for how many chars I can put in a VARCHAR  ?
> 

http://www.sqlite.org/faq.html#q11
--
D. Richard Hipp   <[EMAIL PROTECTED]>

[sqlite] field length

[Thomas Rønshof]

Is there a maximun for how many chars I can put in a VARCHAR  ?

I could use a field at about 1024 chars.




Med venlig hilsen / Best regards

Thomas Rønshof

Kyborg A/S
Ermelundsvej 132
DK-2820 Gentofte
Tel: +45 39 66 88 30
Fax: +45 39 55 15 29
E-mail: [EMAIL PROTECTED]


--

Jeg beskyttes af den gratis SPAMfighter til privatbrugere.
Den har indtil videre sparet mig for at få 632 spam-mails.
Betalende brugere får ikke denne besked i deres e-mails.
Hent gratis SPAMfighter her: www.spamfighter.dk