Re: Which is best - recordsets/VBA V SQL statements for updating data
- From: Bri <not@xxxxxxxx>
- Date: Thu, 05 Jan 2006 01:50:31 GMT
Lyle Fairfield wrote:
I think I'll withdraw and leave the field to you. Without a deep understanding of what actually happens with the POS / Billing stuff I shouldn't suggest anything and I won't. If you've analyzed the problem, etc, etc and concluded a temp table is called for, then by all means go for it.
Well, I couldn't think of any other way to do it. That isn't the same as 'there is no other way to do it'. I'm always looking for better ways of doing things.
Do you create your temp table within a Transaction and RollBack the Transaction when you're done with it? That way the Temporary Table is never saved and your DB is unmodified.
Not in this case, but I have used that technique elsewhere. I don't use it often either, but there are times where it comes in handy.
But a Report or Form cannot use
such a Temp Table; TTBOMK Access Objects can use only Tables etc that
appear in the DB window.
That hits the nail on the head for my POS form. The temp table is in a separate MDB and is permenantly linked. The table always exists, so it is in the DB Window. It has data added to it in the POS screen. Once the order has been finished and payment has been received, the data is Inserted from the temp table to the Billing table via an INSERT TO query and then deleted from the temp table. So, the temp table is really a Batch proccess collection. The MDB with the temp table in it is compacted when the app is open, each user has their own copy of the temp table MDB in their TEMP folder.
I did in a previous post in this thread state that my definition of temp table in this instance was the the data was temporary, ie the table was a place to temporarily hold data. This isn't the same as a table created, used and then deleted all in code. If I do this I always enclose it in a Transaction as per your above suggestion.
Since this discussion is getting OT I'll bring this back around to the original topic of this thread; I use SQL to move the data from the temp tabel to the Billing table, I do not walk the recordset and do separate inserts for each record.
-- Bri
.
- Follow-Ups:
- Re: Which is best - recordsets/VBA V SQL statements for updating data
- From: David W. Fenton
- Re: Which is best - recordsets/VBA V SQL statements for updating data
- References:
- Which is best - recordsets/VBA V SQL statements for updating data
- From: Jeff
- Re: Which is best - recordsets/VBA V SQL statements for updating data
- From: Lyle Fairfield
- Re: Which is best - recordsets/VBA V SQL statements for updating data
- From: Jeff
- Re: Which is best - recordsets/VBA V SQL statements for updating data
- From: Lyle Fairfield
- Re: Which is best - recordsets/VBA V SQL statements for updating data
- From: Bri
- Re: Which is best - recordsets/VBA V SQL statements for updating data
- From: Jeff
- Re: Which is best - recordsets/VBA V SQL statements for updating data
- From: Lyle Fairfield
- Re: Which is best - recordsets/VBA V SQL statements for updating data
- From: Bri
- Re: Which is best - recordsets/VBA V SQL statements for updating data
- From: Lyle Fairfield
- Re: Which is best - recordsets/VBA V SQL statements for updating data
- From: Bri
- Re: Which is best - recordsets/VBA V SQL statements for updating data
- From: Lyle Fairfield
- Re: Which is best - recordsets/VBA V SQL statements for updating data
- From: Bri
- Re: Which is best - recordsets/VBA V SQL statements for updating data
- From: Lyle Fairfield
- Which is best - recordsets/VBA V SQL statements for updating data
- Prev by Date: Re: Problems while making MDE
- Next by Date: Re: Which hardware upgrades are more important
- Previous by thread: Re: Which is best - recordsets/VBA V SQL statements for updating data
- Next by thread: Re: Which is best - recordsets/VBA V SQL statements for updating data
- Index(es):
Relevant Pages
|