Dmitry Yemanov wrote:

> "Geoff Worboys" <geoff@...> wrote:
>>
>> Is there something I can do here to capture more information
>> when the server aborts?

> Download the PDB archive, put .pdb files next to the server
> binaries, activate Dr.Watson and reproduce the failure. Then
> send the generated crash log to me.

I am starting to feel really silly. I cant get Dr.Watson to
pickup when fbserver fails.

I did a "drwtsn32.exe -i" be sure it was the default debugger.
I am running fbserver as an application (rather than as a
service). And I can get it to fail, but Dr.Watson seems to
be ignoring it.

I even tried to get Dr.Watson to connect directly to the
PID of fbserver. It found it, and brought it crashing down
without waiting for me to do anything. :-(


More info...

The problem happens most reliably when DBak first needs to
drop an existing database (the new/destination database, not
the one where the metadata is coming from). The problem does
not seem to happen as reliably if I manually delete that
database first.

While this dropping is going on the connection to the source
database is active (but no activity occurs on that connection).
After dropping the old database DBak proceeds to read the
metadata from the source - not creating the new database until
it has all the metadata it wants from the source.

Being a totally separate database it should have no bearing
on the issue - but it seems to.

I tried various isql scripts etc to reproduced the problem
using this knowledge (creating and dropping a dummy db) but
could not reproduce the problem.


I am not sure where to go from here.

--
Geoff Worboys
Telesis Computing