You can use your favorite social network to register or link an existing account:
Or use your email address to register without a social network:
Sign in with these social networks:
Or enter your username and password
Forgot your password?
Yes, please link my existing account with for quick, secure access.
No, I would like to create a new account with my profile information.
Tips
How-to
News
Videos
Stories
Today’s tip is provided by Juan Soto, Senior Access Developer at AccessExperts.net. His blog is at AccessExperts.net/blog and you can subscribe to it by clicking here. Juan is a frequent speaker at Access user groups nationwide and was a participant in the last Access developers kitchen for Access 2010. He can be reached through his website or his blog.
The TempVars collection has the ability to save you time, improve the reliability of your programming and provide you with new ways to share information across your application.
TempVars were introduced starting in Access 2007 and represented a major addition to the arsenal of tools for professional developers. With it, developers can now store their global variables in a stable environment that will retain values regardless of program crashes.
Before TempVars, developers had limited choices when using application wide variables: module level variables; hidden forms or tables. There are drawbacks to each approach, with module variables being the worst since they initialize if your program encounters an error, losing their assigned values in the process.
Use TempVars Everywhere TempVars have no such limitation. They retain their values when your code encounters an error and can be used in Forms, Queries, Reports and code. You initialize them when your application starts and they disappear when your application terminates. In short, their a great way to share information across your program!
TempVars Collection The Add method is how you add new variables to the collection.
TempVars.Add Name, Value
Where Name is the name of your variable and Value is of course the value you wish to assign it. Some examples:
TempVars.Add "strAppName", "Test Application" TempVars.Add "lngClientID", 123456789 TempVars.Add "bolLoginAgain", True
Once assigned you can now use the value in your queries and code using the following methods:
TempVars!strAppName TempVars.Item("strAppName") TempVars.Item(0)
Remove Method Use this method to remove the variable or use RemoveAll to get rid of all of them.
Queries One particular advantage of using TempVars is their availability in queries, which you can't do with global variables without using a function. I created an entire multi-franchise database system using TempVars to differentiate between franchisee data. It made my life easier and improved the reliability of my application.
Conclusion I encourage you to start using TempVars in your code and your queries in place of module variables or classes, providing your users with a better experience and making your code more powerful.
Juan Soto
Send your Power Tips to accpower@microsoft.com.
Comments: (4) Collapse
Another long time workaround one can consider using a mde, or accDE. In a mde or accDE, then un-handled errors never re-set local or global vars. The other often not realized advantage of a mde/Accde is that un-handled errors don't cause the runtime edition to stop, or shutdown. In fact, your program just keeps on running without a problem. So, in addition to TempVars, one can consider using a mde, or accDE as another means to give you bullet proof variables that don't re-set on un-handled errors. This also means that class object variables also retain their values, and again do so regardless of errors occurring. However, in cases where you can't or are not using a mde/accDE, then TempVars are great use case. And, your tip and point about being able to use TempVars in a query without a function is even more useful. In fact, I am going to adopt this practice in both accDE and accDB applications for the future. Thanks for sharing this with us. Albert D. Kallal (Access MVP) Edmonton, Alberta Canada
I've not done any A2007/A2010-specific programming yet, so have had no opportunity to try the TempVars collection, but my main concern is that you're sacrificing strong data typing of variables. There are a whole host of ways besides global or module-level variables to store data in memory in a way that will survive a code reset, and retain the virtues of strong data typing. My main concern is that if all TempVars are variants, what's to stop you from storing something of the wrong data type? I looked at the documentation on MSDN and could see nothing about that at all.
From memory there is a maximum of 255 tempvars in a database. Tempvars are great in action queries TempVars!strAppName, especially ones that are used in exports (which fail when referencing form fields). Set them in code or a macro, plug them into the query and they magically turn up. Beats using functions for the same result.
David You are correct, there is no built in type checking, it is therefore up to the developer to maintain consistency in the code and use monikers such as str for String, lng for Long, etc. I look forward to your feedback once you start using 2007 or 2010, there many other great features you will enjoy, not the least of wish is the tab interface, which is my favorite. Kind Regards,
Juan ORIGINAL POST:
Comments: (loading) Collapse