views:

416

answers:

6

I'm a 80% ruby on rails developer, but still need to do some Access VBA work.

Some of them are very shit systems, been build ages ago , used by the big enterprise globally , so that most of the works are just enhance the old system.

The techniques are basically MS Access as front-end, linked-table which link to SQL server via ODBC as back end.

Now, I really think I need help , just want to know is there anybody can build the elegant VBA application follow the object-oriented patten?

Even better if you can show me a snippet of code to demonstrate how good it can be, thanks.

A: 

You have my sympathy - Access VBA is not object-oriented in any sense like Ruby. You will have to change your mindset when tackling development in Access; such applications are almost always geared around the concept of data rows and sets rather than objects. The user interface is often bound to data rows and sets in a way that hides a lot of plumbing.

Having said that it is possible to build pefectly decent maintainable applications in Access with care and attention. Good luck.

Rik Garner
Thanks for your answer, great!! It is paining doing the Access VBa, do you have any idea about how to learn some tips ? like some screencasts website ?
Shuoling Liu
A: 

Take a look at the Implements statement i.e. polymorphism via interfaces. That's about as OO as VBA gets.

onedaywhen
Thanks, will take a look now.
Shuoling Liu
+3  A: 

Well the first issue to keep in mind is that there’s no magical shortcut to learning MS access. Over the years I’ve learned a lot of development platforms ranging from mainframe systems, databae systems, all the way down to hand coded assembler on a PC. I written two payroll systems from scratch (with the revenue Canada formulas for taxes included in those systems). One system was from scratch written Pascal where I even wrote my own data engine.

Make no mistake, ms-access is a complex developmet system.

You can build gorgeous looking drop dead applications in access. take a look at these screen shots:

http://www.fairsoftware.com/screenshots.aspx

Note the cool ribbons in the above screen shots.

The problem is you can’t learn Unix in a day, and you can’t learn Oracle in a day. You also can’t learn MS access in a day. If those applications you been given to maintain are complex, then hiring a developer with 4-5 years of experience is what you need here. The idea that somehow you going to get up to speed in ms-access faster then say vb.net, or c# is really a false concept here.

In fact I would go so far as to say that you can Learn Oracle quicker than you can learn MS access. While the learning curve in MS access is not so steep, it is very long.

VB6 is a walk in the park compared to access. VB6 forms are dead simple, but the forms in access are very complex (we have about 3 times the number of events and properties for the given form). For example, in access we have two events that fire when an form loads (on-open, and on-load). VB6 forms (and even .net forms) only have one event. The on-open event has a cancel option. If you set cancel = true then the form will not load and will not be displayed.

Logically, this means that the form has two distinct events for two distinct purposes when you call the form. The on-open event will thus have code used for verification and testing of certain conditions of data (and allow you to cancel). If the on-open event is not canceled, then the on-load event then fires and the form loads.

Logically, at this point this means that code that sets up variables or initial values of controls on the form needs to be placed in the on-load event ( in fact Controls cannot be modified but only examined in the on open event). So there’s a very nice granularity and distinction between the two processes that occur in a typical form load. It’s also interesting to note that most products in the marketplace don’t have these two separate events.

As a developer, thus you place the appropriate code and use the correct event for a given purpose. It will take some experience in having used access to figure out which event to use for these things. You could ask if there’s a book that explains this problem, but that’s like asking is there a book that tells you when to use a combo box over that of a list box? I don’t think there is such a book.

The documentation for a combo box will explain what a combo box is, and how to use it. The same goes for the documentation access has for the on open event. You can read what on-open does, but then you as a developer will have to figure out when it’s appropriate to use that event. The same goes for when it’s appropriate use a combo box or that of a list box. At the end of the day, the only solution and how to know these issues is going to be your experience as a developer with the product.

I have an article that talks about using class objects in MS access, and when to use them here:

http://www.members.shaw.ca/AlbertKallal/Articles/WhyClass.html

If you’re looking for code samples from everything to forms to reports to using windows API, a great reference is here:

http://www.mvps.org/access/

Albert D. Kallal
+1  A: 

One thing that just futzing around in Access won't teach you is how to create and use standalone class modules. These have some aspects of object orientation, but not a whole lot, but they can be extremely useful in making your code more manageable, as you can wrap a lot of operations in a standalone class module and then treat it as an object that can have multiple instances. You don't get inheritance and polymorphism and a lot of the other buzzwords that go with the OO gospel, but it's worth taking a look at what they can do if you've never used them extensively.

David-W-Fenton
"You don't get...polymorphism" -- sure you do: ever used the Implements keyword?
onedaywhen
"Implements" was added long after I learned to use class modules in Access, which is why I'm not aware of what it does. This is one of the problems of having long-term experience with Access -- one often fails to appreciate new features.
David-W-Fenton
Even so, it's worth taking a look at what Implements can do -- never too late to learn something new :)
onedaywhen
Implements is one thing, but it's not the same as inheritance (derived classes), which is most serious OO design relies on. VB.Net supports inheritance.
apenwarr
The question wasn't about a fully-OO environment, but about what aspects of OO could be used profitably in VBA/Access. I don't see that anyone said implements was the same thing as inheritance, unless that's what you're reading @onedayone to mean when he equates polymorphism with implements. I'm out of my depth here, and think OO is a religion as often as it's a proper programming technique, which leads to all sorts of dogmatic doctrinal arguments. I find those discussions to be a complete snooze, myself.
David-W-Fenton
@apenwarr: Ever heard the OO mantra, 'Favor composition over inheritance'?
onedaywhen
A: 

I read above "You have my sympathy - Access VBA is not object-oriented in any sense" not true by ignorance like 80% of basic MS Access User that's why you can read this :

An Open Letter to MS Access Users

Dear MS Access Power Users,

MS Access is the most popular Personal Database in the World thanks to its Rapid Prototyping Philosophy accessible even to the average Users. Unfortunately this also means that the full power of MS Access is often completely hidden to these same people.

Nonetheless, many MS Access Users, since they are non-IT Professionals use only 1/10th of MS Access Power, even if they go beyond Macros and use VBA modules, they may not ever wander into MS Access VBA Class Modules.

Why would you use OOP with MS Access VBA ? Many times I have seen in Corporate World a User develop a little Utility in MS Access which slowly but surely along months or years turns into a full-blown Business Application and the IT people will get crazy at it when one day that User or Manager of that User is asking for help to maintain the Application because the creator has just gone or the needs of the application is becoming too complex for the User to cope with. That’s why MS Access has a pitiful reputation to be unprofessional whereas it is rather that their users are Professional of their own Field but mostly not expert in IT Field.

The problem is that this reputation leads many IT Professionals not to even bother looking at MS Access since it is a “User” platform. So it’s time to change things a little bit :). I’m gonna show you how to create a maintainable MS Access Application or how to refactor your application to be Object Oriented.

Firstable a little warning. Most people shunt VBA as not “truly” Object. I remind that there is no true Object Programming Language but only “Oriented”. And VBA is as Oriented as any others even if it lacks traditional Inheritance … since it can do Inheritance through Class Interfaces and as you may or may not know traditional Inheritance is now considered Evil - see this Javaworld’s article where Jame’s Gosling (Java’s Father) is quoted to have said when someone asked him: “If you could do Java over again, what would you change?” “I’d leave out classes,” he replied. He explained that the real problem wasn’t classes per se, but rather implementation inheritance (the extends relationship). Interface inheritance (the implements relationship) is preferable.

Sincerely yours,

MSAccessVBATutorial.com

joepassing
+1  A: 

This article is old but make a great case for considering Access as part of the enterprises long-term application strategy.

http://www.fmsinc.com/MicrosoftAccess/Strategy/index.asp

Seth

Seth Spearman