Subject | Re: [Firebird-Architect] transient data sets and procedures |
---|---|
Author | Fabricio Araujo |
Post date | 2005-02-19T16:30:53Z |
On Fri, 18 Feb 2005 17:45:38 -0500, Ann W. Harrison wrote:
modification of declared TDS - it's just adding complication.
<snip>
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.
procedure where it is called.
>If he wants to change things, just create another TDS. No run-time
>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.
modification of declared TDS - it's just adding complication.
<snip>
>We could add a "local" attribute, saying that this declaration creates aWell, the actual solutions to this problem what I have seen is:
>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
>procedures?
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...It's desirable, if it's not destroyed by default in the
>
>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?
procedure where it is called.