Ira Perlow re: Indexes/unable to add key to tag

[Raymond Lyons]

Ira,

Because you were kind enough to try to help with the problems I have had with "unable to add key to tag" and record locking messages, I want to respond more fully and accurately to your last message to me on the subject ( Msg ID 23714).

First, although I know Alpha 5 is not a client-server database and although I am sure you know more about all of this than I do, I am pretty sure what you said in Msg ID 23697, conflicts with what Selwyn told quite a long while ago. In part you wrote:

>>...every time a record is accessed (or a group of records), a set of file lockings and unlockings, as well as record locking and unlockings must occur on the network.

[csda1]

RE: Ira Perlow re: Indexes/unable to add key to ta

Ray,

A concurrent (in other words shared) process must always access information that can potentially change in a way that it can be sure that the information is not in a state of change when it accesses it. Otherwise, the interpretation can lead to disasterous results.

Some programs (e.g. FileMakerPro) use 1 file, but Alpha 5 uses as a minimum a DBF and CDX files (and a FPT/DBT if using memo fields) because it chose to remain with the dBase III/IV legacy format. If you use a Set, you must also include the children files too. Alpha Four had it much worse as there were multiple index files. Support files are a bit less of an issue as there are not normally in a state of change (and another key advantage to doing network optimization), but still must use a similar process to make sure two users are not writing to the support files simultaneously.

A complete explanation of this process is relatively complex and not something I am prepared to write here, but here is a rough explanation of why locks occur.

Whenever you have more than 1 file, you must use "Semaphores" to perform an "Atomic" operation. This means, in american english (UK users will have to use an American-Queen's english dictionary), this means flags to perform an indivisible operation.

To access any record, a temporary sequence of operations (taking typically milliseconds) must occur to hold up all other users from changing any of the files involved while you gain access to it. This is why file locks occur. But if you kept a file locked while you actually were simply reading the record, it would take too long for other users to get access to what they needed. Thus you apply a single record lock and then release the file lock. While you have a record lock (and the read and write cases are different), then you can safely access information for that record in all the files associated with the record that is locked. When you are done with it, you must go through a similar reverse process to release the record lock.

What Selwyn was saying, is there is no lasting lock (a record in write mode lock) until a record is placed in change mode.

Probably any index expression having a date field in your application was causing the problem (I'm not sure why, as I use date fields in numerous applications and have never seen your problem), and placing it as a calculated character field in the database, basically meant that the index expression would always access only character data. So that explains why the problem went away, but not why the problem is there in the 1st place. I'm sure it's buried someplace in your methodology, but I also think it would be difficult to track it down too (as most multi-user issues are).

Using a range is basically OK (and I use it a fair bit), but if your filter expression does not really change, you would be better served by moving portions of the filter to the index expression, e.g.

STR(statuscode,1)+STATE+...

Then you could set the range to being from "1" to "1z" (as an example). You could also do things like;

IF(statuscode=2,"0","1")+STATE+... and set the range from "0" to "0z"

The point is that clever index expressions can group data the way that it is best needed, particularlly for specific ranges.

Your range problems may be solvable, I don't have enough info to be sure, but may be the following;

The blank records may be a refresh issue that can be solved with xbasic refreshes/resynch.

Detecting a Fetch beyond the end-of-file and beginning-of-file may be your other problem. These can be detected by storing the current record number, doing a fetch, and seeing if it has changed. You could also do a Fetch first and/or last to force a refresh if needed.

Rather than writing a "2", I would write the user's name into a field indicating he is using it, and blank it when done. This tells you who has control of it.

You could also potentially use error checking in XBASIC to see if you can open a record in change mode. If not, move to the next record. This would save the problem of having to do 2 saves per record.

I hope this helps you some. I've tried to address most of your issues, but let me know if I missed something.


Regards,

Ira J. Perlow
Computer Systems Design & Associates
[email protected]

[Raymond Lyons]

RE: Ira Perlow re: Indexes/unable to add key to ta

Ira,

I was initially doing some filtering via an index but thinking that might be the source of my problems I did away with the complex filtering index.

You have given me food for thought. Now if only I had a user to continue my testing. I still have some hope of that happening or I wouldn't still be interested in this problem at all.

Thanks again.

Ray