|Subject||Re: [Firebird-Architect] RFC: Proposal for the implementation of Temporary Tables.|
> > Actually, it would be easier if maintained by the server -True :-)
> > 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 ;)
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 :-)
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL