Hans,
I use the temp table approach for entering our quotes or orders. The key is when the row is finally ready to be inserted into the permanent table is to check (with code) for any duplicates then having a way to change the primary information on the fly, so to speak. In our instance, the code checks to see if the quoteID (or OrderID) is in the permanent table then changing it to a unique ID if there is already that ID in the table. That way multiple persons can enter into the same table without duplication. James Belisle ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Hans Manhave Sent: Thursday, June 16, 2011 2:53 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: temporary tables I'm showing my ignorance, but I would like to understand. With many people accessing the same database and using temp tables which (I learned today in this thread) are local to the user, how is record locking handled? Does the act of putting records in a temp table lock them in the master table? How does one control the next person needing the same record for the same or another purpose? Thanks, Hans From: [email protected] [mailto:[email protected]] On Behalf Of William Stacy Sent: Thursday, June 16, 2011 2:22 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: temporary tables I'm sure I will, since speed is of the essence in a busy practice. Now that I have 7 stations accessing the server at the same time, with increasing activity and an ever-enlarging database, even my rocket ship has gone sub-light speed. In a huge practice, the need for temp tables becomes very probable. On Thu, Jun 16, 2011 at 12:12 PM, Javier Valencia <[email protected]> wrote: William, My user would not know how to use a table either, other than through menus. However, I use temporary tables extensively behind the scenes and end users do not have a hint, other that the improved performance. Since temporary tables are stored in memory on the local computer, they provide a measurable increase in performance. Temporary tables is (are?) one of the better R:Base features. Give it a try...you will like it... Javier, Javier Valencia, PE 913-829-0888 Office 913-915-3137 Cell 913-649-2904 Fax [email protected] <mailto:[email protected]> ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of William Stacy Sent: Thursday, June 16, 2011 1:32 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: temporary tables In my app end users know how to handle the phone, patients, appointments, payments and the like. I can't imagine them ever doing any table level stuff. Plus there's the issue of data loss. Transactions in medical apps need to be remembered with paper (virtual paper, that is) trails, etc. Deletions and revisions after the date of transactions are not permitted. On Thu, Jun 16, 2011 at 10:38 AM, Dan Goldberg <[email protected]> wrote: Temporary tables are only seen by the user that created them. So each user can have unique data that pertains to them looking at the same form. Speed is definitely a plus at times. Sometimes I use temp tables to organize and format the data before the report generates the output. It just depends on the need. I use them all the time. Dan Goldberg From: William Stacy <mailto:[email protected]> Sent: Thursday, June 16, 2011 8:18 AM To: RBASE-L Mailing List <mailto:[email protected]> Subject: [RBASE-L] - temporary tables Is the push for using temp tables based on processing speed, data safety, a combo, or what else? -- William Stacy, O.D. Please visit my website by clicking on : http://www.folsomeye.net -- William Stacy, O.D. Please visit my website by clicking on : http://www.folsomeye.net -- William Stacy, O.D. Please visit my website by clicking on : http://www.folsomeye.net
