[AccessD] OT: The Great Primary Debate

Here is a problem that may have been caused by faulty  sequenced 
transaction numbers
I am still listening to the "don't panic" radio commercials.
http://biz.yahoo.com/rc/040604/financial_royalbank_1.html

 Royal Bank's  nightmare began during what it called a routine programming
 update. As best it could explain yesterday, its entire national system
 failed to register withdrawals and deposits against customer balances
 on Monday, on Tuesday and again on Wednesday, and by yesterday, the
 system was stalled by the weight of the backlog.

 Restoring data a day at a time, the bank hopes to get Wednesday's
 transactions on-line today but warns that yesterday's transactions are
 unlikely to show up until tomorrow.

 George Geczy, a software developer and computer consultant based in
 Ancaster, Ont., guessed that the problem involves identification
 numbers assigned to transactions.

 "Obviously if somebody made a deposit before they made a withdrawal
 then the bank needs to know the order that happened in. Programmers
 rarely use time stamps any more because time can actually be a little
 imprecise. Everything gets assigned a unique sequence number."

 Such numbers can paralyze computers when gaps or duplications show up,
 he said.

 Perhaps the system "was expecting the next number to arrive -- the
 next sequence number, the next transaction -- and didn't get the next
 transaction and then it would go into a state where it was waiting for
 that missing transaction. It wouldn't process anything else because if
 it did move on past the missing number everything would be out of
 order."

Stuart McLachlan wrote:

>On 4 Jun 2004 at 15:46, Ken Ismert wrote:
>
>  
>
>>On the other hand, the Autonumber is supposed to be a 'meaningless' unique
>>ID. But, consider an auto-generated date dimension table, with consecutive
>>date records. Think an Autonumber key is meaningless in this situation?
>>Think again - it really represents the number of days since Day Zero (the
>>earliest date record in your table). 
>>    
>>
>
>Does it? What if you:
>
>1.  Delete records and rebuild the table without compacting the database.
>2.  Create records with an algorithm that generates records counting backwards 
>from an end date
>3. Extend your table by adding earlier dates after you build your first date 
>range.
>4.  etc
>
>If you rely on the ANPK to be meaningful and use it in calcuations base on your 
>assumption, you can get into trouble very quickly.
>
>
>
>
> 
>  
>

-- 
Marty Connelly
Victoria, B.C.
Canada