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. |
|
|
Thread Tools | Display Modes |
#31
|
|||
|
|||
Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)
"onedaywhen" wrote in message oups.com... 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?! To quote from (I think) one of your earlier posts: "If you want to appear as a 'serious' SQL database type person, take a look at what people do outside of the Access ghetto". If people are going to evaluate my Access abilities I hope they will do so based on what I do with the program. If the convention in common use helps me be understood it has done what I ask from a convention. Maybe you are less of a rebel than you think ;-) Oh, I can fit into a variety of situations. But as always, any choice will be embraced by some and held at arm's length by others. Interesting as always to engage in these exchanges with you. Regards, Bruce Jamie. -- |
#32
|
|||
|
|||
Pointless debates on the finer points of naming your objects(moved from Combo Box Requery thread)
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. Jamie / onedaywhen, It looks to me like you are consistently overlooking a simple fact: these here are ACCESS newsgroups, and people come here with their Access questions... therefore, the replies are in Access terms. I'll accept, for the sake of the argument, that "view" is correct, and "query" is wrong, bad, filthy or whatever else you want it to be... even so, what makes you so confident that the poster of a question will actually know what you mean by "view"? How can you be so sure they won't be further confused instead? I truly admire the depth of your knowledge of SQL, which is exactly why I hate to see your energy wasted on pointless arguments. I suppose you must be enjoying this more than actually helping others! Nikos |
#33
|
|||
|
|||
Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)
Nikos Yannacopoulos wrote: It looks to me like you are consistently overlooking a simple fact: these here are ACCESS newsgroups, and people come here with their Access questions... therefore, the replies are in Access terms. I'll accept, for the sake of the argument, that "view" is correct, and "query" is wrong, bad, filthy or whatever else you want it to be... I'll settle for 'non-standard'. even so, what makes you so confident that the poster of a question will actually know what you mean by "view"? How can you be so sure they won't be further confused instead? I get your point. I'm pretty sure that when I use the term 'view' I usually say 'Query', 'query object' or similar. Access-specific terms can similarly be confusing for someone thinking in standard SQL terms e.g. a 'delete query' would be an oyxmoron. Surely as a community we can change the prevailing conventions and bring terminology closer in line with that of the wider SQL world. In the long run that would reduce confusion, I think. To use (yet another) example, years ago I was sent on an elementary Access course. The tutor was trying to teach about relationships 1:1, 1:m and m:m. I came out utterly confused, not knowing whether this terminology applied to Query objects or Table objects or what. I didn't use Access after the course and promptly forgot everything. When I later started using SQL on another platform I quickly encountered primary keys and foreign keys, of course, and it suddenly struck me that this is what that tutor had meant! So for me, the SQL syntax made sense and the Access approach did not. I figure there's got to be others like me out there who are confused by the Access conventions but would benefit from seeing the bigger picture; also lots of people for whom it would be overwhelming, I guess. I hate to see your energy wasted on pointless arguments Touché g! I'm only as bad as everyone else posting to a thread with the phrase 'pointless debate' in the subject line ;-) Jamie. -- |
#34
|
|||
|
|||
Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)
"onedaywhen" wrote in message ups.com... Nikos Yannacopoulos wrote: It looks to me like you are consistently overlooking a simple fact: these here are ACCESS newsgroups, and people come here with their Access questions... therefore, the replies are in Access terms. I'll accept, for the sake of the argument, that "view" is correct, and "query" is wrong, bad, filthy or whatever else you want it to be... I'll settle for 'non-standard'. even so, what makes you so confident that the poster of a question will actually know what you mean by "view"? How can you be so sure they won't be further confused instead? I get your point. I'm pretty sure that when I use the term 'view' I usually say 'Query', 'query object' or similar. The Access term is widely understood in an Access newsgroup. Access-specific terms can similarly be confusing for someone thinking in standard SQL terms e.g. a 'delete query' would be an oyxmoron. Those people probably won't come to an Access newsgroup. Surely as a community we can change the prevailing conventions and bring terminology closer in line with that of the wider SQL world. In the long run that would reduce confusion, I think. Most people come here to learn about solving specific problems, and do not care about the world outside of Access. While you may be correct about using terminology that is in wide usage, most people posting answers here probably do not wish to add a terminology tutorial to their responses, nor are those posting questions likely to be interested in such instruction. To use (yet another) example, years ago I was sent on an elementary Access course. The tutor was trying to teach about relationships 1:1, 1:m and m:m. I came out utterly confused, not knowing whether this terminology applied to Query objects or Table objects or what. I didn't use Access after the course and promptly forgot everything. When I later started using SQL on another platform I quickly encountered primary keys and foreign keys, of course, and it suddenly struck me that this is what that tutor had meant! So for me, the SQL syntax made sense and the Access approach did not. I figure there's got to be others like me out there who are confused by the Access conventions but would benefit from seeing the bigger picture; also lots of people for whom it would be overwhelming, I guess. The problem was, of course, with the instructor. I am aware of your disdain for Access, but an instructor's competence or lack thereof is not a reflection of the software. A friend of mine does development work with Filemaker. He is similarly disdainful of Access (and all things Microsoft), but I hear about his struggles with problems that could easily be solved with an After Update event or something of the sort. Still, he won't even consider any possibility other than that Access is at the bottom of the database scrap heap. I hate to see your energy wasted on pointless arguments Touché g! I'm only as bad as everyone else posting to a thread with the phrase 'pointless debate' in the subject line ;-) Yes, quite a number of us like to join the fray, don't we? Jamie. -- |
#35
|
|||
|
|||
Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)
While what you say is true, giving it SOME prefix ensures that any table
that are unrelated to anything else at least get lumped together. I personally find that easier than having them all scattered about when looking at an alphabetical list. To each his or her own, though. Rob "onedaywhen" wrote in message oups.com... 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. -- |
#36
|
|||
|
|||
Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)
I'll try again. My inline replies did not appear as such.
"BruceM" wrote in message ... "onedaywhen" wrote in message ups.com... Nikos Yannacopoulos wrote: It looks to me like you are consistently overlooking a simple fact: these here are ACCESS newsgroups, and people come here with their Access questions... therefore, the replies are in Access terms. I'll accept, for the sake of the argument, that "view" is correct, and "query" is wrong, bad, filthy or whatever else you want it to be... I'll settle for 'non-standard'. even so, what makes you so confident that the poster of a question will actually know what you mean by "view"? How can you be so sure they won't be further confused instead? I get your point. I'm pretty sure that when I use the term 'view' I usually say 'Query', 'query object' or similar. The Access term is widely understood in an Access newsgroup. Access-specific terms can similarly be confusing for someone thinking in standard SQL terms e.g. a 'delete query' would be an oyxmoron. Those people probably won't come to an Access newsgroup. Surely as a community we can change the prevailing conventions and bring terminology closer in line with that of the wider SQL world. In the long run that would reduce confusion, I think. Most people come here to learn about solving specific problems, and do not care about the world outside of Access. While you may be correct about using terminology that is in wide usage, most people posting answers here probably do not wish to add a terminology tutorial to their responses, nor are those posting questions likely to be interested in such instruction. To use (yet another) example, years ago I was sent on an elementary Access course. The tutor was trying to teach about relationships 1:1, 1:m and m:m. I came out utterly confused, not knowing whether this terminology applied to Query objects or Table objects or what. I didn't use Access after the course and promptly forgot everything. When I later started using SQL on another platform I quickly encountered primary keys and foreign keys, of course, and it suddenly struck me that this is what that tutor had meant! So for me, the SQL syntax made sense and the Access approach did not. I figure there's got to be others like me out there who are confused by the Access conventions but would benefit from seeing the bigger picture; also lots of people for whom it would be overwhelming, I guess. The problem was, of course, with the instructor. I am aware of your disdain for Access, but an instructor's competence or lack thereof is not a reflection of the software. A friend of mine does development work with Filemaker. He is similarly disdainful of Access (and all things Microsoft), but I hear about his struggles with problems that could easily be solved with an After Update event or something of the sort. Still, he won't even consider any possibility other than that Access is at the bottom of the database scrap heap. I hate to see your energy wasted on pointless arguments Touché g! I'm only as bad as everyone else posting to a thread with the phrase 'pointless debate' in the subject line ;-) Yes, quite a number of us like to join the fray, don't we? Jamie. -- |
#37
|
|||
|
|||
Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)
Those people probably won't come to an Access newsgroup.
While I can hardly argue the point that this is an Access newsgroup ("like, duh!" a la stereotypical teenage girl), one of the groups that this is being posted to is also geared towards ADP and SQL Server, and so is likely to attract at least a few so-called "real" database programmers who are "just trying to help the poor misguided souls who seem to think that Access is actually worth mentioning". Typically, the poor misguided souls who seem to think that they're using a "real" database system and Access users are not fall into one of two categories: those who believe that Access is not as robust as insert Enterprise-level system here, and those who have an unreasoning prejudice against anything that isn't their chosen system. Now, the former group certainly has a point. Access is not as robust of a back-end as SQL Server (or Oracle or whatever else) is. I know it may violate your preconceived notions, but not every database needs to be run on an enterprise-level DBMS. Access is meant to create small, portable databases on a local computer, or maybe with replication under a limited set of circumstances, and it does that very well. And as a front-end, frankly, I've yet to see its match. .NET may give you a lot more programming options, and make the programming tier very powerful and easy to write, but have you honestly ever tried designing a form with it? GODS what a nightmare! And as to the latter group, there's nothing we can do about them short of chaining them to a desk with only Access available and forcing them to actually USE it for more than a few hours and to actually learn how it works and what it's capable of...not to mention forcing them into learning a different way of thinking that doesn't involve command-line interfaces for half the work they do. (Why am I reminded of Linux users?) Alright, so much of the above is fairly prejudicial, but honestly people, these are the attitudes you're projecting...why SHOULDN'T I poke fun at you? Rob |
#38
|
|||
|
|||
Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)
Thanks for the link. I have been away from the programming front line for a
while. When I left I felt all alone in my views to the extent that I felt inferior when contesting programmers writing "Hungarian". Now I am not only not alone, but have learned something too. David F. Cox "Tim Ferguson" wrote in message ... "Robert Morley" wrote in : And while "tbl" itself may have first appeared in a Smart Access article in 1993, as I said, Hungarian notation itself pre-dates that. As I said, Simonyi K roly (aka Charles Simonyi) did indeed work at Microsoft, but he started Hungarian Notation back when he was working for Xerox. For a good description of the history of "systems Hungarian" and its misapplication see Joel on Softwa http://www.joelonsoftware.com/articles/Wrong.html Tim F |
#39
|
|||
|
|||
Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)
Robert Morley wrote: I currently [have a] view called "tblPreferences", Until now I considered the 'tbl' prefix to merely redundant, other than to identify an Access designer. Thanks to this usage example, I now see it is a potential be a hindrance i.e. when you change your base table into a virtual table (VIEW/Query) you have to either find and change the name in every reference in code or make everyone live with a counterintuitive prefix and those people who claim they find the 'tbl' to be helpful are going to be really confused/annoyed g. If that doesn't convince you that the 'tbl' prefix is to be avoided I'm not sure what will. Actually, there is something else nobody has mention AFAIK and that is ISO 11179-5 'Naming and Identification Principles for Data Elements' - google it. I urge anyone follow the ISO naming convention and see if you still think you need the 'tbl' prefix. Readers of this thread may find this article interesting: http://www.dbazine.com/db2/db2-disarticles/gulutzan5 "VBA programmers use a Hungarian-style convention (Leszynski/Reddick), so tblEmployees is a normal name. [However,] SQL programmers have less need for Hungarian Notation because they can get the type information from the metadata tables. Data in relational databases -including metadata - should be atomic and shouldn't be redundant...'This is the year 2000; the '60s are over! Things like "str_firstname" or "tblPayroll" are redundant.' -- Joe Celko" Jamie. -- |
#40
|
|||
|
|||
Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)
"onedaywhen" wrote in message ups.com... Robert Morley wrote: I currently [have a] view called "tblPreferences", Until now I considered the 'tbl' prefix to merely redundant, other than to identify an Access designer. Thanks to this usage example, I now see it is a potential be a hindrance i.e. when you change your base table into a virtual table (VIEW/Query) you have to either find and change the name in every reference in code or make everyone live with a counterintuitive prefix and those people who claim they find the 'tbl' to be helpful are going to be really confused/annoyed g. If that doesn't convince you that the 'tbl' prefix is to be avoided I'm not sure what will. So you don't need to change the name if you switch from a table to a query, but what if you change from one query to another? Also, several queries could be based on the same table. Which one has the same name as the table? What names are the others given? Actually, there is something else nobody has mention AFAIK and that is ISO 11179-5 'Naming and Identification Principles for Data Elements' - google it. I urge anyone follow the ISO naming convention and see if you still think you need the 'tbl' prefix. I tried the search. That ISO standard is about metadata, which I do not claim to understand, but which is well beyond the interests of most people posting questions here. In looking through some of your links I have seen calls for separating all words by spaces, and for not using spaces at all; for using uppercase, lowercase, and mixed case; for using singular and plural; and so forth. There is an expert somewhere with 25 years experience or whatever who no doubt disagrees with you. Who cares, unless you are both on the same project? If I work on a project with several others, the project leader will come up with a naming convention, which I will follow. I don't need to agree, just to get the work done. If I am that project leader some day, by then I will have refined my views on the subject. Readers of this thread may find this article interesting: http://www.dbazine.com/db2/db2-disarticles/gulutzan5 "VBA programmers use a Hungarian-style convention (Leszynski/Reddick), so tblEmployees is a normal name. [However,] SQL programmers have less need for Hungarian Notation because they can get the type information from the metadata tables. Data in relational databases -including metadata - should be atomic and shouldn't be redundant...'This is the year 2000; the '60s are over! Things like "str_firstname" or "tblPayroll" are redundant.' -- Joe Celko" Jamie. Interesting as always. Best regards. -- |
Thread Tools | |
Display Modes | |
|
|
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 03:31 AM |
Requery Combobox | MJ | Running & Setting Up Queries | 7 | May 25th, 2004 11:01 AM |