At 23:04 24/09/2008, you wrote:

>--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>>
>> At 12:52 24/09/2008, you wrote:
>> >I have two similar DBs. If I process one (attach, select, update,
>> >detach), exit the app, restart, then process the second, everything
>> >works fine. If I try to process both DBs without exiting and
>> >restarting, the app hangs in isc_dsql_execute() when attempting the
>> >update on the second DB (the selects on the second DB work fine). The
>> >call stack is
>> >
>> >NTDLL! 7c90eb94()
>> >KERNEL32! 7c80a075()
>> >FBCLIENT! 015165d1()
>> >ff006aec()
>> >
>> >which to me is not very helpful. Is there something I should (or
>> >shouldn't) be doing in this situation?
>>
>> If you tell us what the application is trying to do involving
>simultaneous connections to two databases, perhaps someone can answer
>that question for you.
>
>Sorry I wasn't more clear. I'm not attempting simultaneous
>connections. The order of operations is this:
>
>attach DB 1
>select
>detach DB 1
>attach DB 1
>select
>select
>update
>detach DB 1
>attach DB 2
>select
>detach DB 2
>attach DB 2
>select
>select
>update
><hang>
>
>If I exit the app between the "detach DB 1" and "attach DB 2", then
>restart, everything works fine. Apparently, after the "detach DB 1"
>step either I haven't correctly detached from DB 1, or I'm not
>properly reinitializing something before the "attach DB 2". So far, I
>haven't been able to figure out what that might be. Just before the
>hang, all the parameters to isc_dsql_execute appear to be correct. In
>fact, they appear to be identical in both scenarios.
>
>As far as I can tell, there are no open transactions when the hang
>occurs. isc_start_transaction is called with this TPB:
>
> static char transParamBuf[] =
> {
> isc_tpb_version3, // Version, always 3
> isc_tpb_write, // Read-write access
> isc_tpb_concurrency, // Concurrency-mode transaction
> isc_tpb_read_committed, // High throughput, high concurrency transaction
> isc_tpb_wait // Wait on lock
> };
>
>The "wait on lock" looks suspicious, but where could a lock be held
>except in another transaction?

Well, at least one has to wonder why a wait transaction is used in a single-user scenario....but I'd be more dubious about a TPB that tries to start with two isolation levels!!

>After the hang, gfix reports no problems with DB 2.
>
>
>> >Is there any mechanism within FB that will help me track the problem?
>>
>> Well, it very much depends on what's causing the problem. Have you
>looked at the firebird.log at all?
>
>I have. There are several scattered around my system, but none with
>any entries newer than February 2008. Here's one of them:
>
>
>ACAPPELLA (Server) Sun May 20 14:40:39 2007
> Database: C:\BURMAIR\SYSTEM\FACET\FACET.FDB
> internal gds software consistency check (can't find shared latch
>(300), file: cch.cpp line: 3640)
>
>
>HARMONY (Server) Fri Feb 08 10:12:39 2008
> WNET/wnet_error: CreateFile errno = 2
>
>
>HARMONY (Server) Fri Feb 08 10:12:39 2008
> WNET/wnet_error: CreateFile errno = 2
>
>In the folder where current work is being performed, there is no log
>file, which I assume means recent operations have not produced any
>loggable errors.

Have a look in the system32 folder.

>I'm using the embedded server, if that makes any difference.

It does...you have a server and a client there, not just a client. But if this "hangs" on a write operation, you might suspect a "deadly embrace", where one wait transaction is waiting for another wait transaction which is waiting for the first one - they will wait for each other for ever.

It might be a byway of some bug in 2.0.3, too. Since it is embedded, it should be no drama to grab 2.0.4 and see whether you get the same behaviour.

./heLen