Re[2]: [sqlite] PHP 5.0.2 / Win sqlite_query problem
>> When I try to execute the same query using sqlitecc.exe it works just fine. >> DRH> This fact suggests that the problem is in PHP or the application program, DRH> not in SQLite. There can hardly be any problem with sqlite_query($db,$query) application code... Is SQLite in PHP 5.0.2 supposed to run correctly? I'm pretty sure this is not my bug... Any success stories using PHP 5.0.2 and SQLite? Anyway, will try the same code on a Linux box, maybe it will work better.. R.
Re: [sqlite] PHP 5.0.2 / Win sqlite_query problem
Radek Hulán wrote: When I try to execute the same query using sqlitecc.exe it works just fine. This fact suggests that the problem is in PHP or the application program, not in SQLite. -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
[sqlite] PHP 5.0.2 / Win sqlite_query problem
I am trying to migrate my opensource project (http://blogcms.com/) from MySQL 4.0 (mysql) and MySQL 4.1 (mysqli) to SQLite as well. Seems pretty easy with DB layer, but... when I open DB via sqlite_open() and execute few CREATE TABLE queries, via sqlite_query(), the connection is dropped and I cannot execute any other queries anymore. This is what I get (customized error message): Invalid query: CREATE INDEX membername ON nucleus_member (mname); Error: SQL logic error or missing database When I try to execute the same query using sqlitecc.exe it works just fine. Index is created. Have spend last 3 hours trying to get more than 10 tables / indexes created, but with no luck. Any hints where to look for my own / SQLite bugs? Radek
[sqlite] Table locked when trying to delete a record whilst a cursor to the table is open
Hi, Sorry I forgot to say.. I do know that the error occurs because there are read locks on the table, but is there any reason why say a single process should not be able to modify the table anyway? Or is there something in the Cursor enumeration code that would not be happy if a record was deleted after it had encountered that record. Andrew -- Andrew Clark
[sqlite] Table locked when trying to delete a record whilst a cursor to the table is open
Hi, First of all here the simple example of what i am doing would be: "SELECT id FROM test" Get first Result DELETE FROM test WHERE id=xxx Close Cursor - When i call the DELETE command I get an error of TABLE LOCKED which for those that actually know something about the source code might understand, but not being to familiar about it I am not. Now I know that some of you will reply with... "Why not call the DELETE command with just the id's that we want to delete". Well, esentially my program is not wanting to do that.. without any further debates about it could we please discuss what we could do in this situation. I read somewhere in the documentation about if a transaction fails for whatever reason then in the future the transaction will be retried after say the table has been unlocked. Does this exist yet either in Beta development or something? If not, any help with either solving this problem or telling me why it shouldn't be fixed would be of great help. As I said I am not that knowledgable about SQLite but I see the error occurs from within a call to fileBtreeDelete which itself is called from the OP_DELETE part of vdbe Could someone please tell me if this is a simple thing to solve, and even if whether it should be solved or not. I may indeed look at changing my app design to call DELETE commands directly if this cannot be resolved quickly. Thanks in advance Andrew -- Andrew Clark
[sqlite] minor typo
In the comments at the head of pager.c, there is this: ** The page cache comes up in PAGER_UNLOCK. The first time a ** sqlite3pager_get() occurs, the state transitions to PAGER_SHARED. ** After all pages have been released using sqlite_page_unref(), ** the state transitions back to PAGER_UNLOCK. The first time ** that sqlite3pager_write() is called, the state transitions to ** PAGER_RESERVED. (Note that sqlite_page_write() can only be ** called on an outstanding page which means that the pager must ** be in PAGER_SHARED before it transitions to PAGER_RESERVED.) ** The transition to PAGER_EXCLUSIVE occurs when before any changes ** are made to the database file. After an sqlite3pager_rollback() ** or sqlite_pager_commit(), the state goes back to PAGER_SHARED. There is a minor typo in the second to last sentence -- "occurs when before" doesn't make sense. b.bum
Re: [sqlite] Parameterized queries -- howto?
On Thu, October 21, 2004 7:51, Clay Dowling said: > Ron, > > Take a look at the example application in the Linux Journal article > http://www.linuxjournal.com/article.php?sid=7803 > > The parameterized queries provide a much better solution than sprintf. > You can grab a complete working app from the link at the end of the > article. > Thanks. I spent some time last night playing around with adding support for the parameterized queries to my C++ wrapper (around SQLite). It works nicely, thanks! -- My GPG public key is at http://ronware.org/ fingerprint: 8130 734C 69A3 6542 0853 CB42 3ECF 9259 AD29 415D
Re: [sqlite] Busy handlers in SQLite3
On Thu, Oct 21, 2004 at 04:36:16PM +0200, Guillaume Fougnies wrote: > Hi, > > This problem was evoked on the list. sqlite3_exec do not catch > SQLITE_BUSY on the sqlite3_step. I'm not even using sqlite3_exec, I was writing my own my_sqlite3_exec, because sqlite3_exec was not compatible with the SQLite 2.x one (it did not return the column decltypes). > If you want to continue to use the sqlite3_exec properly with busy > handler, you can copy and modify the method stored in src/legacy.c. This one works with internals of the sqlite data structure, so I can't just use it in my application code. I was forced to write my own, which only uses the high-level SQLite API functions. > I can send you my modified version if you need. Thanks for the offer, but I won't need it. I only needed to know if it was my own stupidity, or ... > It seems, to me, the only conversion problem between v2 and v3. ... another conversion problem between v2 and v3 where v3 looks like it has a compatible API, but doesn't. -- Gerhard signature.asc Description: Digital signature
Re: [sqlite] Busy handlers in SQLite3
Hi, This problem was evoked on the list. sqlite3_exec do not catch SQLITE_BUSY on the sqlite3_step. If you want to continue to use the sqlite3_exec properly with busy handler, you can copy and modify the method stored in src/legacy.c. I can send you my modified version if you need. It seems, to me, the only conversion problem between v2 and v3. Cheers, Thu, Oct 21, 2004 at 03:51:10PM +0200: Gerhard Haering wrote: > Hi, > > I'm converting SQLite2 code to SQLite3. It looks to me like the > sqlite3_busy_handler() and sqlite3_busy_timeout() don't do anything. > At least not anything useful. At least not when using the new API with > sqlite3_step() and friends. > > Is that true? Do I have to catch SQLITE_BUSY from the _step() etc. > calls myself and call an appropriate busy handler? > > All in all, I wonder why the old functions were left in the API if > they don't work properly. But maybe I've overseen something. > > Don't get me wrong: I like the new API a lot :-) > > -- Gerhard -- Guillaume FOUGNIES
[sqlite] Busy handlers in SQLite3
Hi, I'm converting SQLite2 code to SQLite3. It looks to me like the sqlite3_busy_handler() and sqlite3_busy_timeout() don't do anything. At least not anything useful. At least not when using the new API with sqlite3_step() and friends. Is that true? Do I have to catch SQLITE_BUSY from the _step() etc. calls myself and call an appropriate busy handler? All in all, I wonder why the old functions were left in the API if they don't work properly. But maybe I've overseen something. Don't get me wrong: I like the new API a lot :-) -- Gerhard signature.asc Description: Digital signature
Re: [sqlite] Parameterized queries -- howto?
Ron, Take a look at the example application in the Linux Journal article http://www.linuxjournal.com/article.php?sid=7803 The parameterized queries provide a much better solution than sprintf. You can grab a complete working app from the link at the end of the article. Clay Dowling Ron Aaron said: > Anyway, in my particular case I have several similar queries which differ > only > in a few specifics. Right now I sprintf() to a temp buffer and execute > that > buffer -- but I was hoping that I could use sqlite's dialect of SQL more > directly rather than cobbling together my query piecemeal. > > It doesn't matter a whole lot, as the sprintf() or equivalent would have > to be > done somewhere. But it makes my application much more messy looking and > bigger than it would otherwise have to be. -- Lazarus Notes from Lazarus Internet Development http://www.lazarusid.com/notes/ Articles, Reviews and Commentary on web development
