> > gizu tseng <gizu.ts...@gmail.com> wrote: > > I am porting my Java applications from Oracle Lite to SQLite and > > getting those error message: "SQLite only supports TYPE_FORWARD_ONLY > > cursors". > > I'd like to know if there is any (updated) SQLite JDBC driver that > > supports the TYPE_SCROLL_INSENSITIVE cursors?
Igor Tandetnik <itandet...@mvps.org> replied: > I doubt it. This is not a limitation of the drivers, but of SQLite itself. > The only operation it supports on its equivalent of a cursor is "advance to > next row". SQLite does not actually have cursors. Your program can emulate a cursor but the database engine will not help you much with that. If you have SQLite in WAL and ran all your cursor emulation queries inside a single transaction, you would have cursor stability (that is, database changes on other connections would not be visible to your cursor operations running inside a single WAL transaction). Without WAL, subsequent queries would see the database "as modified" and return results based on the database at the time the query was executed. Many databases emulate cursors entirely on the client side (in the "driver" as it were). Some databases provide cursor support on the server-side through temporary keyset or result tables. Since SQLite does not actually have cursors (it has statements, which generate a step by step result set) you would have to emulate a cursor entirely within your application. If your goal is to be able to emulate "cursor stability" (ie, a stable view of the database across multiple queries -- keeping in mind that SQLite does not actually have cursors) where you can run multiple queries that see the same database view irrespective of updates taking place on other connections, then you can use WAL. When you BEGIN a wal transaction which contains only queries, you will get a stable view of the database until you commit (or rollback) that transaction. Note that the default is to have "automatic transactions" around select statements, so the default is that each SELECT statement is itself stable. To extend that across multiple selects on a connection, they must all occur within a single transaction. That is, if all you do is selects, you can thing of BEGIN as meaning "begin select stability" and COMMIT as "end select stability" ... http://www.sqlite.org/wal.html --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
