> Extraordinary! one of the many things I hated about SQLServer
> was the contortions one has to go through to get row sets back
> from a SP! Not to mention the _further_ contortions to undo the
> work when a user error breaks the logical task.

Never noticed the problem. But most of my work with SQL Server did
not involve that much user interaction and some of with was on
Sybase and not on M$.

When I used M$ SQL Server with a couple of GUI Clients, that is
when I found my less favorite property of SQL Server:
- the way it falls on its knees when the number of connections
grows.

I think M$ started preaching about n-tier architectures because
THEY HAD TO.

And I could mention several other "features" that are much higher
in my M$ SQL hate list. I just don't remember what you are
talking about as a real obstacle.

> Have you never done a
> FOR...SELECT...INTO...DO...SUSPEND style of procedure in IB?

A couple of times. Sometimes I even had to type a lot to do it
and my delicate fingers resent that.
=;o)

It really is such a fascinating flexible mechanism, and I like
that ...but it is also quite annoying at times.


When processing big chunks of that on the server side I used
temp tables a lot. And in a couple of situations, for complex
reports and so, I used temp tables to cook the data and then
returned them to the client just by SELECTing them.

Now, if I would have temp tables:
- Fast (as-much-in-memory-as-possible);
- With transaction scope, completely invisible to other
transactions;
- And that would just disappear when the transaction is over.

And if I could return a complex temp table with results just
by typing a silly:
SELECT * FROM #temp

> ...
> roll the whole lot back, if it comes to that...try to get that
> degree of ACID from SQLServer.

Of course, I did not say that the implementation had to be
as sh*ty as M$'s.

The versioning stuff could help there, just as it does help
hiding changes made in one transaction from the others until
they are committed, and has it turns them into smoke when they
are rolled back.

But since this is Open Source and I do not intend to go back
to coding in C just to scratch this itch, I will keep the
rest of my extensive whish list to myself and will not even
insist on this one.
=:o)


Have fun,
Paulo Gaspar

> -----Original Message-----
> From: Helen Borrie [mailto:helebor@...]
> Sent: Thursday, November 22, 2001 1:18 AM
>
> At 08:42 PM 21-11-01 +0100, Paulo Gaspar wrote:
>
> >What I really miss is being able to return result sets ( = a set of
> >rows = the result of some SELECT) from inside a Stored Proc.
> >
> >This is one of the few things I miss from M$ SQLServer!
>
> Extraordinary! one of the many things I hated about SQLServer
> was the contortions one has to go through to get row sets back
> from a SP! Not to mention the _further_ contortions to undo the
> work when a user error breaks the logical task.
>
> Have you never done a
> FOR...SELECT...INTO...DO...SUSPEND style of procedure in IB?
>
> When you SELECT * from myproc(:param1, param2), the procedure
> does all its stuff and then returns the rows to play with.
> Everything stays inside the same transaction context and you can
> roll the whole lot back, if it comes to that...try to get that
> degree of ACID from SQLServer.
>
> Helen