>So based on my environment, this technique is sound. If you use SYS(3), SYS(2015) or GUIDs this technique doesn't work and the PKs are only used for RI routines.

My PK generation works the same as yours, but just to play the devil's advocate, there are many environments where records must originate from different sources without access to the same PK generation routine. In these scenarios, the PK must either be generated with a node multiplier to guarantee uniqueness, or using CoCreateGUID. Whatever the technique used to accomodate this need, this would not allow the assumption that PKs are sequential.

Additionally, even with a sequential scheme, some frameworks allow the fetching of the PK when the record is inserted into the view or buffered table (to allow for simultaneous addition of related parent and child records). In this case, workstation A may retrieve a unique value first, but take longer to commit his record, so a higher number would fall sequentially first in the underlying table.

IOW, I don't think that this is generally a safe assumption, but only in certain tightly controlled situations...