We've had an issue with the locking of the File definition record in
the md. The lock is a group lock, not an item lock. The lock occurs
between the ODBC connection and a local user - on the dictionary entry
(NOT records).

The search program OPENs the file, then does a READ while traversing
the file. The program appears to lock up on the OPEN statement. This
file is constantly being searched by many users.

This file is only updated from an ODBC connection from Goldmine/Access.
I do have a CALLX trigger on the file to update other files when a
change occurs. The trigger program is straightforward and should
execute very quickly - with provisions for locked records.

It appears that the ODBC connection is maintaining the lock on the
dictionary of the file - and not releasing it. Normally you never see
the lock on the dictionary.

Does an OPEN temporarily lock the dictionary of the file? Does ODBC
lock the dictionary for some reason?

D3/Linux 7.2.1
ODBC C27

For a workaround, I created a duplicate (I don't like duplicating
data...) file that the CALLX trigger updates. The search program now
uses that file.

How are you making the connection?

ODBC doesn't normally lock anything because they never know how long
anything is going to take.

Also, ODBC via SQL uses the SQL TABLES file to locate the data file and then
opens it via full path (act,dictname,filename) and so wouldn't neccessarily
lock the master dictionary of the target account for anything.

Mark Brown

"DaveG" <daveg_0205 (AT) iwon (DOT) com> wrote

Dave,

We are only using ODBC for UPS Worldship and FedEx. We had a number of
problems trying to directly update sales orders with the freight
information. So we created a temporary shipping file and have ODBC simply
writing the information to that file. Then we have a phantom process that
wakes up every 5 minutes, selects the file, and updates the appropriate
records. No mess, no worries, no locks. Something to think about.

Jeff

"DaveG" <daveg_0205 (AT) iwon (DOT) com> wrote