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.

>
> select *
> from rdb$database
> yielding fat_cats;
>
> we'll got error in latter invocations of procedure fattest_cats.

That's right. Procedures that use real tables have dependencies on
those tables that cause errors when you try to change the table
definitions. That strategy works badly with something transient.

>
> Since TDS'es is like temporary variables i suspect that its names
> often will be like T, T1, T2 etc and scenario above is very probable.

Yup. And a procedure designed to work on a transient data set called T
is unlikely to generalize well...

>
> But there is at least one more problem.
>
> I want to use TDS's primarily in my SP's to simplify hard calculations and
> reuse partially calculated datasets in subsequent queries.

That seems like a reasonable approach.

> Therefore i have
> a big number of SP's which used TDS's. And that TDS's usually local to SP
> in which it is declared and defined. Your approach force me to assign a
> different
> names to all of my "inner" TDS's in all my SP's :( And there are no help from
> compiler at compilation time

I agree that's awkward.

I tend to write small procedures that perform specific transformations,
so I need the ability to create a transient data set in one procedure -
or in my code - and transform it in another procedure. Allowing a
procedure to use a previously constructed transient data set is very
attractive.

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
procedures?

>
>
>>When the procedure is first invoked and compiled, it will return an
>>error if the invoking connection does not have a transient data set
>>defined that corresponds to the declaration. If the data set is
>>defined, the execution structures will reference that definition through
>>the connection.
>
>
> What if i want to declare TDS and define it in the same SP ?

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?


Regards,


Ann