Subject | Re: invalid SEND request (167) |
---|---|
Author | gstegehuis |
Post date | 2006-10-23T10:23:48Z |
Thanks Helen,
At least one thing is clear now. I thought the SEND-message was the
problem, and that afterwards the file was locked, but is it seems it
is only a symptom, the file was already locked when this message was
returned. I did not find a cause yet, I will try to find one.
Gerrit
At least one thing is clear now. I thought the SEND-message was the
problem, and that afterwards the file was locked, but is it seems it
is only a symptom, the file was already locked when this message was
returned. I did not find a cause yet, I will try to find one.
Gerrit
--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>
> At 11:43 AM 20/10/2006, you wrote:
> >no insult was intended,
> >
> >I have learned everything I know about Firebird from this newsgroup,
> >and the excellent Firebird book.
> >
> >I mentioned my situation because my symptoms also included:
> >
> > > >After that all accesses to the database fail, because the database
> > > file 'is locked by another process'.
> >
> >This seemed to be caused by the bugcheck and no other extraneous
source.
>
> Actually, when you see the "software inconsistency" message it's not
> a BUGCHECK unless the message says it is. This message occurs
> whenever the engine finds itself in a state where it can't do what
> it's been asked to...in Gerrit's case (and yours, I think) it has a
> SEND request that it can't act upon. It's only trying to help us
> find out what occurred to cause that condition. So "the problem"
> here is (apparently) extraneous (file is locked by another process:
> the engine can't do anything about that!) and the halt occurs as a
> result of the consequent condition that the engine finds itself in.
>
> This situation does come up with WinXP SP2 from time to time. Nessus
> is a known "offender", along with possibly other security and
> filesystem utilities that are apparently allowed to override
> Superserver's exclusive write lock on the database file. Configuring
> such utilities to bypass your database files usually fixes the
> problem, if indeed the problem is caused by such a utility.
>
> All that said, it doesn't mean that software inconsistencies arise
> *only* from extraneous causes; nor even that encountering *this one*
> with Superserver on XPSP2 is always caused by the same, single
> thing. It does, nevertheless, provide places in the operating
> environment to look for possible causes and eliminate them.
>
> ./heLen
>