QUOTE (mrpersonality @ Apr 10 2012, 05:05 AM)
using Set m_rstTotalStarts = CurrentDb.OpenRecordset("SELECT I
raises an error
Yes, notice how the SELECT tapers off and is snipped. The select statement as above is also incorrect and the OpenRecordSet command you posted above also will not work!
It is simply a partial code snip and the suggestion was/is to move ALL of that move first code ETC ETC ETC to the code part where you load up the reocordsets so you don't have to repeat the movefirst/movelast a zillion times everywhere else in the code.
You still have to have the if recordcount > 0, and for any property code that has to iterate records, then have to always include a move first.
So the above was just some "air code" code here. So keep in mind that not only did that code snip leave out the "if" test for records, but if you look close the select string has no closing quotes, and is also not valid SQL (so that part as posted is also wrong).
So the suggesting here is for most of the cases you have, you can remove the moveirst/move last and clean up a good bit of code, and place such actions on the reocrdsets into one place (the place where you initial load up the reocrdsets).
It just seems there is little need to repeat the code over and over in a whole bunch of places when it can be done right after the recordset open.
And as for some difference in opinions as to best practices, you basically only have two choices
You appeal to a higher authority with books, authors and others who have been down these roads, and can produce examples. Because this is not firsthand knowledge, then in these cases you are actually having to make an act of faith here until such knowledge becomes first hand or verified through your own experiences.
In other words we are the ones bearing witness for you on these development practices, and you have to accept or reject our testimony in these matters. In fact it is actually 100% truthful and honest to state that you having to make an act of faith here!
And overtime when you experience is these practices then they'll become something other than the witness and testimony of others – it will then become YOUR own firsthand knowledge.
The overall often stated goal of using a class object is the concept of encapsulation. However by me suggesting that some of these members that you create (variables) in some developer circles is considered a bad practice to make them public.
However I have enough experience to know when these rules make sense and when these rules don't make sense. So I don't have to appeal to a higher authority, some book or some author and make an act of faith, but now have gained that firsthand experience.
In other words, in the vast majority of exposing some of these public members, you're not going to pay a penalty or cost for doing so, and as I pointed out there is actually more benefits than downsides of doing so.
In other words if somebody has an example of coding (not some reference to a book or testimony from others), but that of their OWN firsthand experience of showing why and when and how exposing those public members cost them developer time or caused bugs, then they have to step forward to demonstrate and share that experience to convince anybody of such positions.
For example, I have the frown upon using global variables to pass values between form or standard subroutines (I'm talking about general coding practices here, not class objects). In other words over the years when I have to pass some values between forms, I very rarely use global variables, and the same thing to pass values between sub/function routines. The reason is of course over the years using global variables has cost me lots of money and time, and has resulted in lost productivity. In other words I can't copy those forms, or copy the code, or have multiple instances of those forms and cold running when I utilize global variables. And if I copy such routines are forms between different applications, or even in the current application, then I have to painstakingly hunt down all of the global variable dependencies.
I had code routines that after 10+ years of extensive modifications that are well into the thousands of lines of code all of a sudden need to have another instance of that code running. And unfortunately that code had utilized tons and tons of global variables over a period of 10 years with extensive development. If we had insisted from day one that no global variables were to be used in these routines, and it was reasonably possible to do so, then we could have now had multiple instances of that code able to run and be used. Unfortunately some of the work arounds were to launch a whole another instance of the whole application, but we eventually forced buckle down and rewrote that whole module to run on local variables (and turns out that this was anon access application, and in fact was my own custom forms design package).
In other words over the years due to bad programming practices, and simply the desire to cut some corners, we did not care that we were using global variables. The result was that 10 years later we got to a point where we probably did not save any development time at all! In other words as always the developer practices you adopt must produce a tangible positive result.
In the case of exposing members of class objects? Well if it just a variable that's going to be modified in code by a get/let pair, then there is no obvious inherent benefits or even further additional encapsulation that I can see. And MORE important is over 10+ years of such a coding practice we NEVER had any practical downsides in adopting such a practice.
However if you run a team with 20 developers, and they're all going to be interactively coding writing and developing and using a set of class objects developed by many different people, it's very possible that you might have to increase the requirement and demands that developers use extra caution and tighten things up a bit in terms of how members of a class object are to be created and exposed.
Again a good developer will know when to break the rules, and when these decisions make the best sense.
If a mechanic is working on a small airplane and by accident they drop a sparkplug, they have to pick that sparkplug up and throw it in the garbage can. The reason is that dropping the sparkplug may have cracked it (they been inspected). Such a simple sparkplug failure could result down the road in a failure of the small engine. A loss of some power or engine failure in a small plane can be disastrous.
However dropping the same spark plug on the floor that you're about to change in your own lawnmower is absolutely of no consequence at all. And I suspect utilizing that spark plug in your automobile in 99% of the cases will also not be a problem. And in the leftover 1% of the cases it's really not that significant in your car or lawnmower. The risk and downside is not an issue, but in the 1% cases for an airplane, then this becomes a significant issue.
I can assure you in all cases all these development practices are not all or nothing propositions. However for those that don't have the experience that I have, then often you're going to have to appeal to some book or some development practice that says don't do this or that, and you're going to have to blindly follow that advice until you gain the experience like I have to know when such advice actually really make sense.
And I'm pretty confident public to state freely that I DO know these issues and that I have gained that knowledge and experience to make my above claims.
Like everything, the advice of being careful with that sparkplug is not the same advice that applies to your lawn mower as opposed to an aircraft.
So in terms of experiences with avoiding global variables, I can post examples and give you stories of my experience were such coding practices have cost me dearly. And I can also freely state that in every development project, exposing some of these class members as public has NEVER been a problem ever, and this is especially in the case that if it's just simply a value that's being modified by a pair of let/gets.
And in the case of exposing record sets? You can't accidentally modify a record set unless you put it into edit mode (and in fact one might eventually even want to do that). And I think if you don't need those record sets to be utilized from code outside of the class module, then I absolutely 100% agree that they should not be made public.
In other words don't be afraid to expose them if you need them! However the reverse is true, if you don't need any code outside of the class object to directly use those record sets, then there's no need it all to make them public and expose them.
Thus the terms of BEST development practices is going to be very much dependent on the CONTEXT and how your utilizing those objects and what are the resources and type of developer teams and projects you're working on.
And I have no fundamental disagreement with any of the other comments here, and they all contribute to this discussion in a great and useful way, and I welcome any other comments on the points I've made above or any others here!
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada