How does CodeBase (Sequiter) make locks?

I am using CodeBase - package of program from Sequiter Software, Inc to manage
dB and FoxPro database tables.

They provide C-source code for this package, but I don't have time to read it.
Does anyone knows the principal method CodeBase (CB) uses to lock record or
an entire table (table is a file, usually with extension .dbf).

Details are:

 In our Microsoft Windows network, users use
 CodeBase 6.3, Stand-alone(no client-server achitecture).
 They have common database files on single network computer.
 In other words, this network computer and files, (.dbf, fpt, cdx)
 are shared between users.
 All applications written in Microsoft Visual Basic and use C4fox.dll
 All questions below asked for this architecture.

Quesion precisely:

   What is a principal mechanism to lock record and lock database file?
   Does CB writes an additional file next to database file and this
   additional file contains number (reference) of the locked record or marker for
   locked file? When record is unlocked, this number is removed, is this correct?

(I never noticed any extra files in Windows Explorer though, perhaps changes go too fast?)

Thank you.
Who is Participating?
rherguthConnect With a Mentor Commented:
>> What is a principal mechanism to lock record and lock database file?

Records are locked at the row level rather than using a page locking scheme.  When an insert, update, or delete is attempted, the record is locked automatically.  The DBF files can also become locked if they are opened exclusively by the developer or when an append is done to the table (DBF).  To avoid table locking using these file types, it is best to have a certain number of blank appended and deleted rows at the end of the table and develop a scheme to check for and resuse deleted rows before issuing an APPEND or SQL INSERT (same effect). The most concurrent multi-user apps written to DBFs typically employ a semphore locking scheme for master tables to avoid physcial row locks and instead use a lock table that the application refers to when determining which rows are in use.

>>Does CB writes an additional file next to database file and this additional file contains number (reference) of the locked record or marker for locked file?

This sounds like the semaphore locking that I was talking about above.  It is up to the developer to implement it, and to my CodeBase v5.0 recollection, which was many years ago, it was still up to the developer to implement their own scheme for record locking beyond the basic built-in row locking for insert/append, update, and delete.

>> When record is unlocked, this number is removed, is this correct?

If the developer implement a semaphore file, that is how it would work, but if you don't see the semaphore files or a table while the app is running, it probably doesn't use them.

beaverstoneAuthor Commented:
Thank you very much rherguth for the great programming tips.
They make me more certain that I am guessing a right method.

However, they don't answer the question, but explain in general how lock works.
There is no doubt that CodeBase 6.3 does a lock of a group of records, files and/or append bytes.
I am a VB-developer, and don't implement any lock mechanism, but using this
mechanism by means of functions like code4lock from from CB C-package.
Let me to repeat the question crudely (precise definition is in the original text):

  does CB write file to operating system to place into this file information for
  applications from another computers about locked records and files?

(Actually, I cannot imagine another alternative, but who knows?
It seems, CodeBase went ahead since version 5.0. But their tech. support is costly now.)

Thank you.

Ah.  The answer is not that I know of.  :)

The file will have a generic R/W OS lock on it, however, the only way for another app to know which records are locked is to read the DBF header in the case of a file lock or to read the first byte of the row to check for a record lock.  So only apps that understanding DBF record locking will know which records are locked.

Am I getting closer to an answer?

Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

One other note is that if Foxpro locks a record, Clipper, CodeBase or whatever may not know that it's locked.  The application itself determines how records are locked and can support different types of locks.  For instance dBase III+ may only support exclusive row locks whereas Visual FoxPro may support a non-excludive shared row lock.  The way indexes and memo fields are locked is similar.
beaverstoneAuthor Commented:
Thank you very much rtherguth.

I don't believe that there is a place in DBF file header where
Application will put lock marker. Possibly this are positions
(16-28) "Use of dBaseIV multi-user environment" (counting from 1).

And, "first byte of the row", first character of the record, is "record-deleted",
marker not lock marker.

Thank you.
It looks like byte range locks are used for rows, however, just the file header is locked when the table is locked.

beaverstoneAuthor Commented:
This question is not answered.
However I am accepting the

 Comment from rherguth
 Date: 04/27/2004 12:49PM PDT

to reward the work which gave me some ideas.

Thank you rherguth.

Knowledge about CodeBase can be extracted from supplied source code,
and it seems that I have to do this work myself.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.