I've been searching the web for answers but got no success to find the right thing to do. So this is my last resort.
We have an Access database (1997) and works perfectly in our old remote server. But when we migrated it to Windows 2012 Server and convert it to .accdb file format, the CommonDialog built-in method which opens a window for selecting a file is not working and error message pops up.
By that we are completely aware that some references are missing and we were right.
We searched the web and realized that we need to use the Application.FileDialog under Microsoft Office x.0 Object Library for higher version of MS Access. We implemented that for some of our VBA code that utilizes the CommonDialog and it worked.
But we are also thinking on how are we able to continue using the CommonDialog for higher version of Access just for the sake of not tweaking our VBA code?
If you have an idea about this, I would be glad to hear. Thanks in advance!
Related
My question is a mix of a development and an administration question, but since it affects mainly developers and refers to a development tool (Access, VBA and the Form model), I am posting it here and hope that I don't get flamed. Having said this:
I have converted an Access 2010 x64 .adp project to Access 2016 .accdb, which was not too difficult. But now, whenever I am running code which references the UniqueTable property of a form, I am getting the following error:
Run time error 2455 You entered an expression that has an invalid reference to the property UniqueTable.
This is a known issue with Access 2013 and Access 2016; see here, for example.
Microsoft has made a fix - see here.
And here is the problem: A few days ago, I have installed Office 2016 x64. When trying to apply the fix mentioned above, I am only getting the following message:
There are no product affected by this package installed on this system.
Of course, I have double checked that I was using the right version (x64) of the patch. I have not yet tried to install Office 2016 x86 and apply the x86 version of the patch, though.
Did anybody manage to actually install this patch against the x64 version of Office 2016? According to Jim Conrad's statement (second to last post here), it cures the problem, but this doesn't help if we can't install it.
Well, the uniquie table setting really not of any use in Access (non adp). As far as I can tell, the setting tells (told) Access to use the PK from the source data table, and as a result should not effect anything of value I can think of here.
What I would do is open up the form(s) in design mode in the ADP project, and simply blank out the setting BEFORE you import the table into the accDB. The issue is you can't get at and remove this non need setting in the accDB, but it persists when you copy from the ADP.
So, simply blank out the uniqueTable setting in the ADP and then import the tables. You could also write a loop, and do all of the forms in one shot before you import them into access (so, I guess working on a copy would make sense).
So the issue here is that the setting persists when you copy the table into the accDB, but THEN you can't get at, or change, or remove this setting since it is not exposed via code, or the property sheet.
So, the simple solution here is remove the setting in the ADP application before you import the forms into the accDB.
I have an Access, 2007 – 2016, accdb database on my Toshiba Satellite Pro running Windows 7 32 bit. I am using MS Office 365.
The database that opens at its home page, but any attempt to open a table, form or module brings up this message:
“The database cannot be opened because the VBA project contained in it cannot be read…”
I have 2 backups of this database, but they do the same thing.
I have read several posts on the internet that indicate that the problem can be solved by decompiling the database.
I have tried the VBS Script solution contained in:
How does one decompile and recompile a database application?
However, it does not get to decompile as the same message displays when the .vbs file opens the database.
I have read some other posts that indicate a problem with a VBA7 file, but these refer to Access 2010, so I do not know if they also apply to me. I have VBA7.1 by the way.
Attempts to decompile through the Command Prompt has its own problems that seem to be associated with file names with spaces.
So, I’m stuck. Any help would be much appreciated
I ran into this same error at work, Have you tried shift-clicking and opening? I know that seems obvious, What I did, was I got the DB open in safe mode, and opened up a module in the vba editor, and tried to fight the problematic code, if anything you could delete all your modules after copying them into a notepad.
I also right clicked and restored previous versions from windows, I am not sure if you have tried this when you say you have to back ups, but i was unaware of this fix and i luckily had a version from last week that fixed my issue.
we have an over the years grown Access Database which is making use of a Treeview Element and the Excel Office reference. With some Windows Updates we ran into problems with the Treeview (throws random errors about ActiveX control for each input: mouse move, mouse click, etc.).
Some customers use Access 2003 (we 2007) and therefore some errors are thrown on the first time opening the database because the references have to be adjusted.
I want to solve those problems by taking the office 2003 reference (I think it should be the MSO.dll) and store it in the database as an OLE object. On Startup I want to 'extract' the file and use it as a reference for the office libraries, so that I am kind of independent from the installed Office version on the machine.
Furthermore I thought about doing the same thing with the MSCOMCTL.OCX so that it can not get corrupted from Windows Updates anymore. I hope to gain more stability in the application.
My questions would be: Is it possible at all to use the office references from a local file instead of the windows dir?
And is it possible to use an ActiveX control directly from a local file instead of the registered one through RegSvr32?
If so, any links or information how to achieve this will be greatly appreciated.
Kind regards,
Matthias
I honestly don't know if it's possible, but I certainly would do everything I could to avoid going down that road. The potential for even worse stability problems and general weirdness would be significant. I would push for either
standardizing on an Office version (not 2003), or
using a third-party treeview control from a reputable developer and using late binding to replace the Excel reference(s).
I have an Access 2003 application that users recently started having issues with the day I put out a new version, one of the screens has a field that has a default value of 'date()', instead of showing the date it shows '#name?'. I'm sure this if some out of synch dll or ocx but not sure which one. Anybody know? I rolled back to a previous version of the application on the users machine and they are fine now (but I'll need to keep pushing out new versions with new functionality soon). So I think some file on my development box got updated just not sure which one.
Thanks
Don
This is typical of a missing reference. If your are using ActiveX controls, you could easily be missing something on the other PCs. Another common cause is using early binding and library references.
Missing references often affect the VBA core functions such as Date.
What are the implications of running a Microsoft Access Database in both 2003 and 2007?
Is there some class I forgot to take?
The program was originally built in office 2003, and then run in 2007. Issues seem to happen when the machine it is being run on has both 2003 and 2007 on it. The issue would also appear to stem from reference from the "Microsoft Access 12.0 Object Library" (or the "Microsoft Access 11.0 Object Library" in 2003). To see this, just look at the Tools: Refrences menu on the VBA screen.
The error's symptom is basically the code not be recognized (almost like it doesn’t recognize the programming language I’m using). It usually follows this with a box that says "The expression On Load you entered as the event property settings produced the following error: Object or class does not support the set of events". You can also replace “On Load” with “On Click” for buttons or “On Change” for text boxes.
I personally suspect that the computer is taking parts of the Microsoft Access 11.0/12.0 Object Library and then mixes the two into a useless VBA reference. What further confirms my suspicion is the box that pops up when going between the two that says "Configuring Microsoft Access" Another issue that further confirms my suspicion is it will run on whichever one it is opened on first (2007, for example) and then not run on the other (2003 continuing the example)
The only other issue is I have had to fix was changing the last part of the DoCmd.OpenForm ,,,,, acFormReadOnly (or acReadOnly, depending on how the machine seems to feel on that particular day - yes it would work with one, one day and then want me to switch it another) to simply locking the individual text boxes
Maybe it’s not quite coding, but I think it might be able to be fixed by coding.
Hopefully that’s enough for someone to come up with something.
Microsoft's official position is that installing multiple office versions on the same pc is not supported and not recommended, and Access 2007 seems to be designed to prove that to us!
That said, you can avoid most issues by doing the following:
1 - Splitting the db into a back end and front end. Place the back end (tables and relationships) in a network folder, and place a copy of the front end (all other objects) on each user's desktop.
2 - It's best to make the front end an mde to avoid the references shuffle every time you open the db in the other version of Access.
3 - Create a shortcut to open the front end with the desired version of Access so it's always opened with that version. (And remember to use the shortcut!) In the shortcut's target:
"path to Access 12 msaccess.exe" "path to db.mdb"
We have an MS-Acces application, developped with Access 2003 and used on either full or runtime version of Access 2003 and Access 2007 (Access 2007 Runtime being free, we are making a great use of it!). There is no particular issue except the references management. Our code analyses the Office version installed on the computer and automatically updates corresponding references (not only Access but also Excel, Outlook, Word, etc.: code is very tricky but of great interest!)
To my own knowledge, no major objects, properties or methods available in Office 2003/VBA were deprecated in Office 2007. Office 2003 code will then run with Access 2007 once these references issues solved. Some new objects were introduced in Office 2007 so I would not advise any developer to use it to develop code to be further used with Access 2003.
But the main & real issue of your question is: why should one run both Access versions on the same computer? This is what I'd do if I want to make sure to crash my apps. I think that if your objectives were to develop software, you should definitely find a better configuration for your machine!
In general, having multiple versions of Access installed on the one machine is unsupported and will result in the issues you are seeing with the object references.
If the database is authored in Access 2003, compiled to an .MDE, and then deployed onto a separate Windows instance running Access 2007, you should not have any significant issues (other than UI changes such as custom toolbars being thrown into the Add-Ins ribbon).
For testing on multiple versions of Access you will need some form of isolation between each version. I use multiple virtual machines to accomplish this. My primary Windows VM runnings Office 2007 and IE7 and I have a second VM which has Office 2003 and IE6 for testing.
Note that if you wish to simply use Word, Excel and Outlook 2007 with Access 2003, you can install Access 2003 first by itself and then do a custom install of Office 2007 and deselect Access 2007.