Re: [sqlite] interrupting sqlite3_prepare_v2

I have investigated futher and noticed that it will break when preparing statements like creating tables from a select. I filed a bugreport with example code at: http://www.sqlite.org/cvstrac/tktview?tn=3155 Dennis Cote wrote: Daniel Önnerby wrote: Sometimes this interrupt occur in the

[sqlite] quoted .import

Hi Is there a way to get .import lt;filenamegt; lt;tablegt; to process quoted columns? aka if .separator , then any quoted column with hello, world will break it. I do not control the exports which are daily derived dumps from mysql and db2 databases. I did a test with unquoted export with

Re: [sqlite] SQLite Analyzer OSX

Am 02.06.2008 um 07:17 schrieb Bruce Robertson: I see that SQLite3 Analyzer for OSX is listed on the download page but no instructions are provided and when unzipped it does nothing. What are we supposed to do with this? Hmmh - I downloaded and unzipped the archive and launched the

Re: [sqlite] Corrupted sqlite_sequence table

Were you able to successfully reproduce the corruption using the scripts and databases I sent? We're having a lot more trouble with this problem and our earlier workaround is proving troublesome in some situations. Thanks, Sam On Wed, May 28, 2008 at 7:25 PM, D. Richard Hipp [EMAIL

Re: [sqlite] reading a row that has been deleted

Hi Keith, Your observation is correct. I did not know that when selecting a table a shared lock is aquired by the reader and writes are locked out until the last row is read or stmt is finialized. This is true even for in-memory database. One cure for this problem is to create a temorary

Re: [sqlite] reading a row that has been deleted

On Mon, Jun 2, 2008 at 8:12 AM, Alex Katebi [EMAIL PROTECTED] wrote: Hi Keith, Your observation is correct. I did not know that when selecting a table a shared lock is aquired by the reader and writes are locked out until the last row is read or stmt is finialized. This is true even for

Re: [sqlite] Corrupted sqlite_sequence table

Samuel Neff wrote: Were you able to successfully reproduce the corruption using the scripts and databases I sent? We're having a lot more trouble with this problem and our earlier workaround is proving troublesome in some situations. I think it has been fixed. See

Re: [sqlite] Corrupted sqlite_sequence table

great, thanks! On Mon, Jun 2, 2008 at 11:55 AM, Dennis Cote [EMAIL PROTECTED] wrote: Samuel Neff wrote: Were you able to successfully reproduce the corruption using the scripts and databases I sent? We're having a lot more trouble with this problem and our earlier workaround is proving

Re: [sqlite] reading a row that has been deleted

Keith, For normal operations the writer will wait until the reading is done. But I have a client that is remote and is very slow and could sit on a select statement indefinitly. In this case I would need to create a temp table. Thanks, -Alex On Mon, Jun 2, 2008 at 11:53 AM, Keith Goodman

Re: [sqlite] transaction recovery question

Simple enough to test... just open two sqlite sessions and try it... Process B will recover the database when the transaction begins. Are you having an issue with sqlite doing something different? HTH Robert Lehr [EMAIL PROTECTED] wrote: I have a question about recovering from a transaction

Re: [sqlite] transaction recovery question

Robert Lehr [EMAIL PROTECTED] wrote: I have a question about recovering from a transaction that was not completed by a process b/c it terminated abnormally, e.g., careless SIGKILL or segfault. The scenario involves multiple processes having the database open. * process A opens the database

[sqlite] Sqlite on RAM

Hello.- How many db's can i have on RAM? Thanks -- Ing. Hildemaro Carrasquel Ingeniero de Proyectos Cel.: 04164388917/04121832139 ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite3 file format

Well, is there any way to determine, from an sqlite database file, the exact dot dot version of sqlite3 which produced the file? A quick hack is OK since I don't need to do this in production, just troubleshoot a possible forward-compatibility issue with a remote user. I see that the first