>So, what IS your question???
>

Q: What is wrong with this code?

Here are some answers I have recieved:


Depending on the settings of SET EXACT and SET ANSI this function fails if there are entries in the table like "table.kTest" and "table.kTest2". This is especially important, as cKeyCtr must not match the field name, but can be any other value. That might happen, when the ID field is renamed, but it can happen in other situations, as well. Fixed with padr()

Also, CREATE TABLE would always add the table to the current database. But the counter table should be a free table, otherwise a transaction would block any other station from adding a new record to one table, if another added one record during the transaction to the same table. Fixed with free.

kKeyCtr needs a candidate index, otherwise two stations might add the same record for new tables with the code>INSERT command, especially, because the new record is not immediately visible to all stations. Fixed with unique.

Error handling is needed to cover update conflicts, especially on the INSERT line. See below.

In this code, the key table is opened automatically by the first SELECT statement. This might open the table in buffering mode in the development environment. CURSORSETPROP is needed to disable buffering, but only if no transaction is open.

Variables are not using the "m." prefix. If there happens to be an active table with the same field names as local variables, these values are used instead, with all kind of strange results. Fixed. Array names take precedence over field names, therefore don't have to be prefixed, and in some cases can't even be prefixed. (It causes the update command to fail. See VFPUndocumentedBugs)

But beside this, it's really an interesting solution. :)


Errors and exceptions:

Heavy contention keeps a process tied up indefinitely (problem A). If the demand on KeyCtr? is that high, I am going to assume that the demand on the table where the keys are being used as a PrimaryKey is also high (problem B). I think that problem B will become significant first. The solution to problem B will also take care of problem A before it becomes significant. I would hope that someone doesn't upsize "the table" but not KeyCtr?.

KeyCtr?.dbf does not exist or is corrupt. Environment is hosed, best to bring in professional help and not have the program try and fix it automatically.

KeyCtr?.dbf is locked exclusively. Environment is hostel. Whoever is responsible can deal with it.

If this will surface under typical (worse than ideal but not extreme) environments, I will leave it up to the developer of a hostel environment to make the necessary enhancements. Don't let this stop anyone from commenting on potential problems. If it can be addresses without polluting things, good. If not, it will be an interesting topic for discussion (assuming it is based on facts, not religion).