|
Thanks Joe, That is interesting, I have often worried aboubt the speed of SQL inserts; I usually use OLE DB Provider /ADO 2.5 and batch updates in chunks of 100. ODBC is as dead as a duck in my books. Dave ----- Original Message ----- From: "Joe Pluta" <joepluta@PlutaBrothers.com> To: <midrange-l@midrange.com> Sent: Wednesday, November 14, 2001 5:39 AM Subject: RE: Green screen - it's time is over > I have less problem with SQL than with ODBC, Dave. If your SQL is > encapsulated in a way that your client doesn't use table or column names > (basically, if you don't have raw SQL statements in your client > application), then I'm okay with it, to a degree. I still find SQL to > perform significantly worse than RLA for non-set-based database updates > (that is, when you're updating a small number of records, as in transaction > processing). > > SQL is fine on the host for ad hoc queries and set-based updates (like > month-end rollovers and the like). As long as the details of the SQL > statement are hidden from the client, I have no problem. > > SQL is inappropriate for transaction updates - RLA performance is simply > superior. Don't believe it? Run a few tests. I've published results > regularly that show that RLA is still at least 50% faster than SQL for > typical database updates and inserts. > > ODBC, no matter what the application, goes against every possible tenet of > distributed processing. It is slow, and it ties your host database to your > client code. You cannot change even the names of your columns (much less > the physical layout and location of your data) without updating your client > code. This is absolutely unacceptable. > > Does that answer your question? > > Joe Pluta > www.plutabrothers.com > > > > -----Original Message----- > > From: David Bulog > > > > Joe, > > Im lost here,whats wrong with business rules in SQL? I would like to drill > > down deep to the nitty gritty of what you dont like aboubt SQL. > > BTW I thought IBM invented SQL in the first place > > Thanks in advance > > Dave > > _______________________________________________ > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list > To post a message email: MIDRANGE-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l > or email: MIDRANGE-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l. >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.