Hello,

Marco Lauria wrote:

> No problem,
> but I can assure you that having able to use them can be useful....
> I'd like to be able to use variables in DSQL
> I'd like to be able to use FOR SELECT in DSQL
> I'd like to be able to test a SP in DSQL without having to
> use a work-around or a client-side buggy parser
> as the one that comes with Quickdesk or other similar products.
> But this is my personal opinion...
> Regards
> Marco
> P.S. in other environment you can do this
> and this can tell being faster than other that doesn't have
> similar capabilities.
> And Being faster means that you can achieve the same result with
> less head-ache.
> But I repeat this is my opinion.

Now, push my client-sideism view of it a little bit further and think of
the server hosting (or embedding) a "client"...

What I, personally, would like is to have a common script/stored
procedure concept, valid on the server-side as stored procedures and on
the client-side as "scripts" (no matter we call them scripts or not). I
assume that is what you too described here above. But please, please,
please, let's do a barrage to any solution that would like to run
"scripts" solely on the server-side. Or let's take steps as to allow
such server-side scripts/procs to do things like a client could do. For
instance open up a connection to a database, be it on the same server or
not, start/commit/rollbacks transactions spanning multiple connections,
and so on.

--
Olivier Mascia <om@...>