I just encountered an interesting problem while testing the portability of my database. I have built a database using MS Access 2000 and it is fully functional as far as I can tell. It is not complicated but the queries do contain some simple expressions. When I load the database on a different PC and try to run the opening form, which is tied to a query, I get the error message, “do not recognize function in expression (IIF(…)).” We could not find anything different about the two installations until we checked the Help / About Microsoft Access screen. On the installation on my PC, the numbers 9.0.2720 follows the application name. The code on the machine that failed to recognize the expression is 9.0.6926 SP-3. Does anyone have any ideas? Thanks.
Version question
- Thread starter slrphd
- Start date
ShiftyJaffa
Registered User.
- Local time
- Today, 15:15
- Joined
- Nov 10, 2004
- Messages
- 36
On the code window of the new pc, try clicking tools and references and make sure you have non missing. If your using code from a dll which is not available on the newer pc then you can get errors similar to this. If there are some missing, check what other applications are installed on the original pc that are not on the newer one.
- Local time
- Today, 10:15
- Joined
- Feb 28, 2001
- Messages
- 30,222
Ah, portability - the elusive butterfly, the brass ring. The very thing that Bill Gates doesn't really want to hear unless he gets a cut...
The problem is very likely due to references, just as ShiftyJaffa said, but let me 'splain.
Access knows what references are required for a given DB because they are listed in that DB. OK, well and good, ... but in a half-hearted attempt at providing better security, the brainiacs at MS made it so that usually you cannot use a .DLL file from Office unless the registry knows about it first. And the registry is a totally separate file from Access.
So on ANY machine that you want to be a host to your DB, you have to find a way to put entries into your registry if your DB needs them. Now, by hand it is no biggie. Open the DB, open a module panel with code in it, then follow menu path Tools >> References. (Just as ShiftyJaffa told you.) If you see MISSING: as a prefix for a reference, the file associated with that reference is (well, DUH) missing. You can look at the file it wants near the bottom of the dialog box by selecting the line with MISSING on it. The file spec pops into view under the main box.
You can either browse for the file (there is a Browse button to click) or you can do a Start >> Search >> Files or Folders for the named file. If you find it, use the Browse button. Select it. The MISSING marker goes away.
If the file is not there, you have a slightly worse problem to consider.
One solution (SOMETIMES) is to re-install Office on the problematic machine and check some options you hadn't checked before. Another similar fix is to re-install Office to let the INSTALLER refresh the install. It can make a list of missing files and it knows where to find copies thereof.
Another solution is to see if a file of a similar name is on the new machine because the library got updated somehow. (After all, you DID note version differences at the service patch - SP3- level.) Like, your reference is file XYZABC23, which you don't have on that machine, but there is an XYZABC24 in the right folder. This COULD be a version change of the file. Use that new version and cross your fingers. (I've done that so often, I can even touch-type that way. But it's hell on your knuckles after a while.
)
The final solution is to copy that file from your system to the new one, put it in a convenient place, and update the reference list to point to it. This is NOT recommended except as a last resort.
The problem is very likely due to references, just as ShiftyJaffa said, but let me 'splain.
Access knows what references are required for a given DB because they are listed in that DB. OK, well and good, ... but in a half-hearted attempt at providing better security, the brainiacs at MS made it so that usually you cannot use a .DLL file from Office unless the registry knows about it first. And the registry is a totally separate file from Access.
So on ANY machine that you want to be a host to your DB, you have to find a way to put entries into your registry if your DB needs them. Now, by hand it is no biggie. Open the DB, open a module panel with code in it, then follow menu path Tools >> References. (Just as ShiftyJaffa told you.) If you see MISSING: as a prefix for a reference, the file associated with that reference is (well, DUH) missing. You can look at the file it wants near the bottom of the dialog box by selecting the line with MISSING on it. The file spec pops into view under the main box.
You can either browse for the file (there is a Browse button to click) or you can do a Start >> Search >> Files or Folders for the named file. If you find it, use the Browse button. Select it. The MISSING marker goes away.
If the file is not there, you have a slightly worse problem to consider.
One solution (SOMETIMES) is to re-install Office on the problematic machine and check some options you hadn't checked before. Another similar fix is to re-install Office to let the INSTALLER refresh the install. It can make a list of missing files and it knows where to find copies thereof.
Another solution is to see if a file of a similar name is on the new machine because the library got updated somehow. (After all, you DID note version differences at the service patch - SP3- level.) Like, your reference is file XYZABC23, which you don't have on that machine, but there is an XYZABC24 in the right folder. This COULD be a version change of the file. Use that new version and cross your fingers. (I've done that so often, I can even touch-type that way. But it's hell on your knuckles after a while.
)The final solution is to copy that file from your system to the new one, put it in a convenient place, and update the reference list to point to it. This is NOT recommended except as a last resort.
Guys,
Thanks for your response.
Doc Man,
You gave me a lot to digest but I can promise you that I shall work my way through it. It will take some time so don't hold your breath. On the other hand, I'll probably need you to hold mine as I navigate through this. Thanks, again.
Thanks for your response.
Doc Man,
You gave me a lot to digest but I can promise you that I shall work my way through it. It will take some time so don't hold your breath. On the other hand, I'll probably need you to hold mine as I navigate through this. Thanks, again.
