At 01:47 PM 25/02/2004 +0000, you wrote:

>Thanks Helen,
>I quit using the view because I suspected some of what you are
>saying. What I have a rather complicated sql statement with several
>aggregates that need to come to a intermediate stage. After that I
>need to do a check/conversion (if it fails the check) store in this
>intermediate stage and the send RAVE reports an sql statement for a
>report. It shouldn't be this complicated, but I always seem to have
>some obscure difficulty with RAVE.
>
>btw, I agree that a TTable shouldn't be anywheres near a SQL
>database and don't use them.
>
>What I needed was an intermediate storage place, like an in memory
>temp table. I don't know if this is the best way to do it, but it
>works. I create a temporary table using the work station name on
>the Firebird server. (actually, I check to see if the table already
>exist, and do a DELETE FROM .. if it does, if not then I create
>it). After I do a SELECT STATEMENT, do all the conversions, then I
>store it in this new table. I send RAVE an SQL statement for this
>temp table, generate the report, commit the transaction then drop
>the table.
>
>It seems to work pretty good. But if there is a better way to do
>it, I'm all ears.

Well, I would *never* do something like that. Basicially, if you can
create a temporary table to house the data, then you can do the same thing
with views and/or selectable stored procedures.

I think you mentioned that you can't use a SP (which I find strange..) but
there is nothing to prevent you from creating your "temporary" table as a
view instead, and then creating another view that selects what you need
from the first view. (Not at runtime, natch!!!)

At runtime, pass WHERE clause parameters to the second view (or input
parameters to a SP, my preference, because you are apparently doing some
run-time validity checking). Creating temporary objects is a crock: you've
got one user trying to delete an object that another user created.

/heLen