John W. Colby
jwcolby at colbyconsulting.com
Wed May 18 13:54:39 CDT 2005
ROTFL. Why? Look at his statement to see the scale of lack of understanding. >unless I'm mistaken, math in VB is going to be just as fast as something in assembler Uh... No, by several orders of magnitude. John W. Colby www.ColbyConsulting.com Contribute your unused CPU cycles to a good cause: http://folding.stanford.edu/ -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Hale, Jim Sent: Wednesday, May 18, 2005 2:22 PM To: 'Access Developers discussion and problem solving' Subject: RE: Integers was:RE: [AccessD] Global Variable I'm only trying to figure out your metric for "good" vs "bad" programming. Jim Hale -----Original Message----- From: DWUTKA at marlow.com [mailto:DWUTKA at marlow.com] Sent: Wednesday, May 18, 2005 12:25 PM To: accessd at databaseadvisors.com Subject: Integers was:RE: [AccessD] Global Variable Now does that make sense? Where is the value in using a slower variable (Integer) to represent, let's say a month. Sure, the value is going to be 1 through 12, unless the calendar itself changes. If you use a Long Integer, for the same value, can it not store 1 through 12 also? Running faster? It's not a different language, so you can't compare going to assembler, from VB, besides, unless I'm mistaken, math in VB is going to be just as fast as something in assembler.... Drew -----Original Message----- From: Hale, Jim [mailto:Jim.Hale at fleetpride.com] Sent: Wednesday, May 18, 2005 12:08 PM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] Global Variable Okay Drew, you've completely confused me (which often is not all that hard to do). I thought it was always a "good" practice to type variables according to use. I use integers for things like months, loop counters (the infamous dim x),etc. and longs only when I know the number has a chance to exceed the integer limit. I hope you are not arguing integers are "bad" because they are less efficient, take up more cycles, etc. Using that standard we should all be programming using assembler. Jim Hale -----Original Message----- From: DWUTKA at marlow.com [mailto:DWUTKA at marlow.com] Sent: Wednesday, May 18, 2005 11:39 AM To: accessd at databaseadvisors.com Subject: RE: [AccessD] Global Variable LOL. Well, I did say that exceeding an Integer is possible, but that was a philosophical point. It could exceed 32k, in your example, if you decided to include an extended family tree. Either way, using an Integer is much slower then a Long Integer. Drew -----Original Message----- From: Scott Marcus [mailto:marcus at tsstech.com] Sent: Wednesday, May 18, 2005 7:41 AM To: Access Developers discussion and problem solving Subject: RE: [AccessD] Global Variable << Declaring a variables 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. Question: So when will the following declaration exceed the 32k, -32k limit? Dim intFamilyMembers as integer 'Number of immediate family members Answer: When you declare the variable as a Public (global) variable, then some other function written by some other developer changes its intended use causing the original function to possibly work incorrectly. Scott Marcus -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of DWUTKA at marlow.com Sent: Tuesday, May 17, 2005 7:05 PM To: accessd at databaseadvisors.com Subject: RE: [AccessD] Global Variable 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 *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email.