Helen,

I understand you. Really!

I know how traumatizing can be working with M$ SQLServer. (Sybase
was a bit more solid in my experience.)

But it looks like your trauma is obscuring your perception of the
fact that I am talking about the idea and NOT the implementation.

I mean, I was talking about copying the feature and not the bugs.

Claudio got the thing right.


Have fun,
Paulo Gaspar

> -----Original Message-----
> From: Helen Borrie [mailto:helebor@...]
> Sent: Thursday, November 22, 2001 2:57 AM
>
> At 02:38 AM 22-11-01 +0100, Paulo Gaspar wrote:
> > > Which means what, exactly? I don't know SQL server very well.
> How is it
> > > 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.
>
> If 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...
>
> 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