"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in
news:A53C7599-68E9-43B8-9EEE-16A3FCB70D04@news.elevatesoft.com:

> IOW, the SQL statements after the SELECT may try to do something
> that requires exclusive access with the tables involved in the SELECT,
> etc.
>

Couldn't that "danger" be left for the programmer to cope with? If any such
problem just generates an error, we'll soon learn how to not generate them.

Anyway, ElevateDB's just around the corner, so I'm happy to live with this
in v4

--
Chris

Chris,

<< Couldn't that "danger" be left for the programmer to cope with? If any
such problem just generates an error, we'll soon learn how to not generate
them. >>

The problem is that it is an either/or proposition.  IOW, it would make it
impossible to do a SELECT INTO statement in conjunction with another
statement after the SELECT INTO that wants to do something else with the
query result set of the SELECT INTO.  Whew !  That's a mouthful.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in
news:BC154BEE-9408-411B-A093-FC4B489DBA50@news.elevatesoft.com:

> another statement after the SELECT INTO that wants to do something
> else with the query result set of the SELECT INTO.

I don't follow - If I do a SELECT INTO, I don't expect to get back a
result set directly, I'm bound to either follow up with a SELECT that
leaves me with a result set, or an UPDATE/DELETE/INSERT on another table
that joins to the SELECT INTO table, amn't I ?

Or else I'm just preparing the way for some other SQL or pascal
manipulation of the temporary table, outside the initial script, so I
won't want to drop it in the same script.

So IIUC, I could follow my SELECT INTO with a SELECT and then a DROP
TABLE and DBISAM would know for sure that the INTO table was to be
dropped after giving me a canned result set, no?

It's up to me to not do a drop if I'm going to need the INTO table after
the script is over.

So I'm asking for (well we're discussing the possibility of leaving
the result set of a penultimate SELECT (without INTO) available to the
program when the ultimate (or all remaining) command is a DROP TABLE, and
there is no confusion (?).

Perhaps the DROP(s) could be done when we UnPrepare the DBISAMQuery? (or
when the program closes down if we never unprepare it).

It would simply allow for tidier, more self-contained coding.

(my brain is trying to catch up...)
The DROP(s) should go into a waiting mode until the SELECT frees the lock
it has on the temporary table(s)! got it!
--
Chris

Chris,

<< I don't follow - If I do a SELECT INTO, I don't expect to get back a
result set directly, I'm bound to either follow up with a SELECT that leaves
me with a result set, or an UPDATE/DELETE/INSERT on another table that joins
to the SELECT INTO table, amn't I ? >>

Not currently, no.  DBISAM will return the result set of a SELECT..INTO if
it is the last SQL statement in the script.


<< So IIUC, I could follow my SELECT INTO with a SELECT and then a DROP
TABLE and DBISAM would know for sure that the INTO table was to be dropped
after giving me a canned result set, no? >>

Sure, in which case DBISAM would currently provide no result set.

<< So I'm asking for (well we're discussing the possibility of leaving
the result set of a penultimate SELECT (without INTO) available to the
program when the ultimate (or all remaining) command is a DROP TABLE, and
there is no confusion (?). >>

Yes, but what you're talking about involves some serious wranglings to
determine which SELECT statements should be left open vs. which should be
closed.  IOW, DBISAM will have to try and infer what you want to happen,
which is prone to make things dicey when it comes to how DBISAM processes
the SQL scripts currently.

<< Perhaps the DROP(s) could be done when we UnPrepare the DBISAMQuery? (or
when the program closes down if we never unprepare it). >>

That may be more feasible - a CleanupSQL property that is executed once the
script is unprepared.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in
news:43110FB5-4289-4B9D-9706-A43CE9E94BDE@news.elevatesoft.com:

><< Perhaps the DROP(s) could be done when we UnPrepare the DBISAMQuery?
>(or
> when the program closes down if we never unprepare it). >>
>
> That may be more feasible - a CleanupSQL property that is executed
> once the script is unprepared.
>

I don't really feel it's worth the effort on your part.

except of course for ElevateDB

--
Chris