Bill Benson
bensonforums at gmail.com
Fri Mar 7 07:59:31 CST 2014
Jim, so you have agreed that GUID1 cannot be compared to GUID2 to tease our a record's ordinal position and you have said that auto number can get confused and turn negative. Might I say that the latter situation is a database corruption issue, since if they turn trip 0 they take away the one test I often use for "no record" and if they go higher after that they could easily try to duplicate a record id. I think this adds a measure of maintenance to a database and /or rules out Access as a relational database of choice in high stakes operarions. I would not run my life by this extremely unlikely principle. As for AN being a local phenomenon, says who? If the Access database is a backend systen, then then New Record is called, it will advance the value in the main table. No long as the database is not replicated or being maintained client-side, the connection can be dropped and the record used until update is required or the next New Record. So that argument sounds like a non starter or else equivalent to other things said in support of GUID. No one yet has said how a GUID value can be shown to come before or after another. I cannot think of a database project yet where I was not concerned with sorting records in a recordset that included all records posted on or before a certain record, or on or after a certain record, and datetime is not a good predictor. I have seen that field hand-entered/overridden after-the-fact. I need record Id for sequential comparison of records, generally, and I don't believe that is possible with GUIS and is always (ok, *almost always*) doable with an Auto number fields. And don't forget in client server databases, the sequence is often handles by a stored operation that runs while the database is running, called, I think, a Sequence and a new record Id gets popped every time the stored function is called and it always keeps track where it is regardless of the number of users. And for Peterson ' s sake, the name is Bill, NOT BENSON!! What is this, High School?? On Mar 7, 2014 6:42 AM, "Jim Dettman" <jimdettman at verizon.net> wrote: > <<How else could I sit on record with RecordID = ######## and find the very > > > > next previous record?>> > > Well one problem with that is that you really can't. AN's can roll over > to negative numbers, So your check may not be valid at some point. For > all practical purposes it's true (the rollover point is quite large), but > I have seen a Jet db corrupt and as a result, the AN seed jump to an > extremely high number. > > Second problem is that the key is no longer meaningless. You've encoded > the "entry order" in the value of the key. > > You can't change the key without destroying the information it represents. > > GUID creation does involve the time as part of the calc, but that doesn't > allow you to treat them as sequenced numbers. > > Jim > > Sent from my iPhone > > On Mar 6, 2014, at 11:54 PM, "Bill Benson" <bensonforums at gmail.com> wrote: > > > 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. > > > > > > > > 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 > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com >