Subject | Re: [IB-Architect] Select procedures |
---|---|
Author | Jim Starkey |
Post date | 2000-06-08T14:32:14Z |
At 11:44 AM 6/8/00 +0200, Louis van Alphen wrote:
stored procedures is, in my ever humble opinion, is complete crock.
It is, in fact, a computational form of a view and should have been
implemented under the aegis of the view mechanism. With named arguments
and appearing in rdb$relations, rdb$fields, and rdb$relation_fields
(and the respective ODBC/JDBC meta data calls) it would have been
easier to use, easier to implement, and much easier to wrap with
intelligent code.
It's not high on my list of priorities, but I would like to see a
view based mechanism defined and the current mechanism deprecated.
This will have to wait until after the great Java vs. embedded Pearl
vs. XML shootout.
Jim Starkey
>Someone wrote:The design (not the concept) of the select form of the InterBase
>
>>The question is whether to translate "{ call foo }" into
>>"execute procedure foo" or "select * from foo".
>
>I use Delphi + IB + Crystal. I normally create SPs for ALL my reports, as I
>can do joins, do calculations, etc...
>Then I purely link the report to the SP and Viola!. The point is that it
>has the same effect as 'SELECT * FROM SP'. You do get the full resultset.
>Then call the report from Delphi.....
>
stored procedures is, in my ever humble opinion, is complete crock.
It is, in fact, a computational form of a view and should have been
implemented under the aegis of the view mechanism. With named arguments
and appearing in rdb$relations, rdb$fields, and rdb$relation_fields
(and the respective ODBC/JDBC meta data calls) it would have been
easier to use, easier to implement, and much easier to wrap with
intelligent code.
It's not high on my list of priorities, but I would like to see a
view based mechanism defined and the current mechanism deprecated.
This will have to wait until after the great Java vs. embedded Pearl
vs. XML shootout.
Jim Starkey