Hi Mike > Message: 1 > Date: Thu, 20 Mar 2008 10:29:45 -0400 > From: MB Software Solutions General Account > <[EMAIL PROTECTED]> > Subject: Re: VFP SPT Canvassing Opinion > To: [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="us-ascii" > > Ajit Abraham wrote: > > Michael, > > > > MB Software Solutions General Account wrote: > > > >> How does that do for multiple users hitting the database with > >> adds/updates at the same time? > >> > > > > Lets take example of a sales invoice. > > > > For a new invoice, the Frontend generates the primary key for the master > > table. > > It also generates the many primary keys for the child table along with > > updating the foreign key in the child table. > > Then the backend is updated. > > > > When an invoice is being updated, the frontend generates primary keys > > for new child records. Again the backend is updated. > > > > Are you indicating a scenario of two users simultaneously updating the > > same invoice? > > > > No no, not at all. I just wondered moreso about your comment: "But may > not be sufficent > for really huge ones." Please elaborate as to why you said that.
Hey Wifey! Where's my flame-proof suit? ;) I just ran 2 million calls to this ukey routine and inserted 1 million of them into a table after seeking to see if the value had already been generated. Seems to be safe enough, but there's no way I'd use something so non-standard. The programmer in my wanted to see who it worked. The businessman in me wonder's why I bothered. It's 8 digits and doesn't even use all the bits. I'd use a raw unformatted (16 bytes) more standard GUID before I'd even think of using that routine. I'm not interested in any pointless debate over Integer vs GUID or Natural vs Surrogate. I've already decided that the most universally and consistently applicable approach is Surrogate and GUIDs. I'm too tired to have 15 ways to do *everything*. :) It only remains to refine the technique. Regular GUIDs are not good for inserting into SQL Server tables because of page splitting of indexes. Microsoft introduced NewSequentialID() in SQL Server 2005 which solves the problems caused by GUIDs. Jimmy Nilsson's article showed how his COMBs are almost as fast as Integers for inserting, but are far more unique. http://www.informit.com/articles/article.aspx?p=25862&seqNum=1 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? Thanks _______________________________________________ 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.
