Temporary tables

[Jon Cosby]

I've had problems with transactions in a Web application, mainly with people
leaving the page without finishing the transaction or canceling it. This
left me with "dummy" entries in the table, with no actual transaction or
related details. What I've done is create temporary tables to hold the data
until the transaction is complete, then adding it to the actual tables. This
works, but I'm wondering if it's a good practice?

 

[Arvin Meyer]

I've had problems with transactions in a Web application, mainly with people
leaving the page without finishing the transaction or canceling it. This
left me with "dummy" entries in the table, with no actual transaction or
related details. What I've done is create temporary tables to hold the data
until the transaction is complete, then adding it to the actual tables. This
works, but I'm wondering if it's a good practice?

Sure it's good practice. Anything that promotes data integrity without
adversely affecting performance and good design is most likely good
practice. In this case, the small performance loss caused by writing data
twice is offset by ensuring that you transactions are completed (or
discarded).
--
Arvin Meyer, MCP, MVP
Microsoft Access
Free Access downloads:
http://www.datastrat.com
http://www.mvps.org/access