What do you mean by "are supposed to check"?

There's no way to tell whether a lock is already held, although in most cases no locks are held upon return of the thread to the client application.  "User" locks can be requested through the DDA API which will persist only until the next write is posted (by calling Post()), and then I believe are automatically released so that you don't accidentally hold a lock you've forgotten about.  There should be no need to use "user" locks when using SQL commands, but they are provided for potential use when performing DDA operations.

A lock timeout (VistaDB.Diagnostic.Errors.dda_LockTimeout = 163) is supposed to be a retryable error, meaning that the exception can be caught and the query or operation can be reissued (either automatically after some delay or with user input).  This may be particularly important when opening a connection using Nonexclusive* modes because timeouts in that case are most likely caused by transitory locks on the [database schema] table.

To check for a timeout error, catch (VistaDBException ex) and check the ex.ErrorId value and optionally also test ex.Contains(Errors.dda_LockTimeout) (Contains does not test the top-level ErrorId, so you have to check ex.ErrorId explicitly.)