?
Solved

Access 2007 Early Binding ADO and Runtime

Posted on 2009-12-28
14
Medium Priority
?
642 Views
Last Modified: 2012-05-11
If I create an application in Access 2007 and reference ADO in my VBA Tools References section, and then allow a user to run that application via Runtime, will the user expereince any problems regarding ADO?

My suppostion is that the early binding references to ADO will be carried over and picked up automatically on a machine making use of Acess 2007 runtime, but just thought I would ask for additional clarification.
0
Comment
Question by:WoodrowA
  • 7
  • 6
14 Comments
 
LVL 75
ID: 26132782
Assuming that on other machines there is no issue in Access finding that Reference ... which s/b standard, that I can't see a problem.  However, there are different versions of ADO ... so that could be a consideration.  Will these machines not have O2007 on them?

mx
0
 

Author Comment

by:WoodrowA
ID: 26133222
Hello DBMX:
>which s/b standard, that I can't see a problem.
I'm sorry, I did not understand that sentence.  To elaborate my question.  It appears there are certain references that Access copies over and makes use of automatically when using Runtime. For example, I believe these four referecnes are included automatically:
Visual Basica for applications
Microsoft Access 12.0 Object Library
OLE Automation
Microsoft Office 12.0 Object Library.
I think runtime would not work if these were not included.  I guess my question is whether the same is true for Microsoft ActiveX Data Objects 2.8 Library.  It seems to me that this references gets automatically included, but I would like to confirm.
The question is this: Suppose you wrote an application that included a referece to ADO.  Supose you installed Access 2007 runtime on a machine that had never had office installed on it. Further, suppose you copied your applciation to that computer.   The question is, will that code for that application run OK in runtime , specifically with regard to code that has to do with ADO.
0
 
LVL 85
ID: 26134355
<Suppose you wrote an application that included a referece to ADO.  Supose you installed Access 2007 runtime on a machine that had never had office installed on it. Further, suppose you copied your applciation to that computer.   The question is, will that code for that application run OK in runtime , specifically with regard to code that has to do with ADO. >

First: ADO is not specific to Office, so whether Office was installed on the machine would have no bearing on whether ADO (any version) was installed on the target machine.

In general, your installation routine should check for EVERY reference needed to properly run your appliction. If your application requires ADO 2.8, then your install routine should check for ADO 2.8 and, if not present should either (a) alert the user and abort or (b) install ADO 2.8, if you include that in your install routine. If you try to install on a machine with a lower "version" - for instance, ADO 2.7 - then your application will have issues. Access/VBA can "upsize" references with ease, but cannot downgrade them (since they generally aren't backwards compatible).

This goes for every reference; however, in general, I never check for VBA, Access or OLE, since those VBA and Acces will be available through either retail or runtime Access, and OLE is always available in Windows machines. A good idea is to determine minimum system operating requirements for your system - for example, will your application run on Windows 2000 machines, or will you require at least Windows XP, SP3, etc etc - and then make sure that your install will work on a bare-bones install of that configuration.

On a side note: Technically, you should never install ADO by itself. ADO has been part of MDAC (Microsoft Data Access Components) for quite some time, and you should deploy and install THAT on your target machines. Trying to add a foreign verion of ADO to a specific version of MDAC will result in a special sort of "dll-hell" <g>. You should also use the lowest level of ADO that you supports all your features, which will eliminate a lot of issues like this. If all you're doing is opening recordsets and such, then using ADO 2.1 is generally fine, and every Windows machine from Windows 2000 forward is virtually certain to have ADO 2.1 installed.
0
NEW Veeam Backup for Microsoft Office 365 1.5

With Office 365, it’s your data and your responsibility to protect it. NEW Veeam Backup for Microsoft Office 365 eliminates the risk of losing access to your Office 365 data.

 

Author Comment

by:WoodrowA
ID: 26134592
Thank you LSM.  I hesitate to even take this conversation in this direction but maybe it will help you to know where I'm coming from. I think Access is a great solution for very specific types of problems, primarily for small businesses that do not have an I.T. Department.  I don't give a hoot for the ability of Access 2010 to access the web.  I think it is a big mistake for companies to write any kind of web application in a tool that doesn't have all the web capability it will ultimately need.
I am uninterested in writing Enterprise  Access applications for corporations, as a way to get around I.T.  I am not interested in connecting Access to SQL Server as a back end.
But I do think that when it's a small business, the problem involves less than a quarter million reocrds, and there are less than 30 people on a local area network, you can't beat Access.
That said, another draw is Access Runtime.  It's free and small business likes that.  But iti is of no worth if it only works 95% of time.  It sounds as if your saying that you cannot do early binding with regard to ADO.  That is, it sounds like you're saying that if you create an early binding reference in VBA to ADO 2.8, for example, that reference does not get included in a runtime rendition of your application, and there is no guarantee it will be useable if you're trying to run your application in a Runtime version of Access.  (By the way, I am talking Access 2007 and 2010. I am not interested in earler versions)
If that is the case, i.e., that there are no guarantees with regard to ADO, this seems to be one more reason to stick to the basics in Access and just use DAO.  I just don't want to get caught in a situation where I promise a client that I can write an applciation for him using Runtime, and then find out that it "almost works", or works "Most of the time."  The client doesn't care about most of the time.  
Hope I haven't sounded like a smart guy, but this is what I'm getting at.
Any additional thoughts?
Best Regards - Woody
0
 
LVL 85
ID: 26134767
<That said, another draw is Access Runtime.  It's free and small business likes that.  But iti is of no worth if it only works 95% of time.  It sounds as if your saying that you cannot do early binding with regard to ADO.  That is, it sounds like you're saying that if you create an early binding reference in VBA to ADO 2.8, for example, that reference does not get included in a runtime rendition of your application, and there is no guarantee it will be useable if you're trying to run your application in a Runtime version of Access.  (By the way, I am talking Access 2007 and 2010. I am not interested in earler versions)>

The REFERENCE most certainly gets included. Whether or not your target machine will CONTAIN the files needed for that reference is another story. That is up to the developer to determine, and Office/Access has nothing to do with that. This is true of any deliverable application. This has no bearing on whether the user is running Runtime or Retail Access ... a reference is a reference, and if it's installed properly, and if the containing environment (in your case, Access) is installed correctly, it should work on any machine.

The basics of this are true with ANY deliverable application. You MUST make sure that your target environment is compatible with your application. I may be misunderstanding you, but it seems as if are assuming that by delivering a reference to a library, that your application somehow "carries" that library with it. If so, that's not the case - the ONLY thing it does is carry a reference, hence the term. Once installed on the target machine, it's up to Access/VBA to verify that reference. Generally this is done through CLSIDs, which are unique to specific versions of libraries/files/etc.

However, given your parameters - that is, you're working entirely within Access, and you have no need to 3rd party utilities, SQL Server or anything foreign to Access - then you should be able to deliver your .accdb/.accdr/.accde file to the customer, and they should be able to run it - assuming they have a valid install of Access, either runtime or retail, on their machine.

<If that is the case, i.e., that there are no guarantees with regard to ADO, this seems to be one more reason to stick to the basics in Access and just use DAO.>

There is no guarantee that the correct version of DAO will be available on the machine. The same caveats hold true with DAO in regard to ADO - you should make sure that your target environment has installed the correct versions of DAO, if you use DAO. That said, I've never seen a situation where a reference to the standard Access references failed between machines (assuming valid, up-to-date installations of Access on those machines).

<I just don't want to get caught in a situation where I promise a client that I can write an applciation for him using Runtime, and then find out that it "almost works", or works "Most of the time."  The client doesn't care about most of the time.  >

I can certainly appreciate that. The fewer references you keep in your application, the better off you are.
0
 

Author Comment

by:WoodrowA
ID: 26135109
Well, I appreciate you sticking with me on this.  There is still an area where we have not exactly made a connection. I don't know if this is because one of us is misinformed,  or if it's a matter of symantics.  Assuming it's the later,  I hope you will bear with me.
I have an Access 2007 application before me. If I go into VBA I am able to write code like the following:
Dim dbCurr As DAO.Database
Set dbCurr as CurrentDB()
If I compile the application it compiles just fine.  If I select the Tools menu, and then references, I see no reference to DAO of any kind.  I assume this is because it is not needed.  I assume that DAO is such an intrical part of Access that placing some sort of explict reference (in tools References) is not necessary.  Additionally, I assume that if I give this application to another machine that does not have a full copy of Access but does have Access 2007 runtime, I say, I assume it is also going to run correctly on that machine too. .
Is this not correct?
0
 
LVL 85
ID: 26136932
You do have a reference to DAO - it's just named diferently. It's now called the Microsoft Office 12.0 Access database engine Object Libary, but can be referenced as "DAO".

Check this for more information:
http://allenbrowne.com/ser-38.html

< Additionally, I assume that if I give this application to another machine that does not have a full copy of Access but does have Access 2007 runtime, I say, I assume it is also going to run correctly on that machine too. .>

In general, assuming that the runtime is installed correctly and all is working as planned, it should work fine.
0
 

Author Comment

by:WoodrowA
ID: 26140634
LSM:
Thank you for the clarification.  The link you provided was very insightful and it led to other links that were also helpful.
I will bring this question to a close.  The summary to me is as follows.  Access makes a nice claim.  The claim is that a skilled developer can create an Access applicaiton for a client (in my case, a small business) and then distribute that application to numerous client machines without the client having to have a full paid-for copy of Access on each macine.    This is a nice claim, but I have yet to determine how true it is.
I have worked in PowerBuilder and .Net and they of course are able to do the same thing, but they also provide an easy way to insure that the distributtible will actually work on each machine.  This does not appear to be the case with Access.  With Access there are enough caveats to cause this developer to be very careful in what he promises the client.
Right now, it appears I am able to make the following claim.  "It is likely that the application will work in a runtime environment but I cannot guarantee it.  Worst case scenario, you may have to pay for a full version of Access on machines where there is a problem."
My hope is that if I do things in an orthodox way in Access, refrain from as many unneeded references as possible, and use things like DAO instead of ADO in as many cases as possible, the above claim will hold true.  I will ask one final question and close.
Do you concur?
I sincerely appreicate the help I have been given.  If I have additional questions I will switch to a forum like UtterAccess where others can chime in.  Thank you again.
0
 
LVL 85
ID: 26142053
I think that's a reasonable assumption. I've not yet run across a situation where the Access runtime failed to run my app, but a retail version did. That said, I don't often deploy to machines without a full version of Access, but I do so often enough, I suppose.

However, you mention items like .NET and PowerBuilder. Even with those products, the target machine requires a runtime (for example, the target machine must have the proper .NET framework). There's no real difference.
0
 

Author Comment

by:WoodrowA
ID: 26142191
Well, I fear I'm pressing you too hard but how, for example, do you insure your runtime version Accesses the right version of ADO?  With the .Net framework you're guaranteed the right access.  But if, for example I created an application that made use of Microsoft ActiveX Data Objects 2.8 Library, how do I insure that my runtime version will have access to the same file?  I can't just go and get that file and place it in the right place on the user computer can I?  I mean I have access to the computers of all users so I can do what I want but I can't do that can I?
 
0
 
LVL 85

Accepted Solution

by:
Scott McDaniel (Microsoft Access MVP - EE MVE ) earned 2000 total points
ID: 26142414
It's all the same thing ... the .NET framework just makes things easier on you.

It is incumbent on YOU - the developer, and the person deploying the application - to insure that the target machine meets the requirements of your application. If your app requires ADO 2.8, then your installation routine must insure that the target machine includes ADO 2.8. If it does not, then your installation should abort, and alert the user (or install ADO 2.8, if you so desire). The same as if your .NET application requires 3.0 framework, and only 2.0 exists - you should abort, and inform the user.

If 2.8 (or a compatible newer version) exists on the machine, then Access will recognize this and make the necessary references. If 2.8 does not exist, then your app will break. That is not a fault of Access, or Windows, or the library - that's the fault of the developer.

There are many different methods you can use to determine things like this - i.e. the environment of the target machine - but by far the simplest is using a commercial installer that can do this for you. All of them have scripts that can be used to check such things as OS level, MDAC versions, etc etc ... in the days before ClickOnce and .NET Frameworks, this is the way it was done (and it's the way you must do it with Access).
0
 

Author Comment

by:WoodrowA
ID: 26142505
Thank you again for responding.  In my case I have physical access to all the machines so I can determine for myself what the machine does or does not have.
Lets assume I want to insure the application  uses ADO 2.8 and I know the client machine does not have it.  How do I get it?  Is is part of a certain version of MDAC?  If so, can that version of MDAC be downloaded and installed on the users machine (like .net).  If I install a version of MDAC that satisfies my need, is it going to goof up something else the user may have on their machine.  For example, maybe the user has another application that takes advantage of another version of MDAC?
Are there white papers on this with further detailed instructions?
Thank you again.
0
 

Author Closing Comment

by:WoodrowA
ID: 31670488
You sure did a lot of work for 500 points but I know this is not your motive.  Thank you.  Part of the problem perhaps is that I was searching for a single answer to a compound question.  It's a fairly big subject.  I will try to be thorough in my homework. Thank you again.
0
 
LVL 85
ID: 26157485
Sorry I missed your last comment.

<Lets assume I want to insure the application  uses ADO 2.8 and I know the client machine does not have it.  How do I get it?  Is is part of a certain version of MDAC?  >

MDAC can be downloaded and installed on the user machines. In some cases, developers will even include it in their deployment package (although it can be a very large file). MDAC is Microsoft Data Access Components, and includes a lot of different things.

<If I install a version of MDAC that satisfies my need, is it going to goof up something else the user may have on their machine.  For example, maybe the user has another application that takes advantage of another version of MDAC?>

MDAC is backwards compatible, so any app that relies on version 2.5 will work fine with version 2.8 (or higher). In other words, it's "binary compatible" with older versions, which means those older apps would simply use the newer version with no issue.

Remember too that it's important to use the "lowest" version you can use for your application. There is no reason to require ADO 2.8 if ADO 2.1 will work - and this goes a long way towards making your application easier to install and maintain, since a LOT more machines will have 2.1 installed than will have 2.8.

There are thousands of white papers written on issues like this. Research MSDN and TechNet for more information, and also review some fo the online forums for the big installer companies (like Advanced installer: www.advancedinstaller.com). They are very good sources of information for deployment issues faced by those new to the technology.
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Windows Explorer let you handle zip folders nearly as any other folder: Copy, move, change, and delete, etc. In VBA you can also handle normal files and folders, but zip folders takes a little more - and that you'll find here.
In a use case, a user needs to close an opened report by simply pressing the Escape (Esc) key. This can be done by adding macro code in Report_KeyPress or Report_KeyDown event.
Polish reports in Access so they look terrific. Take yourself to another level. Equations, Back Color, Alternate Back Color. Write easy VBA Code. Tighten space to use less pages. Launch report from a menu, considering criteria only when it is filled…
With Secure Portal Encryption, the recipient is sent a link to their email address directing them to the email laundry delivery page. From there, the recipient will be required to enter a user name and password to enter the page. Once the recipient …
Suggested Courses

807 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question