Subject Re: [Firebird-Architect] transient data sets and procedures
Author Fabricio Araujo
On Fri, 18 Feb 2005 17:45:38 -0500, Ann W. Harrison wrote:

>Vlad Horsun wrote:
>> Ok, i understand. You propose to map declared TDS name
>> to corresponding "real" (defined) TDS name. This is allows to create
>> and fill TDS outside of procedure and use it inside.
>Right. That seemed like a desirable characteristic. An alternative is
> to say that transient data sets are transient, stored procedures are
>stored, and so they're naturally incompatible.
>> This approach needs
>> run-time check for existence of TDS (this is ok) and structure matching
>> of declared and defined TDS. I think second requirement is not good.
>> Developer can wrote procedure with one structure of TDS in mind but
>> latter he can redefine structure of TDS and get run-time errors in SP.
>That's also right, and it's dictated by the current nature of stored
>procedures. It's possible to generate blr for a table that doesn't
>exist, but not for a table with an undefined format. At some point, we
>will look at a different representation for stored procedures, but I was
>trying to work within the current model.

If he wants to change things, just create another TDS. No run-time
modification of declared TDS - it's just adding complication.

>We could add a "local" attribute, saying that this declaration creates a
>new transient data set, local to this procedure. That's fine, until I
>decide that the procedure is too complicated for me to understand or
>debug and want to break it into separate processing steps. Can you
>suggest a way to declare the data set local to a group of related

Well, the actual solutions to this problem what I have seen is:

1 - It's a parameter of TDS - so pass it like a declared cursor
2 - Scoping - called procedures can see TDS'es of the caller procedure.

>Ah, sorry, I should have included that case.. more like this...
>When the procedure is first invoked and compiled, it will return an
>error unless a matching transient data set is defined within the
>procedure or the invoking connection has a transient data set defined
>that corresponds to the declaration.
>Is it important to be able to destroy a transient data set?

It's desirable, if it's not destroyed by default in the
procedure where it is called.