Hans, When you use a TEMP table, it exists only on your machine (whereever you set your environment) so only you are interacting with it. Other users do not see it at all. Therefore you can manipulate the data all you want until you decide to put it back through programming.
And if you are sloppy like me, they automatically disappear when you DISConnect from the main database. I resisted using temp tables for a long time, but once I understood them they have become a fantastic tool. Especially once you understand that you can have a row with computed columns that can do a lot of the work for you. Jan -----Original Message----- From: "Hans Manhave" <[email protected]> To: [email protected] (RBASE-L Mailing List) Date: Thu, 16 Jun 2011 14:52:53 -0500 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] 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 Sent: Thursday, June 16, 2011 8:18 AM To: RBASE-L Mailing List 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
