Subject Re: [Firebird-Architect] RFC: Proposal for the implementation of Temporary Tables.
Author Martijn Tonies
> > Actually, it would be easier if maintained by the server -
> > For example, what do you do if the connection fails?
> > The server can cleanup the table after you, while you - with
> > your own mechanism - cannot, as you do not know that
> > your "attachment ID" is no longer a valid one.
> >
> > Also, in all your procedures/queries/etc, there's no longer a
> > need to write:
> > "AND ATTACHMENTID = :MyID"
>
> Swings and roundabouts. Because of the way I use the data, if the
> connection is lost I don't necessarily want to loose the data. Latest
> one is Terminal Server crashes requiring the user to log in again. At
> present I CAN just pick up where they left off rather than start again.
>
> In the longer term, *I* will need to maintain this 'temporary' data
> across 'sessions' in PHP, and the connection is currently not maintained
> which may be the wrong way of doing things, but means I am not tied to
> the one web server.
>
> There will always be some users who can't use 'automatic' functions ;)

True :-)

The other way around though, makes more sense: there are probably
plenty of people who would rather use an automatic function than
rolling their own :-)

With regards,

Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server.
Upscene Productions
http://www.upscene.com