A Year from the Backside

By Andy Lacey (bio), Bryan Carbonnell (bio), and Reuben Cummings (bio)

 

Backend Upgrader Project

The Backend Upgrader (BEU) is a utility that will allow developers to map out changes to their mdb Back End (BE) databases and deploy them remotely and automatically. In a nutshell, the developer imports all the components of the BEU into their Front End (FE), defines the changes, distributes the new FE, with the BEU components, and makes changes accordingly, the first time the new FE is run. This utility will allow the developer to avoid making changes to the BE by hand, on-site, or by remote link, and then possibly forgetting some vital change.

 

Some history

The BEU project started innocently enough in early 2001 - prompted by a post from Hadyn Morgan to the AccessD mailing list. As so many other posts to AccessD do, the BEU thread took on a life of it's own :) Lembit Soobik graciously donated the original code in February 2001 and then devised the original plan for the BEU. Volunteers were rounded up to take on the development as one of DBA's first virtual projects. When the stampede finished, Reuben Cummings and Andy Lacey were the only ones still standing so they got the gig, and the saddle sores.

 

They start

Reuben and Andy took Lembit's code and created an application that gives Access developers the chance to make changes to backend files just by filling out a form. Andy's role was to create the user interface and save the changes that the developer requested. Reuben's role was to handle the updating code, making sure that the changes the developer requested via Andy's interface were actually applied to the BE. Lembit kept watch in the early days, but once he saw his baby was in good hands, he wandered off to rebuild his house. The things some people will do to avoid real work!

 

With every new beta release (over 50 to date), everyone would download it, and make sure that it was stable and functioning as promised. Bryan Carbonnell, who had by now come on board as Tester-in-Chief, broke it in ways Andy and Reuben couldn't even conceive. One day, Bryan innocently asked about end-user documentation. There were no plans in place at that time. So he offered to write it (open mouth, insert foot).

 

The betas were being released at probably a rate of one a week, and Bryan got tired of transcribing the errors he got. He offered to build an Error Logging module for the BEU that would capture all the errors that were handled by procedure error handlers, and save them to a text file (open mouth, insert other foot :). So the developing team of two became three. The benefit of this added feature is that the end-developer has a reliable way to troubleshoot upgrade errors and failures. He or she can examine the error log, which captures the error number, error description, module and procedure name, as well as whether the error was expected and handled by code, or unexpected and possibly caused failure of the upgrade.

 

Improving the process

As the project progressed, it became more and more stable, until Hadyn Morgan came along and asked how it worked with relinking code. Unfortunately not very well at first. But Andy and Reuben persisted and now, with the developer adding a single line of code to his/her relinking procedure, the BEU works with relinking code. Once we got that working the time felt right to start looking at releasing the BEU. Our illustrious then-President, John Colby, suggested doing a code-walkthrough. For those of you unfamiliar with the term, a code-walkthrough means going through the code line by line, looking for programming irregularities, ease of maintainability, and thorough commenting. The idea is to critique the code. It is not about, "I wouldn't do it that way. I would have done it like ….." but about "This code does or does not do what it's supposed to." To aid in our efforts of reviewing the code, we enlisted JC and Shamil Salakhetdinov to be our code readers.

 

Since we are spread out across the globe (Andy in Peterborough, UK; Bryan in Ontario, Canada; John in Connecticut, USA; Reuben in Indiana, USA; Shamil in St-Petersburg, Russia) physically getting together was out of the question. We decided to try and use technology to solve this problem, opting for Microsoft's NetMeeting. Since NetMeeting has the capability to share applications, John was elected to host the session. By opening Access and sharing it, we could all see the code we were supposed to be reading, all at the same time. To avoid problems, we tested NetMeeting out beforehand. It seemed to work fairly effortlessly. So we decided to go ahead and use NetMeeting.

 

Meeting special challenges

The next challenge was trying to decide on a time to do it. With Shamil in St-Petersburg, which is GMT+0400, Andy in the UK (GMT) and the rest of us on or near the Eastern seaboard of North America (GMT-0500), picking a time that was convenient for all of us was a challenge. We finally decided on 2:00 PM GMT (6PM for Shamil, 2PM for Andy and 9AM for the rest of us). Since we all have day jobs, we opted to do it on a Saturday. The day of the walkthrough arrived and we all appeared on-line and ready to go. With 70 plus pages of code to review, we made sure we could talk to one another through MSN Messenger. JC then started up NetMeeting, and invited us all to the session. As it turned out, it worked Okay with one or two of us, but not with all of us. We tried for nearly an hour and a half to get it working satisfactorily. We couldn't, so we decided to carry on talking in MSM. Those that could see the shared app followed it on-screen, those that couldn't see it used their hard-copies. The walkthrough progressed, but slowly. Five people pouring over page after page of code laid out in front of them is time-consuming. Doing it remotely on a screen proved to be even more difficult. After four or five hours of the walkthrough we were all pretty talked-out and decided to call it quits for the day. A few very important things did come out of the session though. We realised we needed to have a naming convention, certain coding conventions, and more comments. Oh and some code needed modifications.

 

Since this is the first DBA project, none of the standards or conventions were defined. So Andy, Bryan and Reuben defined them. We started with the Reddick VBA Naming convention (RVBA), which is available at http://www.xoc.net. Where there was some ambiguity or several possibilities in the naming convention, we picked one to use. The coding conventions are things like indenting, loop structure and so on. Andy, Bryan, and Reuben settled on what worked for them. John also suggested that module and procedure header comments be included in all the code: code modules, code behind forms, everywhere there is code. In addition, in-line comments were needed to explain what the code's purpose was. So Andy, Bryan and Reuben went off to make all these changes, as well as to repair the code.

 

This was all done the week following the code walkthrough. The following Saturday, with 70+ new pages of code in hand, we all got together again to continue with the code review. Another four or five hours passed. More code was reviewed, but not enough. In the 10 or so hours of code walkthrough, we really only got through a handful of the 120 plus procedures and almost 4,000 lines of code. It was a great idea, and brought out some valuable points, but to get through all of the code was going to take us months.  So we abandoned the on-line walkthrough idea and decided to take the reading off-line.

 

Lembit returned from his hiatus and agreed to read the code. As he read, he posted his findings and we fixed the code. It worked much better that way. We now had stable code, that was thoroughly commented with standard naming and coding conventions. It had also, we felt, been pretty thoroughly tested by Bryan and Hadyn. That is until Lembit started doing some final testing. What Lembit found was that the code did not handle international numeric settings well. The problem was with the BEU version numbering system. We had used x.xx as a version numbering scheme, but some international settings use x,xx and the BEU didn't handle the decimal comma properly.

 

As we were so far down the line we took the easy route out of this issue and made the decision to use whole integers as the version number. Once that was tested and verified we were ready to release, which is where we are now. The whole team would like to thank DBA and its Board of Directors, for giving us this opportunity to do a virtual-computing project, Hadyn Morgan for his beta testing, John Colby and Shamil Salakhetdinov for helping us with the code walkthrough, and Susan Harkins for reviewing the documentation. Most of all though, we would each like to thank the other members of the team. It's been a long haul. At times it was frustratingly slow going, mostly due to having to fit in with the work that puts food in our families' stomachs. Time differences also slowed us down at times, but that was more than compensated for by the experience of working in a truly international team. Cooperation within the team has been brilliant. Suggestions have been debated then used or rejected with equally good grace. Criticism, in the true sense of the word, particularly during the code-walkthrough, was given and taken in a spirit of learning and improving, never personally. It has been great.

 
A Final Thought by Lembit Soobik (bio)

This attempt was not the first one. I’ve given the code to volunteers for the purpose of building a BEU for list members before, but after initial enthusiasm they all disappeared. But this team has shown a great ability to handle a project (over 14 months). Second, I remember I asked team members to be the project manager, but they did not feel they had enough experience. After following how this project was handled, I can say they have now, and I am sure this experience will be helpful in their jobs. Finally, on behalf of DBA and the AccessD list members I want to thank that team for providing us this great tool.