|
Aaron:
You
are correct. This is a bug in the GX. The db.gxh file specifically notes that
DupSymb_DB puts a READWRITE lock on the new channel.
The
fix is to use the DupSymbNoLock_DB function instead. This will be fixed for
5.1.4.
_______________
Geosoft Inc.
Stephen
Cheesman
[EMAIL PROTECTED]
(905) 315-8207
Software and
services for effective earth science decision-making.
Free Oasis montaj
interface now available at http://www.geosoft.com
Hi everyone,
If I'm just repeating something that had already
been gone over in GXNET, my apologies. I've discovered that if you run
NLFILT.GX under certain circumstances and you have the "report all errors"
setting on. The conditions in which the error message osccurs is: say you want
to perform a nlfilt on CHAN1 and put the results in CHAN2, and CHAN2 does not
yet exist in the database. This gives an error message that the GX has left 1
lock on a line/channel handle in the database. This does not have any effect
on the actual operation of the GX.
I tracked down and fixed the problem but I just
want to confirm the reason why the error message occured. My conclusion was
that if CHAN2 does not yet exist, The OutCH handle(CHAN2) is created with the
DUPSYMB command. I came to the conclusion that the DUPSYMB command Locks the
symbol. OutCh seems to be locked a second time. OutCh is subsequently
Unlocked, but this still leaves the original lock from the DupSymb command.
Hence, the GX terminates with one lock still on.
Can anyone tell me if my thinking here is
correct?
Aaron Balasch
Sky Hunter Technologies
Inc.
Suite 101, 1725 10th Avenue S.W.
Calgary, Alberta T3C 0K1
email:
[EMAIL PROTECTED]
phone:
403-228-2175
fax: 403-244-7955
|
