It depends...

If you already have a field in these tables utilizing NewID(), or you plan to auto-increment more than one field per table, then you're correct... you need to "roll your own" function. NewID() is designed to work with only one field, generally the PK, of a table.

Else... adding NewID() as the default value for the field in question at the table level, and adding the table name to the ID table will work. One caveat... there are additional, internal framework functions that fire on BizObj.New(), designed to "pre-fetch" a new ID into the corresponding view. These functions work specifically with the view's PK field. This means your value will not get populated until a TableUpdate is issued in BizObj.Save() -- if that's not a problem for you, you should be good to go.

Hope that helps,
---J

>Hi Nadia:
>
>I need to handle a set of “folio(s)” for different documents like invoices, purchase orders, etc. Such fields need to be specially handled by a function allowing the user to supply an optional number and the function handling this folios has to be smart enough to detect the next one (not exactly numeric) or any other available from a list. I stick to the idea of not using these unique value fields the primary key.
>
>MM contains a couple of functions to handle auto incremental numeric and base 62 character fields, but the stored procedure that triggers such functions seems not to be flexible enough for my purpose.
>Oscar