Subject | RE: [ib-support] SP returning result sets? |
---|---|
Author | Helen Borrie |
Post date | 2001-11-22T01:56:49Z |
At 02:38 AM 22-11-01 +0100, Paulo Gaspar wrote:
About its only "benefit" is that one SP can output multiple result sets to a galaxy of temporary tables.
My observation from working in a SQLServer shop for a year was that this "benefit" had encouraged the programmers to design applications that pushed an inordinate amount of data processing onto the client, were highly fragile about dependency and concurrency and needed 24/7 attention just to keep the server running long enough to finish a run.
It was "par for the course" for month-end runs to crash at least once, produce at least one set of wrong output and to require code-tweaking EVERY TIME - it was part of the normal procedure to have the programmers (both database and client) on hand during runs to fix things so that the run would actually GO the full course and get the statements ready for mailing on the contracted day. Running month-ends for a dozen telecoms providers required a) that the whole network (including our development network) be dedicated to one customer's run and b) that staff stayed in residence 24/7 when runs were being done.
InterBase never forces, nor even encourages you to write applications like that. How I missed its atomicity and elegance. I was constantly reminded of an old Norfolk expression, "There's a vast difference between scratching your ass and tearing the skin off."
Helen
All for Open and Open for All
InterBase Developer Initiative ยท http://www.interbase2000.org
_______________________________________________________
> > Which means what, exactly? I don't know SQL server very well. How is itIf you are still talking about operating on rowsets back from stored procedure output, it is not that simple. Your procedure has to create that temp table on the local disk by processing a cursor first..and ACID transaction control is a joke. It also forces you to split up the logical task on the client side by having to deal with the SP input and output as unrelated data...it's horrendously slow...it contributes significantly to the major problem that SQLServer presents, of hanging up or falling over completely through unpredictable memory demand (or just a change in the air pressure!)...it adds more overhead to the MS haystack, with management of permissions on temporary objects...oh, I could go on...
> > simpler?
>
>For context take a look at my previous posting. But basically
>it means that doing:
> SELECT * FROM someTable WHERE someCondition...;
>will return a resultset.
About its only "benefit" is that one SP can output multiple result sets to a galaxy of temporary tables.
My observation from working in a SQLServer shop for a year was that this "benefit" had encouraged the programmers to design applications that pushed an inordinate amount of data processing onto the client, were highly fragile about dependency and concurrency and needed 24/7 attention just to keep the server running long enough to finish a run.
It was "par for the course" for month-end runs to crash at least once, produce at least one set of wrong output and to require code-tweaking EVERY TIME - it was part of the normal procedure to have the programmers (both database and client) on hand during runs to fix things so that the run would actually GO the full course and get the statements ready for mailing on the contracted day. Running month-ends for a dozen telecoms providers required a) that the whole network (including our development network) be dedicated to one customer's run and b) that staff stayed in residence 24/7 when runs were being done.
InterBase never forces, nor even encourages you to write applications like that. How I missed its atomicity and elegance. I was constantly reminded of an old Norfolk expression, "There's a vast difference between scratching your ass and tearing the skin off."
Helen
All for Open and Open for All
InterBase Developer Initiative ยท http://www.interbase2000.org
_______________________________________________________