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