Access 2007 Early Binding ADO and Runtime
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.
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.
ASKER
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.
>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.
<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.
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.
ASKER
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
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
<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.
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.
ASKER
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?
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?
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.
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.
ASKER
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.
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.
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.
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.
ASKER
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?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
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.
ASKER
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.
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.
<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.
mx