You're right, newid() creates the number in the new method and would create the holes your talking about. I have never done this, however, what I would suggest is to create your own stored procedure that mimics the newid() stored procedure of going to an 'id' table to get the next number, but it would be called in the presavehook of the business object. This means you would not use the default value on the table itself.

This would create new problems if you have child records of the main business object. For example, in a classic order and order item scenario, you would have to write code to pass the new id from the order table to the order item records before saving the order business object.

In the end, this made me conclude that even though the 'holes' are there, they really don't cause a big problem as far as I was concerned in that the holes are easily explained. (Auditors typically have problems with this situation). You could limit these 'holes' by setting the lautonewrecord property to false (on the cbizobjnolistmaintform class) and setting the luienablernewrecord property to false (on the business object class dropped on the form). This way when a form is activated a new record is not presumed and if the user wants to add a new record all they would do is hit 'cntrl-N'. And when a record is saved a new record is also not presumed. Of course, this would not eliminate these 'holes'.

Bottom line is, to change the newid from getting the new record number on the 'new' method as opposed to the 'save' method, would require extra work in any parent/child type form. If you feel that the extra time is worth it then that's the way you would need to go about it.

Hope this helps.