At 03:21 PM 9/16/2004, Scott Taylor wrote:

>So if I have an application that generates a temp table called 'stuff' and
>two people are running this app, will I be creating two tables called
>'stuff'?

Yes.

>I think that should be done at the client, in a temp file as I already do,
>just to save confusion.

The absence of temporary tables is one of the most common
stumbling blocks for programmers moving from other databases.
Temporary tables are also a pretty good model for the way
most people think about problems - take a wide first cut,
refine it, add to it, refine it some more, repeat, then study
the result. Yes, it would be more efficient and elegant to
express the whole thought in a single statement, but who has
that much time?

> What if the client disconnects poorly (like
>Windoze crashing) and leaves these temp tables hanging about the DB?

The architecture/implementation will avoid that problem.

> > I suspect that works very very badly for tools that
> > do connection pooling and those that use multiple connections.
>
>There should be a way to view and manage temp tables if they are going to
>be stored in DB space. :(

Who says they're stored at all? They're ephemeral. They just
look real to the attachment that's using them.


Regards,


Ann