Not at all.  The number is never assigned until the eep that actually adds the record is in the process of doing so.  We don't use the traditional method of having R:Base through the use of the form enter the record; it is all handled by an eep behind a button that says "OK" or some such.  Complete control.  If they decide to not add the row, no action has to be taken other than close the form.


Emmitt:   Do you mean, though, that they could never change
their mind and NOT add that record?

In several of our processes, like order entry for example, we use forms where the fields are all variables (but not true variable forms).  The eep to add the record sets a lock on a control table, retrieves the integer value, increments it by one, stores the new value back to the control table, then releases the lock.  This number is used for the order number.  Always unique, never duplicated, never skipped.



And I agree with Mike and Dave.  I always have an autonumber PK
on each table that means nothing to the client.  But if they ALSO
want a unique number (such as an invoice number) it seems redundant
to have TWO unique numbers per table.


>I agree with Mike. I don't even let them know the autonumber PK exists.



Karen

Emmitt Dove
Manager, DairyPak Business Systems
Blue Ridge Paper Products, Inc.
40 Lindeman Drive
Trumbull, CT  06611
(203) 673-2231
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Reply via email to