An application we are currently working with uses a 80-columns
temp-table, which contains dummy-fields of almost every size and type.
Some 40 VChars, some numerics, some integers, some dates, times and
timestamps and so on....
The app adds a transaction-id, and pumps in all its data. Other users
from other machines use the very same table with a different transaction
id and therefore, visibility and concurrency is guaranteed. The app
writes its data into the table, builds its report with the
transaction-id in the where-clause, and deletes its records after
successful operation. The server runs batch-tasks to clean the table, if
a connection bumps or something else goes wrong.
Ah, forget to mention: The temp-table resides in a different database as
the application-data, as pumping these large amounts of data and
reallocating the space every time would add unnecessary load to the
oltp-database.Typically, with IBO you won't have problems puming the
data from one db to another, and the other users of the app will thank
you for the better performance.

Cu, Nick

> -----Original Message-----
> From: bobzirbel@... [mailto:bobzirbel@...]
> Sent: Wednesday, July 25, 2001 9:58 AM
> To: IBObjects@yahoogroups.com
> Subject: Re: [IBO] Object in use when dropping table
>
> Thanks for your comment Svein.
>
> What do you suggest I do if you shouldn't create temporary tables 'on
> the fly'?
>
> > I was about to send the same message as you, Lester, but then I
> asked Aage
> > and he said that this limitation is not to the database, but to
> each table.
> > So Bob may be unlucky enough to escape these problems - unlucky
> because
> > even though it may work, it is not very good practise to use DDL
> (Data
> > Definition Language) in a normal application.
>
>
>
> ------------------------ Yahoo! Groups Sponsor
>
>
>
> Your use of Yahoo! Groups is subject to

http://docs.yahoo.com/info/terms/

>