TempVars vs Type Variables

[Isaac]

at the time I answered that question, my wife was calling me downstairs for a spot "honey do" task.

It's one of those days ... My task today was washing the bathtub. When I was done she came in to glance at it and I shined my phone's flashlight at it so it appeared to be glistening

 

[Pat Hartman]

I stuck with the form because in addition to being able to support all the variables I needed, I had the ability to make them visible which was a huge help when I was testing new features. I could change the values without having to log off and log on again.

 

[CJ_London]

my view on tempvars is they are another prop/method for simplifying things for those who don't want or have the time to do things properly. Ok they can be referenced in queries - so can a function or reference to a form control. To my mind their main difference is they retain their value in the event of crash - so the developer can simply say 'click the continue button' and carry on and not bother with proficient error handling.

I'm old school and develop solid and reliable applications but I do accept there are a lot of users out there who just want something to work, even if it limps along (much to the bane of IT departments) and for them a tempvar is potentially a big help - much the same as MVF's and attachment fields. After all, Access is a RAD tool and not intended as a tool for developing world class applications. That said, I've developed a large number of apps for clients large and small which are solid and reliable and meet their requirements to the extent they do not need to go looking for a world class solution

 

[Isaac]

much to the bane of IT departments

You can say that again!

The more often we can develop quality Access apps (esp. front end only), the less I.T. will "hate Access".

 

[The_Doc_Man]

so the developer can simply say 'click the continue button' and carry on

The "Continue" option is not always available if you are not robust in your error handling.

Access is a RAD tool and not intended as a tool for developing world class applications.

The U.S. Navy Bureau of Medicine (BUMED to those who understand Navy-speak) has an Access front-end that was developed in pure Access but then upconverted to full-blown SQL Server with an Access FE. It served the Navy's Medical Officer Training Scholarship program. That is fairly world-class and well within the normal use of Access.

 

[Gasman]

my view on tempvars is they are another prop/method for simplifying things for those who don't want or have the time to do things properly. Ok they can be referenced in queries - so can a function or reference to a form control. To my mind their main difference is they retain their value in the event of crash - so the developer can simply say 'click the continue button' and carry on and not bother with proficient error handling.

I'm old school and develop solid and reliable applications but I do accept there are a lot of users out there who just want something to work, even if it limps along (much to the bane of IT departments) and for them a tempvar is potentially a big help - much the same as MVF's and attachment fields. After all, Access is a RAD tool and not intended as a tool for developing world class applications. That said, I've developed a large number of apps for clients large and small which are solid and reliable and meet their requirements to the extent they do not need to go looking for a world class solution

My thoughts were, if you put a form reference in the query criteria, then that query is tied to that form?
I wanted the queries to be used from more than just one form.? That seemed a good way to do it?

When I worked as an admin person in a bank a few years back, IT would not supply what the department needed, so they asked me to create them something to use.?
The IT dept still charged my dept £11K to vet it for governance, when the CEO found out about this DB.
Any of the experts here could have vetted it in a day.