I often wonder about SQL..... <scratching bald spot on head> BobW
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:owner-u2- > [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] > Sent: Tuesday, March 08, 2005 12:26 PM > To: u2-users@listserver.u2ug.org > Subject: RE: [U2] Unique Ids > > Susan, > > This is the approach I took with the speaker. There was a period of > time 'in the good old days' where the has could go goofy either through > corruption or keys containing system delimiters .. > > But as the speaker (supposidly with the same term of experieince as I) > was teaching the benefits of MsSql Server and the wonders of sql .. <G> > > DSig > David Tod Sigafoos > SigsSolutions, Inc. > > > > -------- Original Message -------- > > Subject: Re: [U2] Unique Ids > > From: "Susan Lynch" <[EMAIL PROTECTED]> > > Date: Tue, March 08, 2005 11:54 am > > To: u2-users@listserver.u2ug.org > > > > I don't recall an MV implementation that intentionally allowed non- > unique > > primary keys. Were the people in the meeting thinking of secondary keys > > (aka indexes) in which non-unique keys are quite possible? > > > > The only other thing I can think of would be the old (and non- > intentional!) > > problems with traditional native Pick in which a group in overflow could > > have one of the linked frames written back to disk and another linked > frame > > in the group not written back to disk (eg. during a system crash), in > which > > case a record which shifted position in the group could end up in both > > frames, and thus in the group twice. In order to get rid of one of the > two, > > we used to edit that record in the file, which would bring up the first > one > > in the group - look at it to see if this is a complete and up-to-date > > version of the record and either save it to move it to the back end of > the > > group or delete it if it was obviously a damaged or partial copy. If > we > > did not delete that record, we would then edit the record with that key > > again, which would bring up the one that used to be second and was now > the > > first in the group, and decide which one to keep. I haven't seen this > on a > > UD system, due to the way that the keys are stored in a table at the > > beginning of the group, and I don't recall having seen it on the UV > system > > that I managed for a few years, but I did see it a lot in the earlier > days > > in Pick. > > > > Susan Lynch > > F.W. Davison & Company, Inc. > > > > ----- Original Message ----- > > From: <[EMAIL PROTECTED]> > > To: "U2 Users List" <u2-users@listserver.u2ug.org> > > Sent: Tuesday, March 08, 2005 1:37 PM > > Subject: [U2] Unique Ids > > > > > > > I just came out of a meeting where it was stated that MV databases > allow > > > non-unique keys. > > > > > > Now I have been working in the VM world since 1983 and although I can > > > remember a time when some of the implementations had 'problems' with > > > hash and specific data in keys .. i can not think of a time when MV > > > tables allowed non-unique keys. > > > > > > 'Say it aint so Joe' .. > > > > > > If anyone knows of any implementation which specifically allows > > > non-unique ids .. please let me know .. show me the light. Have I be > > > in the back room eating twinkies too long? > > > > > > thanks > > > > > > DSig > > > David Tod Sigafoos > > > SigsSolutions, Inc. > > > ------- > > > u2-users mailing list > > > u2-users@listserver.u2ug.org > > > To unsubscribe please visit http://listserver.u2ug.org/ > > ------- > > u2-users mailing list > > u2-users@listserver.u2ug.org > > To unsubscribe please visit http://listserver.u2ug.org/ > ------- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
