[sqlite] can i use sqlite3_column_***() function on multiple rows?
documentation says if int sqlite3_step(sqlite3_stmt*); returns SQLITE_ROW, (meaning a single row) then i can use int sqlite3_column_int(sqlite3_stmt*, int iCol); and other functions to extract the returned values out of the row. can i use the same set of API on a result set which contains multiple rows? if yes, which API do i call to move to the next row before calling sqlite3_column_* again? thanks. jack.
Re: [sqlite] can i use sqlite3_column_***() function on multiple rows?
[jack wu [EMAIL PROTECTED]] documentation says if int sqlite3_step(sqlite3_stmt*); returns SQLITE_ROW, (meaning a single row) then i can use int sqlite3_column_int(sqlite3_stmt*, int iCol); and other functions to extract the returned values out of the row. can i use the same set of API on a result set which contains multiple rows? if yes, which API do i call to move to the next row before calling sqlite3_column_* again? Just keep calling sqlite3_step() -- it will return SQLITE_ROW for each row of results (which you can use the sqlite_column_*() calls to extract data from), SQLITE_DONE if there are no more rows, or an error if something goes wrong. Brian
[sqlite] RDBMS handling of column names (was: Trouble with column names)
Hello Dr. Hipp, Hello dear sqlite users, following my post regarding how sqlite treats column names and the reply from Dr. Hipp, I've studied the way various RDBMS treat column names. The document containing the results obtained is attached to this message. The conclusions I can draw from these investigations is this: although not all queries tested work on all tested database engines, the ones that do work provide consistent results (e.g. SQL Server and MySQL yield the same results). Although things could further change in order to provide a uniform handling with column names, I only insist on one thing: if I ask for column Field1 and that column exists in the table as FIELD1, sqlite should return it as I ask, e.g. Field1 (instead of the way it does now, FIELD1). I cannot understand why this behavior has changed (it did not happen with 3.0.8). If this is not a bug, I guess it's a feature. If it's a feature, what advantages do I have if the database engine doesn't give me what I ask for? Please understand that I'm not trying to criticise anything or anyone: I'm just trying to understand why this has happened and why people do not complain about it. Thanks. George.
Re: [sqlite] can i use sqlite3_column_***() function on multiple rows?
You may want to try my 'Lite Wrap' wrapper API: http://www.sqlite.org/contrib This takes a single call: lw_query(sqlite3 *handle, const char *query); This safely returns a table in memory, without locking SQLite, to which you have random access. As well as some nice utils for displaying table data. I have had no feedback as to whether anybody likes this wrapper. But I use is exclusively and find it works well for me :) If any person uses this and can suggest enhancements, please let me know. Regards, Ben. Brian Swetland wrote: [jack wu [EMAIL PROTECTED]] documentation says if int sqlite3_step(sqlite3_stmt*); returns SQLITE_ROW, (meaning a single row) then i can use int sqlite3_column_int(sqlite3_stmt*, int iCol); and other functions to extract the returned values out of the row. can i use the same set of API on a result set which contains multiple rows? if yes, which API do i call to move to the next row before calling sqlite3_column_* again? Just keep calling sqlite3_step() -- it will return SQLITE_ROW for each row of results (which you can use the sqlite_column_*() calls to extract data from), SQLITE_DONE if there are no more rows, or an error if something goes wrong. Brian
Re: [sqlite] RDBMS handling of column names (was: Trouble with column names)
Hello Dr. Hipp, Hello dear sqlite users, following my previous post: I did not know that I'm not allowed to post attachments in this group... I've added the document which compares how SQL Server, MySQL and sqlite treats column names as an attachment to the wiki page (http://www.sqlite.org/cvstrac/wiki?p=ColumnNames) created by Dr. Hipp. It can be found at: http://www.sqlite.org/cvstrac/attach_get/167/ColumnNames.htm George.
Re: [sqlite] RDBMS handling of column names (was: Trouble with column names)
George Ionescu said: ask for? Please understand that I'm not trying to criticise anything or anyone: I'm just trying to understand why this has happened and why people do not complain about it. George, I suspect very strongly that most SQLite users are submitting themselves to that discipline which I suggested in an earlier message, principally that we don't expect SQLite to cover for our own inconsistencies in column naming. The discipline is fairly simple and I heartily encourage you to submit to it. Clay Dowling -- Lazarus Notes from Lazarus Internet Development http://www.lazarusid.com/notes/ Articles, Reviews and Commentary on web development
Re: [sqlite] RDBMS handling of column names (was: Trouble with column names)
Hello Clay, thanks for replying to the message, I suspect very strongly that most SQLite users are submitting themselves to that discipline which I suggested in an earlier message, principally that we don't expect SQLite to cover for our own inconsistencies in column naming. The discipline is fairly simple and I heartily encourage you to submit to it. I do agree that programming requires discipline. I myself am quite disciplined in programming (well, that's my personal oppinion about me, some people may think differently). The trouble is that my users aren't :-) The SQLiteDb ActiveX wrapper is written by me. My users complain that after the 3.2.1 update they aren't able to reference columns unless they respect case-sensitivityness. And I, as an independent software developer, cannot send emails to clients asking them to be disciplined :-) I could change my code to perform a case-insensitive comparison for column names but that would lead to a performance penalty (big enough not to do it). On the other hand, if you've read the document attached on the wiki, you'll notice that there are differences in the way sqlite treats column names as opposed to SQL Server and MySQL. And I don't really think I'm asking much: all I want is that when I ask for Field1 column, the database engine to report Field1 and not FIELD1. Do you think this is a stupid think to ask? Thanks again. George.
Re: [sqlite] RDBMS handling of column names (was: Trouble with column names)
On Wed, 2005-04-27 at 15:53 +0300, George Ionescu wrote: And I don't really think I'm asking much: all I want is that when I ask for Field1 column, the database engine to report Field1 and not FIELD1. Set PRAGMA short_column_names=OFF; and that will happen. Why doesn't that solution work for you? -- D. Richard Hipp [EMAIL PROTECTED]
Re: [sqlite] RDBMS handling of column names (was: Trouble with column names)
Hello Dr. Hipp, Hello dear sqlite users, And I don't really think I'm asking much: all I want is that when I ask for Field1 column, the database engine to report Field1 and not FIELD1. Set PRAGMA short_column_names=OFF; and that will happen. Why doesn't that solution work for you? Hmmm, too much caffeine and less sleep! I didn't notice, neither by reading the docs nor by experimenting with command line tool, that setting short_column_names=OFF is just what I need and think is the correct way of handling column names. Sorry for insisting so much. I didn't want to start a riot... Thanks again. George.
RE: [sqlite] sqlite3.exe timed queries
I for one would find this very useful. I would have found it most useful when initially evaluating SQLite a couple months ago, but I would still have a number of uses for it going forward. Not that my vote actually does you any good when it comes to implementing anything. :) -Tom -Original Message- From: Brown, Dave [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 26, 2005 3:16 PM To: sqlite-users@sqlite.org Subject: [sqlite] sqlite3.exe timed queries Hi - I think it would be extremely handy to have an option in the sqlite3.exe program for printing the execution time of a query. Would that be hard to add? I'm thinking something like: sqlite3 .timed sqlite3 select * from mytable; value1 value2 value3 ... Total Time: 1.253 milliseconds sqlite3 What do you guys think? -Dave
Re: [sqlite] Trouble with column names
On Wed, 2005-04-27 at 13:19 +, Tiago Dionizio wrote: On 4/27/05, D. Richard Hipp [EMAIL PROTECTED] wrote: I have closed all these tickets now. See wiki page http://www.sqlite.org/cvstrac/wiki?p=ColumnNames Isn't the pragma long_column_names supposed to be full_column_names? Yes, thanks. I have fixed the wiki page. -- D. Richard Hipp [EMAIL PROTECTED]
Re: [sqlite] Double quotes in C++ SQL statements
Literal syntax for strings In C and C++: This is a string This is a character -- 'c' This is NOT valid -- 'character' In Sqlite: This is a column name COL This is a literal string 'COL' To write SQL with double quotes escaped in C/C++ use the backslash: char* sql = SELECT \column name\ FROM Table WHERE id = 'frogfur' ; Google is your friend. The answer to every one of your questions is probably there waiting for you. On 4/26/05, Corwin Burgess [EMAIL PROTECTED] wrote: I need to know what the solution is to translate the following Delphi lines so that they will compile with C++ and be valid SQL statements. Delphi sSQL := 'INSERT INTO testtable(Name,OtherID,Number,Notes) VALUES (Some Name,4,587.6594,Here are some notes);'; sSQL := 'INSERT INTO testtable(Name,OtherID,Number,Notes) VALUES (Another Name,12,4758.3265,More notes);'; The following won' t compile. What do you do about the double-quotes as in Some Name, Here are some notes, Another Name, and More notes? I can get it to compile if I use \ but that causes a SQL exception. BCB6 sSQL = INSERT INTO testtable(Name,OtherID,Number,Notes) VALUES (Some Name,4,587.6594,Here are some notes);; sSQL = INSERT INTO testtable(Name,OtherID,Number,Notes) VALUES (Another Name,12,4758.3265,More notes);; Corwin -- --- You a Gamer? If you're near Kansas City: Conquest 36 https://events.reddawn.net The Castles of Dereth Calendar: a tour of the art and architecture of Asheron's Call http://www.lulu.com/content/77264
Re: [sqlite] can i use sqlite3_column_***() function on multiple rows?
On 4/27/05, jack wu [EMAIL PROTECTED] wrote: documentation says if int sqlite3_step(sqlite3_stmt*); returns SQLITE_ROW, (meaning a single row) then i can use int sqlite3_column_int(sqlite3_stmt*, int iCol); and other functions to extract the returned values out of the row. can i use the same set of API on a result set which contains multiple rows? if yes, which API do i call to move to the next row before calling sqlite3_column_* again? Yes. You call step again. Bind your results to variables. execute step repeatedly to retrieve all rows. It returns SQLITE_DONE when you try to fetch past the last row.
RE: [sqlite] RDBMS handling of column names (was: Trouble with column names)
This is fine for me too. However, in 3.1.0 neither of these pragmas appeared to work. Are they fixed in a later release or check-in? Sorry, but I couldn't find this info on the website. -Original Message- From: George Ionescu [mailto:[EMAIL PROTECTED] Sent: 27 April 2005 14:18 To: sqlite-users@sqlite.org Subject: Re: [sqlite] RDBMS handling of column names (was: Trouble with column names) Hello Dr. Hipp, Hello dear sqlite users, And I don't really think I'm asking much: all I want is that when I ask for Field1 column, the database engine to report Field1 and not FIELD1. Set PRAGMA short_column_names=OFF; and that will happen. Why doesn't that solution work for you? Hmmm, too much caffeine and less sleep! I didn't notice, neither by reading the docs nor by experimenting with command line tool, that setting short_column_names=OFF is just what I need and think is the correct way of handling column names. Sorry for insisting so much. I didn't want to start a riot... Thanks again. George.
RE: [sqlite] Trouble with column names
Imho, naming scheme should be like this: 1. column names as returned from sqlite3_column_name should always be a single word, NOT qualified by origin. So, all below should return field1 as column name. If there is a column alias in the select, the *alias* should be returned as the single word. Case should be irrelevant for column names, as sql is supposed to be case-insensitive. 2. In case where an expression is given as column, say select field1+5 from..., it is Customary to return a pseudo name such as ExprN, where n=1..n. in any case, this is not Important, so use any scheme you find suitable. 3. there *should* be (nice to have) an sqlite3_column_origin function, which attempts to Return the column origin, in the form: Database.table.column In all cases, the *real* names should be returned, and not the aliases column_name column_origin -- select field1 from test; field1 test.field1 select field1 from test;field1 '' select FIELD1 from test; field1 (or FIELD1) '' select FIELD1 from test;field1 '' select [field1] FROM test;field1 '' select test.field1 from test; field1 '' select a.field1 from test as a; field1 '' select a.field1 from test as a; field1 '' select a.field1 from test as a; field1 '' select main.test1.field1 from test; field1 main.test.field1 select [main].a.[field1] from test as a;field1 test.field1 select field1 as a from test a test.field1 etc This problem is related to the naming of columns in views. Please tell me what the column names for the following views should be: create view v1 as select field1 from test; create view v2 as select FIELD1 from test; create view v3 as select a.field1 from test as a; create view v4 as select test1.field1 from test; create view v5 as select FIELD1 from test; create view v6 as select A.FIELD1 from test as a; create view v7 as select a.field1 + 5 FROM test as a; create view v8 as select a.field1+5 from test as a; I believe in all cases, the names for sqlite3_column_name, and sqlite3_column_origin should be exactly the same as if the View was not present, ie as if the select was given directly. Another place where naming is an issue is on CREATE TABLE AS statements. What is the name of the column in each of the following tables: create table t2 as select field1 from test; create table t3 as select FIELD1 from test; create table t4 as SELECT a.field1 from test as a; -- and so forth Same comment as above, the column names should be the same for the equivalent SELECT (and data types as well) For the above, what is the column name reported out when I do: select * from t2; select * from t3; -- and so forth or select * from v1; select * from v2; -- and so forth If someone will come up with a coherent set of column naming rules - rules which other popular SQL database engines follow - then I will be happy to implement them in SQLite. Doing so will probably break a lot of existing code. But as the column naming rules have never been specified or documented before, I'd be willing to do it since any code that breaks would have been depending on undefined behavior to begin with. Does the SQL standard have anything to say about this? Does anybody know? I don't believe so. So, really, it is a matte of choice. However, let us examine the rationale of column naming requests you have been getting all this time. They come under two categories : A. people that do not like the current scheme / cannot make it compatible with some other database etc etc IMHO this is a lot of noise about a non-significant issue. Column names are retrieved from the sql statement, and people have the chance to map them to whatever they think is significant for the end-user. Programs can handle this easily, so I don't understand what it all the fuss about. My only comment here is that column names should be short (like pragma short_column_name), because this is what databases normally do. B. People who need to use column names to do generic processing, like machine-generated UPDATES, discovery of relations etc In this case, it is *ESSENTIAL* that : a. column names are consistent, and as informative as possible b. the origin of data can be retrieved as clearly as possible, since it is *this* which is needed by tools writers, and not any aliasing that the programmer has used in order to resolve ambiguities or for prettying up the sql statement. So, this is why I propose a second api, sqlite3_column_origin, which can return the real origin of the data, skipping aliases, views, etc. of course there are cases where the origin cannot be
[sqlite] sqlite3_bind_text() and SQLITE_STATIC question
Greetings All, In general, is passing NULL to sqlite3_bind_text() as parameter 5 valid, instead of using either SQLITE_STATIC or SQLITE_TRANSIENT? (My bind value is a heap pointer which I manage). I ask because on SOLARIS, compiling (C++ compiler, .cpp module) when passing SQLITE_STATIC produces this rather annoying warning: Warning (Anachronism): Formal argument 5 of type extern C void(*)(void*) in call to sqlite3_bind_text(sqlite3_stmt*, int, const char*, int, extern C void(*)(void*)) is being passed void(*)(void*). Thanks for your help, -- Gerry Blanchette
Re: [sqlite] Patches for CVSTrac?
On Tue, 26 Apr 2005, D. Richard Hipp wrote: On Tue, 2005-04-26 at 17:49 +0100, Christian Smith wrote: Just created ticket #1224 to remove config.h from build, but there appears to be no way to attach a patch to the ticket itself. Have I missed something? There is an [Attach] hyperlink at the top of the screen. Worst thing is I've attached things before to other tickets. D'oh. Patch is attached to ticket. I've done a Solaris 32-bit to Solaris 64-bit target build, and come out with a working sqlite3 binary, but as yet I've not run the regression tests due to lack of installed TCL libraries, but I have bumped into the alignment problem I seem to remember running into before. I've built with 32-bit gcc 3.3.2, using the -m64 flag to generate a 64-bit binary. The callback trace (debugging symbols don't appear to work with gdb or Sun Forte 6) main(0x2, 0x77e8, 0x7800, 0x100185460, 0x1, 0x0) process_input(0x7fffedf0, 0x0, 0x10018ad70, 0x7efefeff, 0x81010100, 0xff) sqlite3_exec(0x100187e50, 0x100186c40, 0x18808, 0x7fffedf0, 0x7fffecd0, 0xff00) sqlite3_step(0x1001ae070, 0x100186c40, 0x, 0x7fffebe8, 0x7fffebf0, 0x0) sqlite3VdbeExec(0x1001ae070, 0x0, 0x, 0xfff8, 0x0, 0x10018b131) sqlite3BtreeInsert(0x1001b1d80, 0x0, 0x66, 0x1001b19a0, 0x5, 0x1001b1958) balance(0x1001ad7b8, 0x1, 0x1001af9a0, 0x7, 0x0, 0x0) balance_deeper(0x1001ad7b8, 0x1001b19a5, 0x0, 0x0, 0x1, 0x1001af9a2) balance_nonroot(0x1001b0208, 0x2, 0x0, 0x0, 0x0, 0x1001b0220) Same trace as that 64-bit problem you worked on last October, check in #2026: http://www.sqlite.org/cvstrac/chngview?cn=2026 Do you have any other alignment/size assumptions, other than the ones fixed above? Or this could just be a bug in gcc perhaps? I can retry the build using the Sun compiler to generate the 64-bit binaries. Either way, I still think it's worth removing config.h from the build to help with general cross building. Cheers, Christian -- /\ \ /ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL X - AGAINST MS ATTACHMENTS / \
Re: [sqlite] sqlite3_bind_text() and SQLITE_STATIC question
Ulrik Petersen wrote:
Hi Gerry,
Gerry Blanchette wrote:
Greetings All,
In general, is passing NULL to sqlite3_bind_text() as parameter 5 valid,
instead of using either SQLITE_STATIC or SQLITE_TRANSIENT? (My bind
value is a heap pointer which I manage).
I ask because on SOLARIS, compiling (C++ compiler, .cpp module) when
passing SQLITE_STATIC produces this rather annoying warning:
Warning (Anachronism): Formal argument 5 of type extern C
void(*)(void*) in call to sqlite3_bind_text(sqlite3_stmt*, int, const
char*, int, extern C void(*)(void*)) is being passed void(*)(void*).
Thanks for your help,
-- Gerry Blanchette
When you #include sqlite3.h, you should enclose that #include in this
construct:
extern C {
#include sqlite3.h
}
That may solve your problem.
sqlite3.h contains:
#ifdef __cplusplus
extern C {
#endif
#ifdef __cplusplus
} /* End of the 'extern C' block */
#endif
It does the `extern C' block automatically.
Likewise, the function that you pass should be declared 'extern C' if
it's one of your own functions.
I agree with this one.
extern C void foo (void*);
and
void foo (void *);
are two different types.
Gé
HTH
Ulrik Petersen
Re: [sqlite] sqlite3.exe timed queries
I'd use it. On 4/26/05, Brown, Dave [EMAIL PROTECTED] wrote: Hi - I think it would be extremely handy to have an option in the sqlite3.exe program for printing the execution time of a query. Would that be hard to add? I'm thinking something like: sqlite3 .timed sqlite3 select * from mytable; value1 value2 value3 ... Total Time: 1.253 milliseconds sqlite3 What do you guys think? -Dave -- Cory Nelson http://www.int64.org
RE: [sqlite] sqlite3.exe timed queries
Thomas and Dave, Re: ...it would be extremely handy to have an option in the sqlite3.exe program for printing the execution time of a query. If you're using windows, Mike Cariotoglou has given the community a great free gui front-end, Sqlite3Explorer, that includes this feature: http://www.singular.gr/sqlite/ Donald Griggs Opinions are not necessarily those of Misys Healthcare Systems nor its board of directors.
RE: [sqlite] sqlite3_bind_text() and SQLITE_STATIC question
Thank you very much for your quick replies! But, I must admit, I am somewhat confused by the responses thus far, as I am not providing my own function pointers to sqlite3_bind_text. My intent is to provide none. My class methods are responsible for managing the buffer being provided to the bind. I'd be very happy passing NULL, but the API reference at sqlite.org and the source documentation (sqlite3.h) implies to me that if I'm not providing a destructor pointer than I am to use one of the special values. From sqlite3.h: ** If the destructor ** argument is SQLITE_STATIC, it means that the content pointer is constant ** and will never change. This best describes my implementation. sqlite3_bind_text( pStmt, col, pBuffer, lBufLen, SQLITE_STATIC ); Clearly, the C++ compiler is substituting SQLITE_STATIC with ((void(*)(void *))0), as the warning from the Solaris C++ compiler claims: Warning (Anachronism): Formal argument 5 of type extern C void(*)(void*) in call to sqlite3_bind_text(sqlite3_stmt*, int, const char*, int, extern C void(*)(void*)) is being passed void(*)(void*). Yes, it is being passed as void(*)(void*) because that's what the sqlite3 SQLITE_STATIC is #defined as... So, in short, is NULL a valid value for the parameter here, or is the use of these #defines required due to assert() statements within the vdbe such as: assert( pMem-xDel==0 || (pMem-flags MEM_Dyn)!=0 ); If NULL is the wrong way to sidestep this issue, what is typically done to placate this warning? Thanks again, -- Gerry Blanchette -Original Message- From: Gé Weijers [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 27, 2005 1:09 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] sqlite3_bind_text() and SQLITE_STATIC question Ulrik Petersen wrote: Likewise, the function that you pass should be declared 'extern C' if it's one of your own functions. I agree with this one. extern C void foo (void*); and void foo (void *); are two different types.
Re: [sqlite] sqlite3_bind_text() and SQLITE_STATIC question
Gerry Blanchette [EMAIL PROTECTED] writes: Clearly, the C++ compiler is substituting SQLITE_STATIC with ((void(*)(void *))0), as the warning from the Solaris C++ compiler claims: Warning (Anachronism): Formal argument 5 of type extern C void(*)(void*) in call to sqlite3_bind_text(sqlite3_stmt*, int, const char*, int, extern C void(*)(void*)) is being passed void(*)(void*). The warning indicates that the value expected is of type (extern C void(*)(void*)) yet the type passed as SQLITE_STATIC is (void(*)(void*)) From the looks of this warning, I would guess that you could redefine SQLITE_STATIC like this (or some variation of this that is legal C++) to solve the problem: #define SQLITE_STATIC ((extern C void(*)(void*)) 0) Derrell
[sqlite] Database corruption.
I've set up a message board database for my school using punBB as the message board system and SQLite3 as the database. Everything was working fine, then I get the following message after a few months of use Error: Unable to open database './board2.db'. SQLite reported: file is encrypted or is not a database. Does anyone know what would cause this, assuming no one messed with the database file itself and the message board software had not caused any conflict. This is the second time it's happend, the first was after a few days of use and I was able to just write a new database and start over, but after a few months there is a good deal of information on the board that needs to be retrieved. Does anyone know of a way to rebuild the database so that it works properly? Thanks for your help, the database is located at http://www.ebrats.org/site/forum/board2.db
RE: [sqlite] sqlite3_bind_text() and SQLITE_STATIC question
From the looks of this warning, I would guess that you could redefine SQLITE_STATIC like this (or some variation of this that is legal C++) to solve the problem: #define SQLITE_STATIC ((extern C void(*)(void*)) 0) I don't think there's any legal way to do this, is there? Linkage is, well, a linker issue; this is a passing-a-function-pointer issue. It doesn't seem sensible to me that you would/should be able to specify the linkage for a function as you're passing around a pointer to that function around. -Tom
Re: [sqlite] Database corruption.
Does anyone know what would cause this, assuming no one messed with the database file itself and the message board software had not caused any conflict. This is the second time it's happend, the first was after a few days of use and I was able to just write a new database and start over, but after a few months there is a good deal of information on the board that needs to be Did you test for hardware failures? retrieved. Does anyone know of a way to rebuild the database so that it works properly? Thanks for your help, the database is located at Backups are a very good thing. You learned the hard way.
Re: [sqlite] sqlite3_bind_text() and SQLITE_STATIC question
On 4/27/05, Thomas Briggs [EMAIL PROTECTED] wrote: From the looks of this warning, I would guess that you could redefine SQLITE_STATIC like this (or some variation of this that is legal C++) to solve the problem: #define SQLITE_STATIC ((extern C void(*)(void*)) 0) I don't think there's any legal way to do this, is there? Linkage is, well, a linker issue; this is a passing-a-function-pointer issue. It doesn't seem sensible to me that you would/should be able to specify the linkage for a function as you're passing around a pointer to that function around. Did you try a cast? (extern C void(*)(void*)) SQLITE_STATIC
Re: [sqlite] Database corruption.
On Wed, 2005-04-27 at 14:40 -0500, Alexander Thomason wrote: the database is located at http://www.ebrats.org/site/forum/board2.db That URL does not work for me. Are you sure that is were the database is suppose to be? -- D. Richard Hipp [EMAIL PROTECTED]
[sqlite] Windows question
Hi, I see various windows binaries available but to be honest I do not know which is which WRT what is needed to get SQLite running under windows. I ask because I have been building my own Linux releases from source and now have a need for a windows version I can send to a friend. So please help the windowless guy with some basic directions like: you only need to get this binary or that binary. I believe I can figure out where to stuff the binary when I get it but even a hint or two in that direction wouldn't go amiss. TIA -- G. Roderick Singleton [EMAIL PROTECTED] PATH tech
Re: [sqlite] Windows question
On Wed, 2005-04-27 at 16:47 -0400, G. Roderick Singleton wrote: I ask because I have been building my own Linux releases from source and now have a need for a windows version I can send to a friend. All those windows things on the website are build on Linux using mingw and gcc configured as a cross-compiler. I highly recommend that solution as it seems to work much better than trying to compile things under windows. -- D. Richard Hipp [EMAIL PROTECTED]
Re: [sqlite] Windows question
On Wed, 2005-04-27 at 16:57 -0400, D. Richard Hipp wrote: On Wed, 2005-04-27 at 16:47 -0400, G. Roderick Singleton wrote: I ask because I have been building my own Linux releases from source and now have a need for a windows version I can send to a friend. All those windows things on the website are build on Linux using mingw and gcc configured as a cross-compiler. I highly recommend that solution as it seems to work much better than trying to compile things under windows. Well I sorta guessed that. I guess what I am asking is which of the zipfiles are recommended for install and in what order. e.g. which of the beasties is the important one? Am I right in guessing sqlite-3_2_1.zip ? The rest I can figure out, I think. It's that the offerings are all similar in size so I am confused. :-( tia -- G. Roderick Singleton [EMAIL PROTECTED] PATH tech
[sqlite] sqlite 3.2.1 lock-2.8 test hangs
hi, when running the sqlite 3.2.1 regression tests, the lock-2.8 test hangs indefinitely. if i disable that test, all others pass. is this a bug in the regression test or is this something i should be concerned about? thanks, - jolan
Re: [sqlite] Windows question
Am I right ... sqlite-3_2_1.zip ? Yes, and get the same version of the dll, with or without tcl bindings, if you're going to write programs. Regards
Re: [sqlite] sqlite 3.2.1 lock-2.8 test hangs
On Wed, 2005-04-27 at 16:55 -0500, Jolan Luff wrote: hi, when running the sqlite 3.2.1 regression tests, the lock-2.8 test hangs indefinitely. if i disable that test, all others pass. is this a bug in the regression test or is this something i should be concerned about? thanks, - jolan Thanks. -- G. Roderick Singleton [EMAIL PROTECTED] PATH tech
[sqlite] attach fails with misleading error code
Using sqlite 2.8.14, I've seen attach fail with a return value of 1 (SQLITE_ERROR) but when I check the error message, it says database is locked. It seems like the return value of sqlite_exec should be 6 (SQLITE_LOCKED). Anyone know why this is? Thanks, Kevin __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[sqlite] DBD-SQLite build query
Perhaps a bit off-topic for this list, but... Being new to compilers, I have a question about building DBD-SQLite (for Perl). If I want to update the underlying SQLite code in DBD-SQLite to the current release, (v3.2.1), i sit simply a matter of putting the current SQLite sources into the DBD-SQLite-1.07 dir and rebuilding? Or is it more complicated? I did just that, and it seemed to complete successfully (on Windows, with VC++ 6.0). nmake test showed no errors. Is that it? Anybody else have experience with this? Also, I was successful in building the SQLite3 dll using VC++, but when I try to build the shell, I get a bunch of link errors about unable to resolve external references, mostly sqlite3_... calls. I know I can just download the pre-built shell (and DLL for that matter), but I'd like to know what I'm missing. Any suggestions? Thanks! -Clark
[sqlite] idxchck
how to run idxchck under windows?
