Jim Lawrence
accessd at shaw.ca
Fri Mar 7 01:14:46 CST 2014
Hi Benson: That is why it is so important to have a central internet/phone accessible database, that handles the account and invoice numbers, especially if your are intending or have a invoicing system that extends across the country. Auto-number is just a local phenomenon and would cause key data collision if ever used as a PK. Traditionally, all clients have a copy of all invoices created in the entire system but can only view or access (update) those records they create. Sometimes, a site may be given a batch of numbers so the breaks in numbering sequence are less obvious. Keeping transaction numbers for accounting records can be even more complex...one invoice will only ever have a single invoice number but every change in the data must be reflected in the item list (added, updated or deleted) and subsequently in the accounts receivable record. This is very important so a corrupted record can easily be rebuilt or any invalid transaction can be easily traced. Jim ----- Original Message ----- From: "Bill Benson" <bensonforums at gmail.com> To: "Access Developers discussion and problem solving" <accessd at databaseadvisors.com> Sent: Thursday, 6 March, 2014 8:54:58 PM Subject: Re: [AccessD] Membership File Changes I would also add that the autonumber PK is very good for searching for all records created before and/or after another record, without having to compare pinpoint precision date fields, which even then may not have *enough* precision when things occur in a batch mode. How else could I sit on record with RecordID = ######## and find the very next previous record? All I know to do is look for the MAX(RecordID) WHERE RecordID < ########. If someone knows a way to do that with GUID, then I will stand down. But being an ignoramus and knowing nothing about how GUIDs are constructed, only that they are essentially "random"...?? Otherwise, well bite off my fingers. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John W Colby Sent: Thursday, March 06, 2014 11:43 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Membership File Changes Explain to the whipper snapper that two integers can be compared in a single instruction. Two GUIDs will take an entire string compare function and thousands of cycles to perform the same compare. Then whip up a demo to show him. GUIDs are dog slow compared to integers. John W. Colby Reality is what refuses to go away when you do not believe in it On 3/6/2014 8:02 PM, David McAfee wrote: > <snip> > This strategy is not without detractors however, mostly "old timers" from > databases where multi-field PKs were ALWAYS used. Mostly they try to argue > that it is possible to just read the PK down in the child / grandchild / > great grandchild etc. simply by looking at the data in the multi-field PK, > which "saves your bacon" when orphans creep in and so forth. Additionally > the "values" can often be pulled for reporting and the like, without > requiring joins back up the chain. Both are true, but not (IMO) make up > for the overhead and headaches that multi-field PKs bring with them. > </snip> > > John, I was recently called an old timer because I insisted on using > autonumber integer PK for some of our new designs. > The young whipper snapper said that's the "old way" of doing things, and is > very anal about using GUIDS and multi-field PKs. > > I know GUIDs have their place, but he just doesn't get it. I love how my > stuff runs so much faster, even with joins. :) > > D --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com