> "only a write lock" is a little like "only an atomic bomb".
> A write lock prevents others from accessing AT ALL; a read
> lock prevents others from writing. But what you need here is
> a write lock.

Oh, I had that backwards. That may not work too well, then. Probably a
separate table to hold these unique numbers would be a better approach after
all, since it would not interfere with the access to the rest of the
settings in the table.

>>> 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?
>
> A query for printing business cards with the keyword = value
> organization might look like:
>
> SELECT a.value, b.value, c.value, d.value, e.value, f.value, g.value
> FROM addrbook a
> LEFT JOIN addrbook b on a.personid = b.personid and b.attribute = 'Last
> Name'
> LEFT JOIN addrbook c on a.personid = c.personid and c.attribute = 'Work
> Street Address'
> LEFT JOIN addrbook d on a.personid = d.personid and d.attribute = 'Work
> City'
> LEFT JOIN addrbook e on a.personid = e.personid and e.attribute = 'Work
> State'
> LEFT JOIN addrbook f on a.personid = f.personid and f.attribute = 'Work
> Zip'
> LEFT JOIN addrbook g on a.personid = g.personid and g.attribute = 'Work
> Phone'
> WHERE a.attribute = 'First Name';

I got it. No, this is not at all what I use that kind of tables for. The
Item, Value approach I use only for storing settings & resources, etc.

Thanks,
Lars