Argee's Access Blog

Check out this Access Team Blog article in which Wouter Steenbergen describes new navigation features in Access 2010 in detail

This article, John R. Durant's WebLog : Why VBA Still Makes Sense , presents a solid case  for why VBA is the ‘next level’ when it comes to application development in Access and other members of the Office suite. John provides an excellent of VBA since its early days to the present and on into Office 2010 including his perspective on the ‘fit’ between .NET and VBA. John R. Durant's WebLog : Why VBA Still Makes Sense is definitely a worthwhile read.

Ryan McMinn and Clint Covington demonstrate the most significant new Access feature being introduced in the 2010 version View the latest Office Team Blog article and click the link to their video.

to www.officetipsandmethods.com

A little over a year ago I started two blogs, Argee's Office Help Blog and Argee's Access Blog. As the titles suggest, the first focuses on entire Microsoft Office applications except for Microsoft Access. The second is aimed strictly at Microsoft Access related topics. I found a number of free blog hosts and started my first OfficeHelp, a Windows Live Site. After publishing a few articles there, I wanted to be able to separate Access oriented articles from those related to the rest of the Office suite. Windows Live blogs are great for personal/social blogs but I couldn’t find a way to classify or categorize articles with more that a single category/tag for each article.

Visiting a few blogs by my Access colleagues led me to consider the Blogger site which is hosted by Google. I decided to locate my Access site there. Each article can have multiple tags. That makes it easier to specifically classify articles so that a reader can find specific topics more quickly.

Recently, I have come to realize that I really wanted an even more sophisticated classification system than what is possible on the Blogger site. Part of this need stems from the significant change that Microsoft introduced into user interfaces with Office 2010. These changes were particularly significant in Access, my main area of interest. A little Internet searching led me to the WordPress publishing platform.

Will WordPress solve my classification problem? It certainly seems so, and then some. I found that I can set up custom categories and sub-categories. That means that I can flag an article as relating to Access generally, to Access 2007, specifically, and that the article is part of a tutorial. I can also tag each article with one or more tags that will aid in subject oriented searching. Best of all, I found I can include a category search capability in a side bar that is always there at the top of the blog page.

WordPress may not be the last word in meeting my blogging needs but so far I like the look and feel. Now it’s time to get back to writing. For the time being I will mirror articles that I publish at OfficeTipsAndMethods on my OfficeHelp and Access blogs so if you have subscribed to one or both of those feeds you will still be notified of new articles in those blogs. But if you want a “one feed serves all” feed, visit

www.officetipsandmethods.com

and subscribe to the rss feed there.

At the end of August, a discussion at my home away from home, UtterAccess.com piqued my interest in the topic of how experienced Access developers viewed the importance of commenting their VBA Code. I decided to conduct a brief survey of two groups, Microsoft MVPs, and UtterAccess VIPs. I specifically notified Access and Excel MVPs as well as the VIP group at UtterAccess.

While there weren’t quite as many opinions as their were people completing the survey, there certainly is a broad range of opinions.

Dennis, an UtterAccess member who was unable to complete the survey because he was away while it was open for response posted a forum message that pretty well sums up my own position on the question. He said in part,

“Commenting code was described by one of my college instructors as one of the most important, but least prioritized steps of the programming process. And I believe he was (and is) 100% correct.
One should never assume that the purpose of a block of code is self-evident. Even if you've used the same module over and over, that module should be documented so that someone (even you) in the future will quickly be able to see HOW and WHY a block of code is doing what it does.
Commenting costs nothing to compiled code, and is worth it's weight in gold to people charged with improving and re-using code. After all, the cliché says "time is money" and the amount of time saved with a few lines of text within a block of code can be enormous.
There, that's about it, in a nutshell.”

I should mention that I did not submit a response to the survey myself; I wanted to leave the answers to others and let the results fall where they may. The results were not particularly startling. They do reflect a broad range of opinion among the respondents. More than half of the 57 people answering the survey rated commenting as being either very important or absolutely essential.

The numerical results, however, only tell part of the story. The survey included two open-ended questions, ‘Briefly describe how you use commenting in your own work and the depth of detail you include in your comments.’ and ‘What would you describe as the single most important reason for including comments in programming code?’

A common theme for the first set of open-ended responses was, “to help me remember what I did and why.” Some of these comments expanded the theme to include “others who might have to follow-up on my work.”

In response to the second open-ended question, one person put it this way, “1stly To remind me of what I wrote and how the code works...I sometimes don't view project for long periods of time. 2ndly so that if or when I expire someone else can take up where I left off.”

There were a few problems with the survey, some caused by my oversight when I designed it and some caused by the the survey software itself. Two people reported either being unable to submit their responses on the the survey site or being unable to edit/include comments that were greater than 255 character. I won’t complain too loudly about the survey site, however, since I used the free survey tool that is available if you register on the site.

As to survey design issues, I neglected to include a ‘none’ category in the question about programming languages other than VBA. That cause the ‘other’ response to be somewhat ambiguous.

All in all, however, I’d have to say that devising and implementing the survey and analyzing the results has been an interesting exercise. I have a few other ideas that I may try in the future. The full survey report is available in pdf format here.

I would like to publicly thank the UtterAccess VIPs and my fellow MVPs who took the time to respond to the survey.

I was quite surprised yesterday to see reference to an article I wrote several years ago, Data Modeling for the Access Newcomer is an internet newsletter. I am not going to name the newsletter here because I don’t want to give it any free publicity. You won’t find it by links that I provide.

The particular newsletter follows the questionable practice of posting teasers about articles with links that lead to a sign-up page for their paid service. Once you have signed up, chances are all you will find is yet another link, this time to another site where the piece was available to you free of charge all the time. So you have just paid for, or at least signed up for a trial of, a service that frequently simply provides you links to pages and sites that a freely available without ever going near their service. If it was a free trial, you can bet they will then be soliciting you for a paid subscription. Definitely don’t buy the subscription unless you feel you are getting real value for your money.

In the case of my article, the full text of the article is freely available in Garry Robinson’s excellent VB123 blog. Garry recently purchased rights to the best years of Smart Access magazine (the years when Peter Vogel was the editor.) You can purchase electronic versions of sets of the magazine from Garry’s vb123 site if you are interested in a set of excellent articles that spanned the years from October 1996 to April 2006. That is almost 10 years of monthly issues with articles by hundreds of Access experts.

If you are just interested in my article, this link Data Modeling for the Access Newcomer, will take you to the full text of the article. Garry is very generously publishing the full text of individual Smart Access articles in his blog. He has a convenient index to the Smart Access articles.

There is an old expression that says, “Why buy the cow, when you can get the milk free?” While the expression can have a somewhat off-colour meaning, depending on its context, I think it deserves a paraphrase here, “Why pay for a link when you can get to the real article free?” If someone is trying to sell you links, use your favourite search engine to find your own links. It won’t cost you a cent.

In the last installment we explored the many to many relationships that exist between our various table. At that point we had not yet created the tables. This article will deal with the nuts and bolts of actually creating a table.

A word about names

The names you use when you create your database objects are important and should follow certain guidelines. Access reserves certain words for its own use. Logically these words are known as reserved words. Unfortunately some of these words are the first that comes to mind when you are trying to name fields for example. In this article I discussed at a conceptual lever, the tables we need in the Ice Cream Parlour database. If you look back to that article you will see names like ‘Name”, “Description”, and “Type”. These words all have special meaning within Access and should not be used to name Access objects.

So you will notice that the field names in the relationship diagrams in my last article are different from those I used in the conceptual diagrams. So, for example I have a field ‘strSundaeName’ rather than simply ‘Name’. What about the ‘str.’ That part of the name comes from a convention I follow to add a prefix to the name that indicates the datatype of the field. Many Access developers do not use prefixes for field names. So SundaeName would be perfectly acceptable and, in fact, preferred by many developers.

On the other hand, many developers do follow a naming convention that prefixes the names of Access objects like tables, queries, forms and reports, with three characters to signify the type of object to which the name pertains. So, for example, the Sundaes table is actually called ‘tblSundaes’.

Notice also that tables are usually plural. That is because the table contains records where each record is one example (or instance) of the subject of the table. So, tblSundaes has fields with names like strSundaeName (or SundaeName, if you prefer.)

Creating a table

There are several ways to create a table in Access. Although I don’t recommend it, you can design a table by entering data into a datasheet. Access will determine the data type for each field based on the data you enter. And unless you are careful to name each field, Access will assign such helpful field names as Field1, Field2, etc.

In Access versions prior to 2007 there are table creation wizards and in 2007 there are table templates to help you out. Unfortunately, tables created by wizards or from Access 2007 templates have field names that do not follow accepted naming standards. They include spaces in the field names. Now, while this may seem perfectly natural to you if you are an Access beginner, those spaces will come back to haunt you when you decide to enhance your work using advanced features like Visual Basic for Applications (VBA).

I prefer to create all tables using the Table Design View. Before we go there, however, we should map out the fields we will need and determine what their respective data types should be. For the sake of illustration I am going to deal with creating one of the tables we have decided we need. If you are following along and creating your own ice cream parlour database, the best way for you to learn will be for you to create the other tables on your own. I will be providing a link to my version of the database with all tables created.

Before we look at the table designer, let’s summarize the information we will need for each table. I am indicating two possible names for each field. The first name follows the naming convention I prefer to use. The second is a valid name in a format that omits the data type prefix. Whichever style you choose, it is important to be consistent throughout the database.

Sundaes - tblSundaes

Dishes - tblDishes

Sizes - tblSizes

Flavors - tblFlavors

Ingredients - tblIngredients

Those are the basic definitions of our five central table. As already noted, we will need additional tables in the database to allow us to connect these central tables together so that the database reflects the one to many relationships between them. We will also need a lookup table for types the type descriptions used by tblDishes, tblSizes, and tblIngredients.

Coming next: Using the table designer.