Perhaps your best general approach is to establish some form of
synchronization so that BUSYs never happen. That would simplify your logic.
JS
Ludovic Ferrandis wrote:
I'm currently writing a C wrapper (yes, I know, yet another ... ;) for my
applications. But it's a good training to learn.
So
I'm currently writing a C wrapper (yes, I know, yet another ... ;) for my
applications. But it's a good training to learn.
So I was looking at the best generic way to manage busy statement.
My first idea was to use the callback option as it seems to be much simplier
and it would benefit to all
It depends upon your application. What are you trying to do?
Ludovic Ferrandis wrote:
Thanks for your answers,
but that still don't explain me which method is the best to manage Busy
statement, to do a loop or to use a busy callback. And as I'm very curious,
especially why one method is
"Ludovic Ferrandis" <[EMAIL PROTECTED]> wrote:
> I was wondering if there was limitations for one of the 2 methods. If they
> are identicals, I know which one I will use.
>
They are essentially different interfaces to the same underlying
mechanism.
--
D. Richard Hipp <[EMAIL PROTECTED]>
I was wondering if there was limitations for one of the 2 methods. If they
are identicals, I know which one I will use.
Thanks a lot.
On 3/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> "Ludovic Ferrandis" <[EMAIL PROTECTED]> wrote:
> > Thanks for your answers,
> >
> > but that still
"Ludovic Ferrandis" <[EMAIL PROTECTED]> wrote:
> Thanks for your answers,
>
> but that still don't explain me which method is the best to manage Busy
> statement, to do a loop or to use a busy callback. And as I'm very curious,
> especially why one method is better than the other. :)
>
That is
Thanks for your answers,
but that still don't explain me which method is the best to manage Busy
statement, to do a loop or to use a busy callback. And as I'm very curious,
especially why one method is better than the other. :)
Thanks,
Ludovic
On 3/5/06, John Stanton <[EMAIL PROTECTED]> wrote:
I have a several of suggestions for that busy logic.
1. Perform a "yield()" or Win sleep(0) to give up the current
timeslice and thus have a busy wait with as little system impact
as possible but fastest turnaround. An upper limit of 100 probes
before failing as deadlocked seems to
On 3/3/06, Ludovic Ferrandis <[EMAIL PROTECTED]> wrote:
> I want to manage the SQLITE_BUSY error like this: If it fails, sleep X
> ms then try the command Y times. I found 2 ways to do it:
I do it using sqlite3_step(); Using bound variables and step eliminates the need
for escaping string data
Hi,
Newbie to SQLite, so maybe my question will seems trivial.
I want to manage the SQLITE_BUSY error like this: If it fails, sleep X
ms then try the command Y times. I found 2 ways to do it:
- First is to manage a loop like:
tryIt = X;
do
{
err = sqlite3_exec(...)
} while (err ==
10 matches
Mail list logo
