you might start writing toward adherence to the stricter permissions of Vista and up using the "current logged in windows user"\Application Data folder for your target, you will avoid the issues with C:\TEMP collecting everything.
It is more difficult to start with because of the spaces in the pathname, but you can develop a standard Stored Procedure to return the pathname correctly and another to wrap in double quotes when required. ----- Original Message ----- From: "Karen Tellef" <[email protected]> To: "RBASE-L Mailing List" <[email protected]> Sent: Tuesday, January 08, 2013 12:05 PM Subject: [RBASE-L] - Re: Thoughts about temp tables? Tony: I've been paying more attention to column naming conventions in temp tables recently too. One thing I do is for text columns, I always include the number of characters. So ClientName45 would have a datatype of Text 45, in case somewhere else someone defines a ClientName of only 40. And I sometimes put a "tmp" in front of the column names to distinguish from real columns. Sorry, but I REFUSE to use underscores in my table / column / variable names! Too hard to type and looks too jumbled for my eyes.... That would be another topic! Karen -----Original Message----- From: Tony IJntema <[email protected]> To: RBASE-L Mailing List <[email protected]> Sent: Tue, Jan 8, 2013 10:57 am Subject: [RBASE-L] - RE: Thoughts about temp tables? Karen, Most of the time I create the needed temp tables as an ordinary permanent table in the database. They even sometimes contain some data, which can be useful for testing Then I make use of the project statement to create the temp table. The temp table has the same name as the original, but it starts with T_ . The used where clause in this case could be ‘where limit = 0’. An empty temp table is the result of the project statement. Of course for safety reasons you better start with the drop statement. In this way I think you will not be confronted by the error you have encountered and the used temp tables are visible for anyone in the project Secondly I make use of a strict naming convention for the tables and columns. In 9.5 64 there are no real limits in the length of a table and column name anymore. Every tables starts with an abbreviation like CMR_Customer and every column in that table starts with CMR_ , unless it is a foreign key The primary key is always CMR_ID. If it is used as an foreign key you easily can see to which table it belongs. Tony From: [email protected] [mailto:[email protected]] On Behalf Of Karen Tellef Sent: dinsdag 8 januari 2013 17:18 To: RBASE-L Mailing List Subject: [RBASE-L] - Thoughts about temp tables? Since the list has been slow, let me throw a question out there. When you write a program that uses temp tables, do you leave the temp tables out there? Or do you delete them? I always leave them, simply because I sometimes want to get to the r> prompt and look at the temp table. I'm not sure whether there's any space/memory/performance issues with having them there. The reason it comes to mind is that last week I had a program fail, and it turns out that another programmer on this client (we work as a team) and I happened to pick the same name for a column to use in a temp table, and of course we used a different data type! If I work alone I have a pretty good memory of what I might have used for temp table column names (although not 100%). And I try to use existing column names whenever possible. What do you do? Karen
