Scott Marcus
marcus at tsstech.com
Wed May 18 12:50:34 CDT 2005
Drew, Do you have any applications with more than 20 global variables? Scott Marcus -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of DWUTKA at marlow.com Sent: Wednesday, May 18, 2005 11:04 AM To: accessd at databaseadvisors.com Subject: RE: [AccessD] Global Variable That's another reason to use the proper scope, true, but it certainly isn't a reason to limit the properly scoped variables. True? Drew -----Original Message----- From: Francisco Tapia [mailto:fhtapia at gmail.com] Sent: Tuesday, May 17, 2005 11:04 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Global Variable Well I suppose that one reason to use Public variables sparingly is that you encapsulate your code modules so they don't cross over to other modules, and therefore are more re-useable. That is, A variable name defined in a lower scope won't ever be called in another scope and you can easily pick up the code and re-use it anywhere else it might be needed. Likewise the less places you call and set a variable will make it easier to maintain your application. This is not at all like saving user settings, as you'd be placing them all in the same object (db, collection, file etc...) but the method to access it would be handled via another module / function, and thus you'd be calling it, not setting variables. my 2 cents worth. On 5/17/05, DWUTKA at marlow.com <DWUTKA at marlow.com> wrote: > > I guess I'm not seeing the same definition from John, though it was closer > in the last few posts. Yes, 'bad practice' sends me into a tail spin, when > there is no reason for calling something bad practice. Declaring a > variable > as an Integer IS bad practice. It is bad practice because even if you > think > a variable will never go over 32k, or below -32k, it can, and probably > will. > But more importantly, an Integer is a 16 bit variable, and it takes longer > to process an Integer then it does a Long Integer, on a 32 bit system. The > first reason is a philosophy. The second reason is a FACT! > > I have yet to hear a fact, as to why Globals are 'bad practice'. What gets > my goat, though, is that this is a forum where developers of all skill > level > meet. If opinions are given as facts, developers who are learning > something > new could be hampered by prejudice. Ever run into an IT shop that refuses > to allow applications to be developed in Access, because 'it's not a > database', or 'it's not secure', or something else, that is just ignorance > repeated through 'tribal knowledge'? (There is also usually power > involved...and IT shop has more power and control involved when something > is > on a server side db.) That's why I rail on this stuff, because invalid > tribal knowledge can be dangerous! > > Drew > > -- -Francisco http://pcthis.blogspot.com |PC news with out the jargon! http://sqlthis.blogspot.com | Tsql and More... -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com NOTICE: This electronic mail transmission is for the use of the named individual or entity to which it is directed and may contain information that is privileged or confidential. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of any information contained herein is prohibited. If you have received this electronic mail transmission in error, delete it from your system without copying or forwarding, and notify the sender of the error by replying via email or by calling TSS Technologies at (513) 772-7000, so our address record can be corrected. Any information included in this email is provided on an “as is” and “where is” basis, and TSS Technologies makes no representations or warranties of any kind with respect to the completeness or accuracy of the information contained in this email, or with respect to any other matters communicated in this email. TSS Technologies hereby disclaims any and all express or implied warranties of any kind. Nothing in this email shall be construed to create any kind of contractual or binding agreement or commitment by or on behalf of TSS Technologies, Inc., the recipient, or any third-parties.