[sqlite] field length
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
Re: [sqlite] field length
=?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]
Re: [sqlite] Plugin help requested
that doesn't seem to be it - I have the same problem with this code.
#include stdio.h
#include stdarg.h
#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, db);
}
[sqlite] Temporary Tables
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] Temporary Tables
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
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
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] Temporary Tables
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] DEFAULT values replace explicit NULLs?
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] DEFAULT values replace explicit NULLs?
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?
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] Plugin help requested
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?
[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
[sqlite] Database locks up on AMD64/PHP
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
[sqlite] Problems compiling SQLite 3.3.4 on Mac OS X
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
Re: [sqlite] Problems compiling SQLite 3.3.4 on Mac OS X
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] sqlite3_prepare() returns SQLITE_ROW ???
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] sqlite3_prepare() returns SQLITE_ROW ???
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]
Re: [sqlite] Problems compiling SQLite 3.3.4 on Mac OS X
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] Problems compiling SQLite 3.3.4 on Mac OS X
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
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] sqlite3_prepare() returns SQLITE_ROW ???
[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
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] Problems compiling SQLite 3.3.4 on Mac OS X
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
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 [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] Coverity Open Source Defect Scan of SQLite
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] Compound queries parenthesis
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
[sqlite] Optional sqlite3 egg update
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
[sqlite] cannot commit transaction - SQL statements in progress
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, errmsg)) != 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, errmsg)) !=
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, errmsg)) !=
SQLITE_OK) {
if (errmsg != NULL) sqlite3_free(errmsg);
}
if (errmsg != NULL) sqlite3_free(errmsg);
Re: [sqlite] Problems compiling SQLite 3.3.4 on Mac OS X
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
Re: [sqlite] Problems compiling SQLite 3.3.4 on Mac OS X
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. http://www.write-brain.com/
Re: [sqlite] Problems compiling SQLite 3.3.4 on Mac OS X
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. http://www.write-brain.com/
[sqlite] Compatability issues with DBD::SQLite and SQLite v3.3.3 and 3.3.4
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 you can provide,
Steve
[sqlite] Merging of like databases to a single master database
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. **
Re: [sqlite] Database locks up on AMD64/PHP
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
Re: [sqlite] Compatability issues with DBD::SQLite and SQLite v3.3.3 and 3.3.4
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] Coverity Open Source Defect Scan of SQLite
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]
[sqlite] recompiled source code, make test failed
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] Compatability issues with DBD::SQLite and SQLite v3.3.3 and 3.3.4
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.
