> Let me guess the answer ... "It depends".
> 
> The fundamental point is .... that trying to use Cursors on a RDMBS will
> never give you the performance you can get from native SQL approach.
> Indeed most books on SQL, including M$soft SQL advise against this
> approach. "
> 
> I agree with you Tony.  However, I would suggest that in the contexts we
> have experienced the above does not matter.
...
> 2) As I mentioned previously, fast machines are really inexpensive today.
> 
> Therefore, if a customer can achieve the performance they feel they need for
> their application and the hardware is really cheap, why would one care about
> relative performance of pure SQL access versus cursor based access?
> 
> 3) It is more expensive in terms of labor costs to redesign your application
> to perform faster.  For example, a migration that cost $100,000  going the
> simple route using cursors, could conceivably cost as $300-$500,000 with a
> redesign!  Moreover, any redesign is more risky than a simple migration.
> 
> Customers who like our approach are first and foremost risk averse.
> Secondly, I think it is difficult today to find a customer who will spend
> $200,000 in labor to avoid spending an extra $10,000 on hardware.

I would also say, "It depends". If an application is reading and updating
individual records most of the time, like many MPE applications do for OLTP,
there isn't any real performance improvement over one SQL UPDATE or INSERT. If
the conversion routine is converting a single DBFIND/DBGET/DBUPDATE with a
stored procedure behind the scenes, I don't think that any current selling
system would be any slower than your 3000. When you get to mass updates, then
Tony's point is well taken.

(Side note: Some operations are not easily done in RDBMs, like exploding a
bill of material. Some vendors, like Oracle, have added proprietary extensions
to their SQL implementation to do this. There are clever ways to make your
tables act like trees to get the job done but that requires some extra fields
in your tables and extra care in updates/deletes to maintain these fields.
This is a situation that many application developers still use cursors in
their stored procedures.)

I have to agree with Charles. If one can migrate using most of your existing
code AND gain the benefits of the popular tools available with many of the
RDBMSs today AND save oneself a lot of money, that sounds like a sound
decision to me - especially if you need more time to explore the next system
platform option be it a migration or a rewrite.

Mark W.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *