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.
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/
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.
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.
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
Take a look at the Implements statement i.e. polymorphism via interfaces. That's about as OO as VBA gets.
Related
I'm relatively new to programming, so Im not quite sure how this all works yet, but I had an idea for a program that would make my job easier and was wondering what program language or tool I needed to learn to go about making it. Basically this program puts together an assembly of hardware using a database and the user checking boxes or selecting multiple options to narrow down the hardware for a specific structure.
Specifically, I work in designing transmission line structures (the towers and poles carrying wires you see on the highways and farms). These structures require multiple assemblies of hardware including bolts, nuts, insulators, etc. All of these parts need to be sized, and currently we do this all by ourselves using specifications. This is a HUGE waste of time and often tedious so I want to make a program that will just give us the list of hardware after we select a few options about the structure (material of structure, wire type, connection type, etc.).
I hear that Microsoft Access could be a tool used to do this, but wasn't sure. Would using Access work? Or is there a better option?
Appreciate the help!
I have a pretty good project task management system going in Microsoft Access, but one feature I'm still missing is some type of 'quick entry' like facility often found in many good productivity applications.
This is how it would work:
Scenario 1:
You're in another application, working on a few things, and you just remember something that needs to get done. You hit your predefined shortcut: CTRL + ALT + T (again, from outside Microsoft Access) and it brings up a small access form with a text box in to which you can type what needs to get done, e.g.
Inform key stakeholders of concerns regarding timeline
you hit return and that gets saved as a record in Microsoft Access instantly.
An alternative, and slightly more complex scenario...
Scenario 2:
As above, but you want to add further details besides the task name, such as the person you need to speak to, and a due date. The input in to the text box could look like this:
Inform #Sally of concerns regarding timeline >+3
Where '#' tells access to populate a field called 'Contact' with 'Sally' (unless it already exists) and '>+3' is interpreted by access to mean a due date 3 days from today.
How difficult are Scenario 1 and Scenario 2 to perform? What level of VBA/programming knowledge would be required?
Thanks,
I would say it requires a fair amount of confidence in VBA.
You need to register a global hot-key; that is, a keyboard-combination that can be captured from outside the Access application. It requires win-api calls. Here is some code.
You need to know where to place these calls. I believe you have to put them in a standard module, not in the form's class module. (I haven't double-checked this, it's late.)
You need to have a little understanding about what this code is doing. NEVER attempt to type this api-code - copy it from a reliable source, exactly as it is!! You don't need to fully understand the code, but you need to know how (and when) to call each function.
Once you've registered the hot-key then your VBA needs to bring your application to the front and display your form, and focus it. Reliably bringing the application to the front may also require api-calls.
Once your form is opened (and focused) you can have a button on it to parse the information in its textbox. However, if you are designing the form anyway, I would add checkboxes, comboboxes, etc., rather than trying to parse a complex sentence/ statement.
I have a Microsoft Access business critical database that was originally created in the 90's and has been enlarged and upgraded up to Access 2007 at this point. We have been using this database as a front end for a custom written ERP system essentially. We have moved most of the data over to an SQL server long ago, but we are still using MS Access as a front end. AS the project grows, we have a full time developer, we have started having stability problems and extremely frequent crashes of unknown causes.
As an example: 1 time out of 10 or so, a certain form will crash if I change the data in 1 specific field. There is no code firing at the time, the data is in a local temporary table that typically only has 5 rows most of the time. If I change the data in the table nothing goes wrong, but if I change it on the form Access will hard crash and dump me to the desktop. There are other examples I could provide of unexplained crashes
I am looking for advice on where to go at this point -- the access front end has all of the business logic for running our company essentially so I can't just abandon it. Ideally we would re-write the entire front end in some other language. The problem is that as a small company we don't have the resources to re-write the entire system in anything resembling a good time frame, and don't have the cash flow to pay someone else to do it. My ideal solution would be a conversion of some sort from the access front end to another end point -- whether web or local windows -- but my searches here and on google make that seem like a non-starter.
So essentially every avenue I look at seems to be a dead-end:
We can't find the source of the crashes to stabilize our current system,
We can't stop production in our current system for as long as it would take to re-write it,
We can't afford to pay someone else to write a new system,
Automated conversion tools seem like a waste of money
Are there other options or which of the options that I have thought of seems best?
We have an enterprise level program with an Access front end and an SQL Server back end. I wonder if it might not help to split the program up into different pieces for diagnostics. For instance if you have Order Entry and Inventory Management you could have one front end for each function. (Yes I can hear the howling in the background but if it was only for the purpose of diagnosis maybe it would help... )
You can also export the Access Database objects to text files and then import them into a fresh new database to get rid of weird errors in some occasions.
Well, I guess I will rephrase the basic issue here. If you have two Computing Science graduates on staff then they should have long ago anticipated that they reached the limits of Access. I fail to see this as any different than an overworked, oven in a restaurant that now have too many customers or a delivery truck that does not have the capacity to deliver goods to customers.
Since funds don't exist to re-write then your staff failed to put aside funds on a monthly bases to deal with this situation and now your choices as a result of this delayed action to deal with this growing problem places you in a difficult situation.
The computing science people you have on staff should have long ago seen this wall and limit you hit coming. In my experience is with most CS people is they consider Access rather limited, and thus even MORE alarm bells should have been ringing here and this means even less excuse exists for you to be placed in this unfortunate predicament.
So, assuming the computing science staff you have are well maintaining this application (and I graciously accept this is the case), then then a logical conclusion is this application has reached or exceeded the limits of Access. As noted such limits should have been long ago anticipated.
As you well point out that funds now do not exist for a re-write, then few choices exist without such funds.
However, you case may not be so bad since we NOW know you have experienced developers on staff. Given this case, then my suggestion would be to consider breaking out modules or small manageable parts and features one at a time from the application and having your well trained and experienced developers build either a web interface, or perhaps even using something like .net if you wish to stay 100% desktop. So this "window" of opportunity is a great chance to consider a change in architecture)
Since the data limits are SQL server and NOT Access, then both applications (existing access front end) and the new parts can BOTH well and easy operate on the same data. As you do this, you then break out and remove the existing parts from the Access application. This would suggest you eventaully return to accetable stability in the Access applicaiton. At that point , you could continue, or stop to save funds.
As noted, without funds to re-write, then the only choice is to find some means to free up SOME limited resources on a monthly basis to solve this problem.
At the end of the day, the solution to this problem is more resources, but without such resources then few technical choices and options exist here. Based on the information given so far YOU have made it clear you don't have resources here. However, the solution to this problem here requires resource allocation and planning.
In other words a technical fix to this problem without resources allocated is not likely an available option for you.
I apologize sincerely for not being able to give you a technology solution here, but this looks to be a solution that will require resources to be allocated to the problem and no simple shortcut or trick or magic silver bullet exists here.
I am still green when it comes to using MS access.
I am attempting to better my-self by using a recordset object instead of using DLookups. My plan is to use these for reading and manipulating data in MS access 2007.
From a lot of the reading I have done, I cannot tell whether to use ADO or DAO?
My access DB is used to store User account info for some of the systems we manage in our office. This will be used by only a few admins to maintain user information
I am having a rather hard time finding hard-and-fast examples or "best practices" that maintain any kind of .consistency. Also, any kind of documentation requires laborious reading of Why to use, and theory of use, before any kind of...
This is what to use.... kind of articles.
I anticipate that these tools will forever live in MS access, since that is all I have at my disposal at this office. In the future I would like to make data-connection strings more open to tools other than MS Access, like SQLite....
However MS Access is what I am driven to. I have been using DLookups to get data from a table, but that is starting to feel juvenile, and not good for retrieving more than 1 column of data from 1 particular row.
Can anyone directly I to some kind of idiots guide to ADO or DAO. I am not a programmer by trade, and would like to get some coding done soon. Everything in this office is To Be done: yesterday. I don't have the time to read long diatribes as to why one is better than the other.
TheSavo
This is a very touchy topic. :) You will find mixed feelings on this subject.
To start with, you can refer to this old article (which was updated last year)
http://msdn.microsoft.com/en-us/library/ms810810.aspx
At the bottom it states that DAO is officially obsolete, and implies that there will never be a 64-bit version. I have not seen any other article after this date which confirms the fate of DAO.
Most programers when they start out, they start with DAO and then gradually move to ADO. At least that is what I have seen in different forums while answering questions. DAO at one point of time was shunned because of only one reason. The fear that it was going to be obsolete and finally replaced by ADO. But when DAO libraries were updated with Access 2007, the focus was back towards DAO. However it was too late. Most of the experienced developers had already become comfortable with ADO. Even today most of them while answering questions in forums still provide code using ADO. And I don't blame them as they have been using ADO for a long time now. IMHO, DAO should be unusable at some point in the near future before ADO is.
I remember discussing something similar with one of SO members sometime ago on whether to use ADO or DAO. I even discussed this with 7 different MVP's and if you are an MVP and a member of vbforums.com then you can visit this thread http://www.vbforums.com/group.php?do=discuss&discussionid=50&pp=10 to view the discussion. Till the time DAO works or is included with MS Access, you sure can use it. :) However the The consensus in the above discussion was NOT to use DAO.
If you would still like to use DAO then please read on :)
As of now both have their advantages and disadvantages. I would recommend you to have a look at this old link in MSDN which would give you a fair idea on the differences.
Topic: Choosing ADO or DAO for Working with Access Databases
Link: http://msdn.microsoft.com/en-us/library/aa164825%28v=office.10%29.aspx
HTH
Sid
As everyone is pointing out, there are various opinions on the subject, and Microsoft's own documentation flip-flopping around technologies does not help.
However, if you're just starting, make it easy for yourself and just use DAO: it's the native technology for Access, it works great, it's fast, easy, and it works out of the box without fiddling with references (it even works in 64bit Access, not that you would want to use that though).
With ADO, you'll need to manage connection strings manually in code and it behaves sometimes slightly differently than DAO, and that just adds to the confusion.
I will unequivocally say that in the context of learning to be a better Access developer, you can safely ignore ADO: you will probably never miss it.
I'm yet to find where I would absolutely need to use it in my own code, and I've been developing fairly large applications (50,000+ lines of VBA) in Access for a few years.
The MSDN page you reference does not talk of development under Access, it talks about what Data access technologies are available to programmers at large under Windows.
It's true that you would not be using DAO from another programming platforms, say when building application in C++ or .Net (although DAO blows ADO.Net in terms of raw speed)
It's also true that MDAC doesn't support Jet any more, but that's because: 1) Jet is integrated in all versions of Windows by default and 2) ACE is a new driver that replaces Jet in Access2007/2010 and adds new features while still being compatible with Jet.
Within Access itself, DAO is still the default -and most integrated- way to operate on your database from code, and until Microsoft actually replaces DAO by something else within Access itself, you don't need to worry, it's not like your apps will suddenly stop working.
Getting started
I would really recommend that you get a nice fat book, like:
Access 2010 Programmer's Reference (there is a PDF version).
Access 2010 VBA Programming Inside/Out (also in PDF version)
You don't need to read everything in these of course, but they will contain almost everything you'll ever need, including database samples for each chapters, and you can slowly improve and discover feature by skimming the book and getting more in-depth at your own pace.
I just started working for a company that uses a "Rapid Development Environment" (RDE) supplied by a third party. The idea is that you can specify things like: "display data in grid", "datasource", "sort by" and it generates an a ASP.NET application that does all of those things.
I'm personally not a huge fan for the following reasons:
You are at the mercy of the RDE with
regards to what level of control you
have. For example there is no
try/catch/fail mechanism.
If there is a bug in the RDE there is
nothing you can do, you have to wait
for them to release a fix.
I'm not sure that it speeds things up
all that much.
There is no way you are going to find
someone with X years of experience
using some backwoods RDE. Every new
employee is starting from scratch
You can't integrate many common tools with it. Source control would be an example of this. While i'm sure I could take the EXTREAMLY verbose xml files used to generate the application and manually insert them into Source control there is no way for me to just right click and checkin. Even if I do that there would be nothing meaningful displayed if you do a diff...
Has anyone found these things useful? They seem like a gimic to keep costs down to me...
I don't use any tool/framework/environment/etc that I cannot bypass whenever I want to.
I don't care how good the product looks on paper or what impressing demos I'm shown.
If the product isn't mature and expressive enough to offer the possibility to work around it or hack/plug into it, I'll pass.