> 1. lock tables configuration_settings write;
> 2. update configuration_settings set Value=Value+1
> where Category = 'ControlNumbers' and Item = 'LastPONumber';
> 3. select Value from configuraton_settings
> where Category = 'ControlNumbers' and Item = 'LastPONumber';
> /* Use Value as your PO number */
> 4. unlock tables;

> If User A is in query 2 or 3, User B will wait at query 1 until User A
> finishes query 4.

Thanks. That is more along the lines I was thinking, but I was not too happy
about a table-level locking since the table is accessed very heavily by many
users. In real life I don't think it would be a problem, though, since it
is only a write lock and only for a split second at a time.

> There's a lot of utility in a Keyword = Value approach. For instance,
> for an address book application, you might have a table: PersonID,
> Attribute, and Value. Attribute might be things like 'First Name',
> 'Birth Date', 'Home Fax Number', 'Work Email', 'Home Street Address',
> etc. You can add more without having to change the schema.
> The trouble is, what type is Value? It's got dates, names,
> telephone numbers, email addresses, etc. in it.

I find the approach quite flexible for my purposes, since a text field can
store most any type of data. The job of ensuring proper format of dates,
numbers, etc. lie with the business objects of my apps.

> You also end up doing a lot of joins to get specific attributes
> (if present) in specific variables.
Out of curiosity, could you elaborate on this?

Thanks for your help,
Lars