--- 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?

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.

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