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.

Dixon Epperson


--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>
wrote:

> At 06:23 PM 24/02/2004 +0000, you wrote:
> >If I have two or more clients on a network create uniquely named
> >views, but they are looking at the same fields in the same
> >table . . .
> >
> >1) when I do an update or insert on the view, will that change the
> >underlying tables the views are based on?
>
> Yes, if the view itself is updatable. Many views are not, and can

be made

> so by the use of triggers.
>
>
> >2) will the will the modification of one client affect the view of
> >the other
>
> "View" has two meanings here. A view(1) is a database object - a

virtual

> table definition. And transaction isolation affects the view(2)

that each

> user has of database state. The view(2) that one user's

transaction sees

> through her view(1) depends on her transaction's isolation (and

others',

> including the other user's transaction looking through his view

(1)). Also,

> the view(2) seen by a view(1) depends on whether WITH CHECK OPTION

is used

> in view(1) creation - that will restrict the view(2) that the user

sees

> through his/her view(1). :-)
>
> >3) when I drop the view at the end of the routine, will that
> >rollback any insert / updates?
>
> If there is any pending work, you won't be allowed to drop the

view. The

> work must be committed or rolled back.
>
>
> >I use Delphi as the front end and for these data operations
>
> I don't think you understand what a view is. What it's NOT is

a "memory

> table" in the Delphi sense.
>
> Views are persistent database objects, not designed to be

interactively

> created and dropped from end-user applications. They have
> dependencies. They have (or are meant to have) privileges

assigned to

> them. The idea is to provide some kind of output set that is

tricky to get

> with a single DSQL statement and/or to restrict access to some

data in an

> underlying table.
>
> Some Delphi developers create views for all their queries so that

they can

> use TTables. That's not a desirable approach to client/server

development

> at all. Views should not be created and dropped by end users for

the

> purpose of doing ad hoc queries. The same goes for all database

objects.

>
> As a designer, you create flexible structures - including views -

that

> provide the data the application needs via queries. Views are a

way to

> surface structures that you wouldn't store in tables. What you can

aim to

> do is create a view and provide the users with an interface for

performing

> ad hoc queries on the view, i.e. your program offers selectors

from which

> the users pick or enter values for replaceable parameters in a

WHERE

> clause. (This is also the standard client/server technique for

queries on

> tables in Delphi). The TTable doesn't belong around a

client/server system.

>
> /heLen