How does CodeBase (Sequiter) make locks?

Posted on 2004-04-27
Last Modified: 2007-12-19
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.
Question by:beaverstone
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 4
  • 3

Accepted Solution

rherguth earned 500 total points
ID: 10932471
>> 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.


Author Comment

ID: 10933403
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.


Expert Comment

ID: 10934081
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?

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!


Expert Comment

ID: 10934097
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.

Author Comment

ID: 10934318
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.

Expert Comment

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


Author Comment

ID: 10952978
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.

Featured Post

Will your db performance match your db growth?

In Percona’s white paper “Performance at Scale: Keeping Your Database on Its Toes,” we take a high-level approach to what you need to think about when planning for database scalability.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

When table data gets too large to manage or queries take too long to execute the solution is often to buy bigger hardware or assign more CPUs and memory resources to the machine to solve the problem. However, the best, cheapest and most effective so…
This post looks at MongoDB and MySQL, and covers high-level MongoDB strengths, weaknesses, features, and uses from the perspective of an SQL user.
Video by: Steve
Using examples as well as descriptions, step through each of the common simple join types, explaining differences in syntax, differences in expected outputs and showing how the queries run along with the actual outputs based upon a simple set of dem…
Polish reports in Access so they look terrific. Take yourself to another level. Equations, Back Color, Alternate Back Color. Write easy VBA Code. Tighten space to use less pages. Launch report from a menu, considering criteria only when it is filled…

690 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question