> In my last post I mentioned that I updated my programs so that I can
> execute an arbitrary query or update, thus eliminating the need to use
> the sqlite command line utility. There really is only one program
> accessing the database now.
Sorry, I've missed this detail. In this case you are saf
>> I am not using BEGIN IMMEDIATE, just BEGIN, but I don't think it is a
>> problem in my case, since now there really is just one program
accessing
>> the database.
>
>Did you forget the message this thread was started from? The sqlite3
>command line utility is a second program, so this could be a
> I'm running on SCO OpenServer so I'm not
sure your product would work for me but I'll take a look
StepSqlite compiler's Linux target generates shared objects (.so) that
should work on virtually all Unix-like systems thanks to ELF format.
As an aside, further in SQLite exploration you may find i
> I am not using BEGIN IMMEDIATE, just BEGIN, but I don't think it is a
> problem in my case, since now there really is just one program accessing
> the database.
Did you forget the message this thread was started from? The sqlite3
command line utility is a second program, so this could be a probl
Thank you all for your responses. This discussion has grown a lot more
than I thought it would.
Like I said in my original question, my system is made up of several
programs that communicate by sending messages to each other. I have a
utility program that can send messages to the programs for testi
Hi Shawn,
> demonstrate SQLite best
> practices, including how to correctly handle error conditions, such as
> the database is locked condition?
> If you pre-select and then modify, you have to be aware enough to
> realize you MUST wrap the whole process in a manual transaction,
> and you s
On Tue, Jun 15, 2010 at 04:36:15PM +0100, Simon Slavin scratched on the wall:
>
> On 15 Jun 2010, at 4:23pm, Robert Latest wrote:
>
> > Instinctively I'd rather first SELECT, store the
> > results, finalize the SELECT statement and then get to work on its
> > result using the stored data. It's ju
On 15 Jun 2010, at 4:23pm, Robert Latest wrote:
> Instinctively I'd rather first SELECT, store the
> results, finalize the SELECT statement and then get to work on its
> result using the stored data. It's just that without intermediate
> storage it's a bit easier (no need to do any ressource mana
Hello all,
> Oh, I completely forgot that people can do that. So, Robert, you case
> is exactly the case I was talking about. As Simon said your SELECT
> opens read-only transaction and then as you issue your first UPDATE
> this transaction have to be converted to writing one. This is a call
> for
>> Do you mean you're making changes as you call SQLite to _step() through the
>> results of the SELECT ? Or do you read all the results of the SELECT into
>> memory, then make changes to the database ?
>
> The former.
Oh, I completely forgot that people can do that. So, Robert, you case
is exact
On 14 Jun 2010, at 3:43pm, Robert Latest wrote:
> On Mon, Jun 14, 2010 at 4:36 PM, Simon Slavin wrote:
>
>> Do you mean you're making changes as you call SQLite to _step() through the
>> results of the SELECT ? Or do you read all the results of the SELECT into
>> memory, then make changes to t
On Mon, Jun 14, 2010 at 09:42:09AM -0400, Pavel Ivanov scratched on the wall:
> > This is interesting. I often have situations where I SELECT something
> > and then do manipulations (INSERT/DELETE/UPDATE) on the db as I
> > iterate through the results.
> >
> > Is this what you mean by your statemen
On Mon, Jun 14, 2010 at 4:36 PM, Simon Slavin wrote:
> Do you mean you're making changes as you call SQLite to _step() through the
> results of the SELECT ? Or do you read all the results of the SELECT into
> memory, then make changes to the database ?
The former.
robert
___
On 14 Jun 2010, at 1:44pm, Robert Latest wrote:
> This is interesting. I often have situations where I SELECT something
> and then do manipulations (INSERT/DELETE/UPDATE) on the db as I
> iterate through the results.
Do you mean you're making changes as you call SQLite to _step() through the
re
Thanks, your and Pavel's clarifications have been very helpful.
robert
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
On Mon, Jun 14, 2010 at 02:44:02PM +0200, Robert Latest scratched on the wall:
> On Fri, Jun 11, 2010 at 5:26 PM, Pavel Ivanov wrote:
>
> > 1. Ensure that you have no transactions started with SELECT and
> > continued with INSERT/DELETE/UPDATE
>
> This is interesting. I often have situations whe
> This is interesting. I often have situations where I SELECT something
> and then do manipulations (INSERT/DELETE/UPDATE) on the db as I
> iterate through the results.
>
> Is this what you mean by your statement? If yes, how should such
> situations be avoided, and why?
If you issue BEGIN stateme
On Fri, Jun 11, 2010 at 5:26 PM, Pavel Ivanov wrote:
> 1. Ensure that you have no transactions started with SELECT and
> continued with INSERT/DELETE/UPDATE
This is interesting. I often have situations where I SELECT something
and then do manipulations (INSERT/DELETE/UPDATE) on the db as I
itera
On 11 Jun 2010, at 4:33pm, Jay A. Kreibich wrote:
> For what it is worth, "Using SQLite" has four or five pages
> specifically dealing with SQLITE_BUSY errors-- both how to avoid them
> and how to correctly handle them.
Well, that somewhat increased the chances that I'll check out that book.
On Fri, Jun 11, 2010 at 04:04:59PM +0100, Simon Slavin scratched on the wall:
>
> On 11 Jun 2010, at 2:50pm, Odekirk, Shawn wrote:
>
> > Also, are there any code examples that demonstrate SQLite best
> > practices, including how to correctly handle error conditions, such as
> > the database is lo
>> Also, are there any code examples that demonstrate SQLite best
>> practices, including how to correctly handle error conditions, such as
>> the database is locked condition? I have been unable to find complete
>> code examples.
>
> Can I point out that this is yet another person asking for the s
On 11 Jun 2010, at 2:50pm, Odekirk, Shawn wrote:
> Also, are there any code examples that demonstrate SQLite best
> practices, including how to correctly handle error conditions, such as
> the database is locked condition? I have been unable to find complete
> code examples.
Can I point out that
I have recently upgraded an old system that managed its data in a
dynamically allocated linked list to use SQLite instead. I have been
extremely pleased with SQLite. Most operations have been greatly
simplified and I am much more confident in the stability of the system
and the integrity of the dat
23 matches
Mail list logo