Tina Norris Fields
tinanfields at torchlake.com
Mon Jul 1 16:37:56 CDT 2013
Ohhhhhhhh!!! That is exactly what I ran into in one client's existing database. It was an oil & gas well company. They have an EPA report obligation. There was report named EPA-Report. There was a query named EPA-Report, and there was a table named EPA-Report. I did get those straightened out, but I didn't stick around with this client because 1 - the boss already knew everything and could not be taught anything new - and - 2 - the needs of the company as presented by the boss were a constantly moving target I got out as quickly as I could. TNF Tina Norris Fields tinanfields-at-torchlake-dot-com 231-322-2787 On 7/1/2013 12:26 PM, Charlotte Foust wrote: > Does that mean you can now have a query and a table of the same name?? > > Charlotte > > On Mon, Jul 1, 2013 at 9:18 AM, David McAfee <davidmcafee at gmail.com> wrote: > >> I still prefer to use Hungarian prefixes for variable names (and tbl, vw, >> stp... for table, view and sproc names). >> >> My younger coworkers love the new way of "not" doing that. >> They explain how you can click or hover on a variable too see what it is. >> >> I love not needing to. just looking at it tells me what it is. >> >> I guess I'm just getting old. >> >> >> >> D >> >> >> On Mon, Jul 1, 2013 at 9:11 AM, Jim Dettman <jimdettman at verizon.net> >> wrote: >> >>> To add to that, right click/define didn't exist in Access Basic either, >> so >>> it was a real hunt back then to find where (and how) you declared a >>> variable. >>> >>> Jim. >>> >>> -----Original Message----- >>> From: accessd-bounces at databaseadvisors.com >>> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John W Colby >>> Sent: Monday, July 01, 2013 11:31 AM >>> To: Access Developers discussion and problem solving >>> Subject: Re: [AccessD] VBA Field Names - Curiosity Question >>> >>> I think the practice started simply because the dim statement can be in >>> many >>> different locations in >>> VBA. It can be in a global module (global to all modules) , or it can be >>> in >>> the header of the >>> module (global to the module) that it is used in or it can be in the >>> function where it is used >>> (local to the function). It is useful to know what datatype something is >>> when you are trying to >>> manipulate it. Multiplying a string with an int is going to cause >>> problems. >>> >>> OTOH, strMyVar * intMyOtherVar makes it immediately obvious that we don't >>> want to do that. >>> Instr(intMyOtherVar...) is immediately obvious. Many issues will compile >>> but give run time errors. >>> Corner cases that only run once a year can cause nightmares to resolve. >>> >>> Just because language practices 40 years ago doesn't do something doesn't >>> necessarily mean that it >>> is bad idea. >>> >>> John W. Colby >>> >>> Reality is what refuses to go away >>> when you do not believe in it >>> >>> On 7/1/2013 11:01 AM, Brad Marks wrote: >>>> All, >>>> >>>> In a prior life, I was sentenced to work with COBOL for over 30 years. >>>> For the past three years, I spend my time in the world of VBA. >>>> >>>> Since starting to work with VBA, I have been curious about something, >>>> but have never asked about it. >>>> >>>> In the COBOL realm (at least where I worked), we did not indicate the >>>> field type in the field name. >>>> >>>> Examples - >>>> 01 Part-Number PICTURE X(30). >>>> 01 Part-Cost Comp-3 PICTURE 9(05). >>>> >>>> >>>> In VBA examples, I see most people using prefixes such as Str, Lng, >> Dat, >>>> Etc. >>>> >>>> I have never quite understood why people do this when working with VBA >>>> while I believe that very few people did this in the COBOL realm. >>>> >>>> In COBOL we would simply look at the Picture clause in the field name >>>> definition. This would be the equivalent of looking at the DIM >>>> statement. >>>> >>>> Again, this is just a curiosity question. >>>> >>>> Thanks, >>>> Brad >>>> >>> -- >>> 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 >>> >> -- >> AccessD mailing list >> AccessD at databaseadvisors.com >> http://databaseadvisors.com/mailman/listinfo/accessd >> Website: http://www.databaseadvisors.com >>