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.
Related
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'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.
http://www.huagati.com/dbmltools/
I've been using the Huagati DBML tools for a project for the past five months or so, and just the "Update Linq-to-SQL Diagram from Database" function is worth the registration price. I haven't run into any compatibility problems, but that's the only 3rd-party add-in for VS2008 that I'm using, so not sure about how it plays with ReSharper.
It still boggles my mind that Microsoft released the Linq-to-sql designer (for .dbml files) without an "update diagram" feature built into it, but the Huagati plug-in does that, plus some other niceties (you can specify how you want to 'prettify' your column-name/properties, so that all my Tablename_Id columns become TablenameID properties. I did have to add a couple lines to the list of fields marked "auto-generated" (by default, my bit columns that default to 0 or 1 weren't marked as auto-generated, even though they are). A nitpicky complaint is that you can't type in the box that has the list of auto-gen values (you can't hit 'enter' to create a new line - so you have to copy/paste from notepad).
Other than that very, very minor nitpick though, the DBML tools have saved me a ton of time. I also like the "compare" feature to see what's out of whack before I go and actually commit to changing my Linq classes (also useful for comparing the dev linq ORM classes to a production database, in case you forget to document changes to the dev DB as you go...)
So anyway - after more than 5 months, I give it a thumbs up.
Kirk
If you've moved to Entity Framework this is clearly a tool you should know about. I've been disappointed by the EF designer's "Update Model From Database..." feature and I'm blown away by the simplicity and power of Huagati's Model Comparer tool. The Model Comparer for EFv4 shows differences between the database, SSDL, and CSDL layers and allows individual differences from one layer to be synchronized with another or left in place. I've just watched the demo video and I'm highly impressed. I wouldn't be surprised to see this sort of tool included in the next version of Visual Studio. Unfortunately I can't give hands on feedback yet, just a heads-up.
If you send an email to support#huagati.com I can put you in touch with some existing users. (Assuming you want to ask other users about their experiences..?)
Or if you have any specific questions on how to use it, please be more specific.
Also, (in case you haven't visited it), the support forum is a good place to get hold of other users and to ask specific questions about the tool... You can of course also email any questions you may have to support#huagati.com
http://forum.huagati.com/forum1-huagati-dbmledmx-tools-support.aspx
I am a non technical person and have a small company who has been supporting my companies software for a number of years. The solution works well and permutations of the solution has been with the current IT service provider for over 15 years. I recently got a more established IT firm to do a general audit on the software. The current solution uses access as a front end with sqlserver 2005 as the database. The company who did the audit presented a list of faults amongst others that the technology is outdated, the solution is not scalable, bad design, non user friendly interfaces, tables not normalised, tables has no referential integrity, non use of proper coding standards and naming conventions, no application security only database security etc. The firm who did the audit proposed that the solution must be re-written and offered to do so. The current service provider aknowledges some of the findings but assures me that it poses very little or no risk to my business. To re-write the application will cost a lot of money. I am in a difficult situation and would appreciate some technical advice. I basically need to know if my business is at risk running on the current technology. I have a maximum of 70 concurrent users working on the system at a given time
Well, if you value Joel's word, i would say that you are indeed, risking alot here.
Rewriting stuff was and will never be a safe thing to do for a company.
To boil it down into simple terms, ask yourself these questions:
Are you having problems with the software currently? Are users complaining about the user interface, or is it particularly hard for new users to pick up the software when using it? Is data being lost or corrupted at any stage, or are you having problems retrieving reports from the database?
Do you currently, or in the future are you likely to need modifications? If your software is badly written, modifications will be more costly, and more likely to break the application and cause downtime in general.
If the answer to both questions is no, then you likely don't need to rewrite the software. You have to remember that good software developers see badly written software and want to re-write it properly - as well as this, there is money for them in developing the software, so their view isn't totally unbiased.
Like others have said, re-writing a system has its own share of risks - old bugs that were fixed a long time ago can rear their heads again, new bugs can be introduced, the developers of the new system can totally miss the point and make the system less usable than the previous system.
If there are problems with the current system though it may be worthwhile to consider having the system re-written by competent developers - if you opt to go this route however, make sure to get feedback from your current users, especially the 'expert' or 'power' users, to ensure that the system will fulfill all of their requirements.
Before you go view your problem from the technical perspective, you must assess how critical the application is to your business. It sounds as though you have a functioning application. If it delivers consistent behavior AND you have no need for upgrades / new development, you may want to leave it alone. We software developers love to complain about everyone else's code, re-write other's work with "elegant" solutions. That means money.
However, you have an investment that may need maintenance, and when you have the underlying code and database in dis-array, you will incur more cost because the application does not lend itself to be modified. You'll want to get a feel for how much change you need to support. Given that it has been in production for 15 years you've had a good run, so you don't have much risk there.
To do a re-write will cost you, because you need to recreate what the app does, and since the supporting database and program seem to be "de-normalized" and unstructured, it's going to a big effort. There are advantages to have a clean database model because it will be easier to do reports, export to Excel, etc. AND should you want to modify it the developers will have an easier time figuring out what to do.
To spend money to get what you already have requires that you challenge the firm to detail what additional benefits you'll receive. Are these benefits beyond what you're getting today, and will this firm deliver on their promises? Will your company be better off if the database is "normalized" but you receive no other benefit than what the current app gives you? Keep these in mind before you make the jump to a new platform.
Fix the problems in the existing app. It will be much cheaper, can be done incrementally, and if done properly, will result in a more maintainable app.
The suggestion to replace the ADP front end sounds like pure prejudice/ignorance to me -- they don't sell Access development so they want to build you an entirely new app.
On the other hand, the advice about the back end sounds like something that you shouldn't wait to fix (though it could require a lot of work, since existing data likely won't fit proper RI).
The front end and back end problems are two separate issues, and can be handled independently (though the app may need to be updated to reflect changes in RI -- impossible to say without a case-by-case evaluation).
I would hire a competent Access developer with ADP experience to handle the project. This will be much cheaper than the complete rewrite and you won't sacrifice any functionality, nor will you re-introduce bugs that have already been addressed in your existing app. It can also likely be done incrementally (depending on what the problems are and how they need to be solved).
The suggestions offered by the "more established IT firm" are pretty common for access/sql server projects. The suggestion is almost always re-write them as web applications.
I just did this myself last year -- took an MS Access front-end/SQL Server back end application, and rewrote the access part as a C#/ASP.Net website. We enjoyed better performance and more flexibility as a result of the switch, but the old front end had been around long enough that we never did get back all of the functionality that we used to have before the rewrite.
If you're actually seeing 70 concurrent users, and none of them are experiencing performance issues, and your corporate network is secure enough, then you may lose more by rewriting the application, at least in terms of functionality. On the other hand, this may be a good chance to evaluate "what works" and "what could work better"--and enhance workflows.
Excellent use of coding standards doesn't necessarily translate to an excellent application.
What prompted the audit? Does their solution address this issue?
Let's do the math:
People: 70
Avg. Hrs Using software/Day: 2 (Conservative)
Salary/Hour: $8.00 (Really Conservative)
Business Days/Year: 250 (Took out weekends & vacation/sick)
Cost of labor using application: 70 * 2 * 8 * 250 = $280,000 / Year (Could go over 500K)
How much improvement can you get? 5%, 10%, 25%
How much will the new application cost? 50K, 100K, 200K
If you are able to save this time, will your users be freed up to do revenue generating activites or will they just have more time to surf the web? You may want to create some worker efficiency factor: 90%, 75%
Simple answer... Most of the "risks" of using Access are surmounted by using SQL server as the backend. You already said your current solution works.
So it boils down to your future plans. If your existing application isn't missing any functionality that can't be provided via access I would just stick with what you have.
If you need new features I would consider a few things.
Are they something Access can't provide or do well (ex: Internet-facing Solutions)?
What is the potential benefit reaped by having the new features?
What is the potential cost incurred by not having the new features?
Can you put a dollar figure on 1 & 2?
How much to develop the solution in Access?
How much to develop the solution in C#
In other words, always do the CBA :) Better yet, do you own CBA, then ask both companies to provide you with one, and compare for fun. In the worst case you might get your existing company to come down on their price to retain you as a client.
I've got an app that is just over 1yr old but it still evolving and will likely revolve more and more around a growing database schema in the near to mid term. The app was written using LinqToSql which has met our needs fairly well. We have run into a few pain points but have worked around them. I would currently consider this app to have fairly minimal database demands.
Now that the EntityFramework appears to be the ORM Microsoft is pushing people towards I'm wondering if it isn't inevitable that we will want to migrate in that direction.
I have heard a lot of good and bad about EntityFramework. So I am wondering if I would be better of taking the plunge now or waiting for v2.0 when VS10 arrives? Any thoughts? Will I lose any functionality if I do it now?
If I were to decide to migrate, can anyone point me at some resources on what is involved?
Thanks!
Re wait or change now? Personally, I'd wait (see Do you think it’s advantageous to switch to Entity Framework?) for VS2010 (as a minimum) - and until the beta comes out I can't check whether the things I use in L2S that EF lacks are implemented yet.
The resources etc question may be a dup of How to move from Linq 2 SQL to Linq 2 Entities??