A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Access » Database Design
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)



 
 
Thread Tools Display Modes
  #21  
Old July 13th, 2006, 10:28 PM posted to microsoft.public.access.adp.sqlserver,microsoft.public.access.tablesdbdesign
Robert Morley
external usenet poster
 
Posts: 113
Default Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)

Unless what used to be a table is now a view, (or vice versa, though less
likely). Access does not easily provide the tools to go hunting through
every reference to "tblSomething" and change it to "vwSomething". Nor,
for that matter, "txtDescriptionType" to "cboDescriptionType", but that
is a different argument.


Yes, I've run into that problem. I currently view called "tblPreferences",
which is a hanger-on from when tblPreferences was stored as a local table in
a replicated MDB, but then got upsized to SQL Server and had to be done as a
view based on the current user.

There are a number of good search & replace utilities for Access...for some
reason, I just haven't gotten around to using it on tblPreferences yet!

To be fair, it was Microsoft itself that pushed Hungarian notation as its
own house style. I don't believe that the company ever understood how
good Access was and they don't seem to have cared either. As for the
programming style, they have now reverted completely, and prefixes are
AbsolutelyOut for anything based on the new versions of VisualStudio --
or should that be visualStudio?


Yes, so I've heard. Personally, I don't give a rat's ass what's in or
out...as many have said, I use what works best for me (and since my
programming team at work is a whole two people, and I'm the lead programmer,
it pretty much works that way there, too grin).



Rob


  #22  
Old July 13th, 2006, 10:46 PM posted to microsoft.public.access.adp.sqlserver,microsoft.public.access.tablesdbdesign
Robert Morley
external usenet poster
 
Posts: 113
Default Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)

Yes, I've run into that problem. I currently view called
"tblPreferences",


Ummm...apparently I'm just randomly dropping words from sentences. That was
supposed to read "I currently have a view", of course. blush



Rob


  #23  
Old July 14th, 2006, 08:49 AM posted to microsoft.public.access.adp.sqlserver,microsoft.public.access.tablesdbdesign
onedaywhen
external usenet poster
 
Posts: 124
Default Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)


Robert Morley wrote:
Like I said, for myself, I don't generally stick to simply "tbl" or "vw" or
whatever unless there's no other logical prefix


He's a idea for you: if there is no *logical* prefix (i.e. the table's
name already conveys meaning) then don't use a prefix that conveys its
*physical* implementation. At best it's redundant, worse it's mixing
logical and physical models.

Jamie.

--

  #24  
Old July 14th, 2006, 09:17 AM posted to microsoft.public.access.adp.sqlserver,microsoft.public.access.tablesdbdesign
onedaywhen
external usenet poster
 
Posts: 124
Default Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)


BruceM wrote:
I learned about a naming
convention that makes sense, so I started using it, and found it to be
helpful.


Did you browse the whole 'naming conventions' aisle before making your
choice?

It's interesting how much of the discussion is about how using one system or
another will appear in the eyes of somebody else.
Did you choose the
naming convention you use because you "wannabe" like somebody else?


Of course. When I started dabbling in WordBasic, I used logical terms
for variable names; I was working in the office of the board of
directors and wore a blazer, slacks and smart shiny shoes to the
office.

I wanted to move into VBA software development so, to be taken
seriously by what I hoped would be my peers, I adopted the naming
convention lng- for Long Integer, str- for String, dtm- for Date, etc.
These prefixes did not add value for me personally: the variable name
told me how I was using it and hence conveyed the data type, the prefix
seemed to be redundant and jar.

Luckily in my SQL career I took the 'standard SQL' path from day one
and never got into the whole 'tbl', 'fields' and other Access
conventions. When I first started using .NET I was very relieved that
the convention has moved away from data type prefixes to logical
variable names; I still use the prefixes in VBA, though sometimes I
can't be bothered and stick with the .NET convention. I was amused the
other day to see an MVP using camelCase for their Access column -
sorry, field - names g.

And, yes, I use the standard SQL terms column (in place of 'field'),
VIEW (in place of 'Query'), 'DECIMAL' (in place of 'Currency' g), a
relational/industry standard key (in place of 'autonumber' vbg) to
encourage others to look outside of the Access ghetto in the hope they
may benefit as I have.

Oh and today I'm wearing a t-shirt and jeans (because sometimes you
need to fit in) with walking boots (because sometimes you need to do
what makes practical sense).

Jamie.

--

  #25  
Old July 14th, 2006, 09:27 AM posted to microsoft.public.access.adp.sqlserver,microsoft.public.access.tablesdbdesign
Vayse
external usenet poster
 
Posts: 15
Default Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)

"Tim Ferguson" wrote in message
...
programming style, they have now reverted completely, and prefixes are
AbsolutelyOut for anything based on the new versions of VisualStudio --
or should that be visualStudio?


I have to do a lot of vb.net work, and I find the new naming convention a
bit awkard. New MS articles insist on dropping the o for object, as
everything is an object now. And cls for class is gone as well, of course.
But there are still some 2003 and older articles amongst the help files,
where they have different naming conventions. But thats not too bad, its
easy enough to get used to.
My old way: Dim oClient as New clsClient
New way: Dim SalesClient as New Client
It does mean thinking of names though! Like having to use SalesClient in
this sample.

What really gets me is the names on forms. So instead of gridClients, its
now ClientsDataGridView. And then theres ClientNameTextBox. Its very hard to
get used to, after years of txtClientName!
In some ways it makes sense. All your Client objects are grouped together.
But I think I'll keep to the old ways in Access. Though I may not be able to
keep up two naming conventions for ever.
Diarmuid


  #26  
Old July 14th, 2006, 11:27 AM posted to microsoft.public.access.adp.sqlserver,microsoft.public.access.tablesdbdesign
david epsom dot com dot au
external usenet poster
 
Posts: 75
Default Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)

Furthermore, FORTRAN, the FORmula TRANslation language, was often
used for formulas, where i,j, and k were indexes to an Array. This
was a notation that predated computers.

We got the word 'array' from the same source: if FORTRAN had not
been used by engineers and mathematicians, we probably would have
had a 'table' instead, which is what we now call that construct
when we use Access to save it to disk and read it back again.

(david)

"Sylvain Lafontaine" sylvain aei ca (fill the blanks, no spam please)
wrote in message ...
Like everything else in the world, to much is like not enough. When
writing



  #27  
Old July 14th, 2006, 12:23 PM posted to microsoft.public.access.adp.sqlserver,microsoft.public.access.tablesdbdesign
david epsom dot com dot au
external usenet poster
 
Posts: 75
Default Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)

It's a fact that the 'tables' and 'queries' are listed
on separate tabs. If they were all listed together, it
would make sense to totally drop the annotation: but
I share multiple databases with other developers, and
when you are looking for a view, you need to know if you
are in the wrong database, or just on the wrong page.

The terms 'field' and 'record' encourage me to think
in terms of card databases. I know that they were also
applied to file systems and sequential processing, but
they were never any more relevant there than they are
with SQL databases and set-based theory. Even the word
'file' was a barrier to people being introduced to 'file
systems': the concepts were too dissimilar to be helpful.
If they don't help with SQL, it's not because they are
bound to file/tape concepts: they never really worked
there either.

However, to be honest, you can use any sound to refer
to any concept. The real problem is that people use
language to define social groups, and social groups are
defined just as much by who you can exclude as by who
you include.

(david)




"Jamie Collins" wrote in message
oups.com...

Robert Morley wrote:
"tbl" for tables, "vw" for views


Another thought. Could using prefixes encourage the wrong mental model?
For example, using 'tbl' and 'vw' differentiates between a table and a
view (or 'qry for Query, to use the Access conventions). The difference
is physical whereas logically a view is a (virtual) table so why
differentiate at all? If I say SELECT last_name FROM Customers, why
would I care whether the table was virtual or otherwise? What value
does the prefix add?

Likewise the terms 'field' and 'record' which still prevail in the
Access world, rather than the respective terms 'column' and 'row'
preferred in the wider SQL world. Do these terms really encourage
people to think in terms file systems and sequential processing rather
than SQL databases and a set-based mental model?

Jamie.

--



  #28  
Old July 14th, 2006, 12:26 PM posted to microsoft.public.access.adp.sqlserver,microsoft.public.access.tablesdbdesign
david epsom dot com dot au
external usenet poster
 
Posts: 75
Default Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)

BASIC won the war, and lost all the battles: .Net has adopted
all the features that made BASIC - fully memory managed string
class, interpreted library, single basic type, etc - dumped the
ideas like prefix notation that were only there to make up for
defects in the C language definition - and given us a new C
language with all the features they laughed at.

In a language that supports memory management and ByRef variables,
where the most difficult part of programming is not keeping track
of your indirection, stack pointers, and string space, it no
longer makes sense to put the syntax annotations in the high-
visibility space at the front of the variable name.

Now, after a long detour through C, we are back were we were
with Pascal: variable names refer to the logical content of
the variable, rather than the structure of the variable.

I still use postfix notation for variable types: name$, cost%
where it helps. There should be postfix annotations for all
types /where it matters/. Unfortunately, that is one place where
..Net is still caught in the 'real-programmer' fashion. They
can't use language-supported postfix notation because C didn't
do it that way, and because BASIC did.

Instead, when they need to note information about the structure
of the element, they are typing it out, COBOL style. And it's
not that I object to COBOL: I could do object-oriented
programming in COBOL, even though COBOL was not 'object-oriented',
and you can do postfix notation in .NET, even though the language
does not support it, but in the end, it's more efficient to
have language support for features like that rather than doing
it all your self.

(david)




"Vayse" wrote in message
...
"Tim Ferguson" wrote in message
...
programming style, they have now reverted completely, and prefixes are
AbsolutelyOut for anything based on the new versions of VisualStudio --
or should that be visualStudio?


I have to do a lot of vb.net work, and I find the new naming convention a
bit awkard. New MS articles insist on dropping the o for object, as
everything is an object now. And cls for class is gone as well, of course.
But there are still some 2003 and older articles amongst the help files,
where they have different naming conventions. But thats not too bad, its
easy enough to get used to.
My old way: Dim oClient as New clsClient
New way: Dim SalesClient as New Client
It does mean thinking of names though! Like having to use SalesClient in
this sample.

What really gets me is the names on forms. So instead of gridClients, its
now ClientsDataGridView. And then theres ClientNameTextBox. Its very hard
to get used to, after years of txtClientName!
In some ways it makes sense. All your Client objects are grouped together.
But I think I'll keep to the old ways in Access. Though I may not be able
to keep up two naming conventions for ever.
Diarmuid




  #29  
Old July 14th, 2006, 12:30 PM posted to microsoft.public.access.adp.sqlserver,microsoft.public.access.tablesdbdesign
BruceM
external usenet poster
 
Posts: 356
Default Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)


"onedaywhen" wrote in message
oups.com...

BruceM wrote:
I learned about a naming
convention that makes sense, so I started using it, and found it to be
helpful.


Did you browse the whole 'naming conventions' aisle before making your
choice?


I picked one that seemed to be in common use, and turned my attention to the
program.


It's interesting how much of the discussion is about how using one system
or
another will appear in the eyes of somebody else.
Did you choose the
naming convention you use because you "wannabe" like somebody else?


Of course. When I started dabbling in WordBasic, I used logical terms
for variable names; I was working in the office of the board of
directors and wore a blazer, slacks and smart shiny shoes to the
office.

I wanted to move into VBA software development so, to be taken
seriously by what I hoped would be my peers, I adopted the naming
convention lng- for Long Integer, str- for String, dtm- for Date, etc.
These prefixes did not add value for me personally: the variable name
told me how I was using it and hence conveyed the data type, the prefix
seemed to be redundant and jar.


When learning something new we tend to adopt methods used by those from whom
we learn. As it happens I learned from people who tended to use a
particular naming convention.


Luckily in my SQL career I took the 'standard SQL' path from day one
and never got into the whole 'tbl', 'fields' and other Access
conventions. When I first started using .NET I was very relieved that
the convention has moved away from data type prefixes to logical
variable names; I still use the prefixes in VBA, though sometimes I
can't be bothered and stick with the .NET convention. I was amused the
other day to see an MVP using camelCase for their Access column -
sorry, field - names g.

And, yes, I use the standard SQL terms column (in place of 'field'),
VIEW (in place of 'Query'), 'DECIMAL' (in place of 'Currency' g), a
relational/industry standard key (in place of 'autonumber' vbg) to
encourage others to look outside of the Access ghetto in the hope they
may benefit as I have.

Oh and today I'm wearing a t-shirt and jeans (because sometimes you
need to fit in) with walking boots (because sometimes you need to do
what makes practical sense).


Perhaps it is or will be my downfall that I have never had much interest in
"fitting in". My choices are logical and systematic, and they work for me.
If they make me uncool in the eyes of some, so be it.


Jamie.

--



  #30  
Old July 14th, 2006, 12:44 PM posted to microsoft.public.access.adp.sqlserver,microsoft.public.access.tablesdbdesign
onedaywhen
external usenet poster
 
Posts: 124
Default Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)


BruceM wrote:
Did you browse the whole 'naming conventions' aisle before making your
choice?


I picked one that seemed to be in common use

Perhaps it is or will be my downfall that I have never had much interest in
"fitting in". My choices are logical and systematic, and they work for me.
If they make me uncool in the eyes of some, so be it.


Is there anything more conventional than choosing the convention in
common use g?!

Maybe you are less of a rebel than you think ;-)

Jamie.

--

 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Update combo box in subform (After Update event) Karl Using Forms 10 April 4th, 2006 07:45 PM
Looking for a recent thread on multple combo boxes potter Using Forms 7 February 28th, 2006 04:31 AM
Requery Combobox MJ Running & Setting Up Queries 7 May 25th, 2004 11:01 AM


All times are GMT +1. The time now is 02:04 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.