On Thu, Mar 20, 2008 at 8:24 PM, Mike yearwood <[EMAIL PROTECTED]> wrote:
> Hi Stephen > > You haven't addressed my questions specifically. > > > Message: 6 > > Date: Thu, 20 Mar 2008 17:17:13 -0500 > > From: "Stephen Russell" <[EMAIL PROTECTED]> > > Subject: Re: GUID generation (was VFP SPT Canvassing Opinion) > > To: [EMAIL PROTECTED] > > Message-ID: > > <[EMAIL PROTECTED]> > > Content-Type: text/plain; charset="us-ascii" > > > > On Thu, Mar 20, 2008 at 12:14 PM, Mike yearwood < > [EMAIL PROTECTED]> > > wrote: > > > > > > > > 1 - NewSequentialID is sequential if SQL Server generates the ID. > > > That's because SQL Server apparently calls UuidCreateSequential on the > > > server. If I have a client generate a GUID using UuidCreateSequential > > > the records will be sequential relative to other records on that > > > client, but not relative to other clients. Is that a performance > > > problem SQL Server? > > > > > > 2 - If 1 is yes, how can a client ask the Server to perform > > > UuidCreateSequential if SQL Server is not on the server? > > > > > > 3 - Is the NewSequentialID as fast as Nilsson's COMBs? > > > > > > 4 - Is it better for index storage to have the first part of the GUID > > > be static and the second part be sequential or vice versa? Basically > > > Surname, Firstname or FirstName, Surname? Is that the same answer for > > > SQL and for VFP? > > > --------------------------------------------------- > > > > > > Never use a clustered index on a GUID as your PK. That will stop a lot > of > > your problems . > > I'm sorry, but I cannot accept such an answer with no explanation. > Every table should have a primary key and a clustered index. An > ever-increasing value in the primary key will deal with any problems. > A regular GUID is the problem, not the clustered index. A > sequentialized GUID solves the problem. Microsoft added > NewSequentialID as an enhancement over NewID. > > So, back to my questions? > ------------------------------------------------------------------------- I have a host of errors / issues to run down this morning so I'll try to get back later to this. -- Stephen Russell Sr. Production Systems Programmer Mimeo.com Memphis TN 901.246-0159 --- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html --- _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
