I didn't notice .

I wasn't trying to be snide.

There are reasons why relational theory has developed several normalization rules of data structures.

Your bit vector column violates the first normalization rule, called "First Normal Form", which states, in effect, that all column values should be atomic.

A more formal definition reads, "The domains of attributes must include only atomic (simple, indivisible) values and that the value of any attribute in a tuple must be a single value from the domain of that attribute."

Your bit vector column contains multiple values so it is not atomic, and thus violates this first rule of database normalization.

This may or may not cause you problems down the line. It will be a bit difficult to select rows based on values of this column, and updating them can be a bit tricky, requiring potentially awkward bit masking/shifting, etc. - not something that the SQL language is necessarily all that good at. Try writing a report/query that lists the privileges a user is assigned.

A more normalized solution would have a related table with one row for each privilege the user is assigned, i.e. (User, Privilege).

Jeff Mason
Custom Apps, Inc.
www.custom-apps.com

I am explaining myself poorly/ I didn't go into details because I just wanted an answer to the original question. Either way, I do have individual rows in a separate table that define the privileges. I've put the bitmask into the database for speed of processing. We try to adhere to 3rd normal form as much as possible; I suppose I could just compute the masks in code . . . hmm, I'll have to think about that one.

Either way, I guess the answer's no on incrementing a primary key via anything but straight addition?

I'm not trying to give you a hard time, honest. But what makes you think that cramming that information into a bit vector will in fact increase processing speed? If you are talking about client code, I could see that, as testing a bit in client code to see if the user has a certain privilege will be very fast. Much faster than looking up the privilege value in an array or collection or whatever. Testing the bit in an SQL query or otherwise operating on the values using SQL operations such as JOINs, etc. almost certainly won't be faster than a more normalized approach.
You can provide a primary key value any way you want as long as it is unique in its table. Identity values, on the other hand, can only be automatically assigned increasing values by a defined increment, which by default is 1, but can be any positive integral number. The datatype of a column with the identity property (this does not have to be the primary key, though it typically is used for a primary key - that's the subject of another debate :)) must be one of the integer types, or the numeric types with a 0 scale value, i.e. integral values.

So, no, you can't have the system do anything automatically other than add the increment to the 'last' identity value to give you the next one.

Jeff Mason
Custom Apps, Inc.
www.custom-apps.com

That is what I'm talking about. The user object is already going to have those rows coming back into it, so, rather than looping over the DataSet to then calculate the masks every time a user object is instantiated, I'm storing them with the permission record in the database.