Isolating that alpha incrementing

[rob@xxxxxxxxx]

Regarding jt and Hans discussion on that database design.

Good database design is not really rocket science.

I agree that putting that into an alpha field is hard to understand. 
Granted, we have a package that stores employee numbers into alpha, and 
does their own auto incrementing for new employees.  The business logic 
was to support customers who migrated from a system with alpha employee 
numbers to use their package.  I can understand that paradigm.

Ideally such an id field would use some of the new data types supported in 
V5R2 to do this autoincrementing.
Failing that the update would be in the trigger program.  That's what a 
good DBA does.  Leave the application programming up to the programmer. 
However, much of this stuff needs to be moved out of the application and 
into the DB itself using techniques such as:
- autoincrementing fields
- constraints
- triggers
And all these aren't really all that hard to understand.  It just takes a 
little discipline.

As far as the trick with the data structure.  I don't like that because if 
the field size changes your toast.  And coming from a package that changed 
numerous field sizes, such as the size of the item master number, (which 
is a huge undertaking for an ERP package), I can tell you that this stuff 
happens.  Using the other techniques allows a recompile to handle it.

Rob Berendt
-- 
"They that can give up essential liberty to obtain a little temporary 
safety deserve neither liberty nor safety." 
Benjamin Franklin