Dave, I'm not Louis, of course, but I want to jump in your bandwagon.
;-)
We all know IB doesn't have bidirectional cursors. In some complicated
processing, I'm sometimes in the need to go back and forth in a result set.
Probably several people would point that this must be done in the client and
not on the server. So, maybe it's just me that want to do as much as I can
in the server... seems I have some "affinity" with Dalton here.
Personally, I don't think bidirectional cursors should be a priority of a
future release, but that several cursor FW/BW problems could be solved by
allowing sprocs to create temporal tables. Probably temporal tables need
some "privacity" in the sense other users (or other transactions... maybe
too restrictive) cannot step in my ones.
While some people claim for the ability of running arbitrary statements
from a function like sp_executesql in SqlServer, I think this is a new
security breach if not sandboxed properly. Maybe it's possible to allow for
some restricted set of DDL statements in sprocs, like creating temp tables,
setting generator values, deal with GRANT/REVOKE and lowering the priority
of the thread serving the current procedure. While this may seem strange, I
think it's need to avoid one intensive SP hogging the CPU while interactive
users starve for lack of timely response.
I won't follow here to avoid converting this list in IB-Priorities-2.

C.

> -----Original Message-----
> From: David Schnepper [mailto:dave@...]
> Sent: Lunes 5 de Junio de 2000 11:59
> To: 'IB-Architect@egroups.com'
> Subject: RE: [IB-Architect] A few more suggestions
>
>
> re: Dynamic SQL from within an SP.
>
> I don't think that is asking for a "bit much" -- Oracle supports this. My
> head has been churning the last
> few weeks about how this could be added within IB.
>
> Along the lines of "defining the problem" -- Louis, can you
> define some DDL
> operations that
> you've wanted to do in a SP, but haven't been able to?
>
> Dave