Delphi - How to test if a Table is locked?

I'm trying to get to grips with how to overhaul some Delphi code to become multi-user.
The program has a sequence of forms that need to be posted to a Paradox Table controlled by the BDE.
In essence I want to check if the table is locked and if not lock the table or record and then post and then remove my locks.

The Borland BDE API examples seem to be working with grids and rely on working out where the cursor is.
They don't appear to be appropriate and do I need anything that complex.

I have three issues that I will separate out into distinct EE questions.

How do I see if the table is locked?

If I use the crude code below I can get the BDE intercepting it first telling me that the table is locked by another user.
Also it always gives me the same answer. I am forcing the table into Edit mode to notionally lock it.

Who is Participating?

Entering an Edit state will place a Record lock on the cursor (to be explained in a sec), not a full table lock. Note, it is generally in bad taste to lock the table unless you plan on performing some maintenance and need exclusive access to the table. What you originally posted:

translates into a record lock check, which I provided, but without entering an edit state and testing for an exception.

function IsRecordLocked(DataSet: TBDEDataSet): LongBool;
begin

// Check for active dataset
if DataSet.Active then
begin
// Check if record is locked, if an error occurs return false
if (Bde.DbiIsRecordLocked(DataSet.Handle, result) <> 0) then result:=False;
end
else
// Not active
result:=False;

end;

Regarding the BDE usage of "cursors", that is what the Handle property is on a BDE dataset decendant. It is an hDBICur handle. Please note, that a cursor (in DB related terms), is an open connection to a record set (table/sql statement/etc), where there is a notion of a current location which is the current record (if not BOF/EOF). To adjust the cursors location, one uses Dataset.First/Prev/Next/Last etc. To check for cursor "edges", one tests for DataSet.BOF/EOF. You get the point.... all those calls are cursor related.

As to the grid question/comment; the cursor has absolutely NOTHING to do with any controls, grid or otherwise. The cursor still has a current location, regardless of being bound to a control or not. Think of data bound controls as nothing more than a UI reflection of the cursors state (eg, active record, field values, cursor location, etc).

As to the question "How does it know which record to lock?"; It tests/locks the current record for the cursor, just like calls to DataSet.Edit/Delete/etc operate on the current record for the cursor.

When working with BDE, you will find that this is a little cleaner as you don't have to enter/exit the edit state (you only test the state). The plus side is that you get to handle the errors without raising/trapping an exception to do it.

Requires DB, DBTable, BDE in the uses clause.

function IsRecordLocked(DataSet: TBDEDataSet): LongBool;
begin

// Check for active dataset
if DataSet.Active then
begin
// Check if record is locked, if an error occurs return false
if (Bde.DbiIsRecordLocked(DataSet.Handle, result) <> 0) then result:=False;
end
else
// Not active
result:=False;

Russell - if I use the function GetTableLockCount(DataSet: TBDEDataSet): I'm always getting a a result of 0 even after I have put the table inot "edit" state - from what I have read on EE previously that should lock the table?

I was trying to lock it anotherwas but looking at the BDE calls like the one to release the TableLocks they almost always mention a cursor which throws me. I'm not using a grid so the concept of the cursor is superfluos. Can you elaborate?