I have an Access database for which I have created a 2010 runtime version.
I sent over to a partner in India where their predominant machines only have Access 2007 installed.
They have installed Access 2010 Runtime to these machines, but make the following claims:
No access to Nav Pane - to see/open tables
No menu ribbon
No table/datasheet right-click functions (sort, find, etc.), except as I have implemented under buttons on the form.
I see all these functions when I run on a 2010 VM. I don;t have a 2007-only machine to validate or debug their claims.
Does this result sound odd?
I suppose I could work around some of these:
Populate the current list of tables in a listbox on the form
Create a custom menu with the necessary functions
Not too sure about the table/datasheet right click functions
Not freaking out just yet, but getting close... I cannot re-build this thing DOWN to 2007.
Any advice anyone?
Does this result sound odd?
Not really. It sounds like you were opening the .accde file using the full Access 2010 application while the other team was opening it using the Access 2010 Runtime.
The Access 2010 Runtime environment does not include things like the standard ribbons, navigation pane, etc.. If the developer intends to deploy the Access application under the Runtime then the expectation is that they will provide custom ribbons and navigation tools as required for that particular application.
Note that this is true whether the Access application is distributed as an .accdb file or an .accde file. An .accde file is simply an .accdb file with the VBA source code removed and the users being prevented from opening objects like Forms and Reports in Design View. Those changes help "lock down" an application when opened in the full Access application, but they don't make any difference to the behaviour when opened in the Runtime environment (because the users can't perform those operations in the Runtime environment anyway).
Developers can test the "Runtime" behaviour of their applications by opening them in "Runtime mode" in the full Access application. This can be accomplished in either of the following ways:
Create a shortcut that invokes MSACCESS.EXE with the /runtime switch and passes the name of the .accdb file to open.
Temporarily rename the .accdb file to .accdr and open it. .accdr files automatically open in Runtime mode.
Related
I have a program made and developed by Microsoft access 2003 but i can't open it's VBA code or see any tables or use the design mode even by using alt + F11
it's only open the program interface
so how i can do this?
If the application has been compiled to a mde (or accDE), then design mode will not be available for forms/reports and VBA code.
Assuming you have an mdb or accDB (not an mde or accDE in which design changes are NOT possible), then you should and can modify the application.
The first suggestion to hold down the shift key during application startup usually works. However, the shift key can be disabled. That being the case, then simply create a new blank database and then import all objects from the original - this thus will allow you to launch/open the application without any startup code running.
You can do this by pressing shift key while opening the mdb.
An Access database with a load of queries, tables, reports and forms with VBA code.
Was used in Access 2010 for ages, then some users upgraded to Office 2013 very recently.
One user had a "problem" on their computer while using the database, which may have resulted in their computer restarting, and now the database seems to have no forms or code visible when opened.
Googling finds reports of similar situations where the forms and code was there but invisible.
Any ideas?
The first thing to attempt is to open the database and choose Compact and Repair. I would then go into the VB Editor, if possible, and choose the Debug menu, Compile. While in the VB Editor, also check Tools, References for any missing references.
If the database is split to a back-end and front-end then just give them a new copy of the front-end. If this doesn't work then I would re-install Office on their computer.
If they have their own copy of the database (it is not split) then give them a new copy.
If they have already entered data that needs to be kept then I would start a new database and import all of the Access objects from the existing database. I have found that re-importing all objects solves most of these issues. You could import just the tables from their copy of the database, but the other objects from another copy.
If re-importing all objects doesn't resolve the issue then a remaining option is use the decompile command-line option:
C:\Program Files\Microsoft Office\Office15\MSACCESS.EXE /decompile
Open Access from this command-line, go into the VB Editor and choose the Debug menu, Compile. Then close, re-open and Compact and Repair.
I'm getting the following error message on some users machines:
The expression On Open you entered as the event property setting produced the following error: There is an invalid use of the . (dot) or ! operator or invalid parentheses.
This error message appears when trying to open the Access database on some peoples' machines using Access 2010 on Windows 7 from a shared location.
Using the same shared network location the database opens fine on Windows XP with Access 2003.
I've checked the registry for the Sandboxmode (2).
The folder location is shared and open for all users.
Looks from the code its not liking the main menu, its complaining about the ! in this form:
strCriteria = [Forms]![MainMenu]![Text22]
I see two issues here:
Compiled .mde (and .accde) files are a lot more "fussy" about different versions of Access than .mdb (and .accdb) files are. This is presumably because .mde files have the source code stripped out of them so Access cannot re-compile things "on the fly" like it can with an .mdb file. Years ago I began stipulating that if the Access application is using an .mde front-end then all users must be running the same version of Access and the .mde must be compiled for that version. Even so, an .mde file will occasionally "act up" but re-building the .mde from the source .mdb will usually fix it. (Subtle changes introduced by Office patches and Service Packs may account for at least some of that.)
If multiple concurrent users are opening the same .mde file from a network folder then you will almost certainly encounter problems. For many years it has been well-known among Access developers that a multi-user Access application must be split into a front-end and a back-end (which you have apparently done), and each user must have their own local copy of the front-end file. Even Microsoft is recommending the practice now (after many years of their being conspicuously silent about the matter).
I am about to release an Access Database application where the UI is used exclusively to interact with the database tables.
Whilst I am interacting with the forms during run time, the Visual Basic Editor appears with a line of code highlighted in debug mode, even when no breakpoints exist and no run time error has occurred.
Has anyone else come across this issue?
I need to ensure that the editor does not appear (under normal operating conditions) while the user is interacting with the application.
Thanks.
Yes, I have had this problem too and it has driven me batty. The quick and dirty way of fixing it is to create blank database and import all of the objects from you old database into the new one.
Are your users working with an .accdb file? (or .mdb, depending on the Access version)
If yes, you should convert it into an .accde/.mde before giving it to your users.
Quote from the link:
Additionally, if the database design needs to be secured to prevent changes, Access databases can be locked/protected (and the source code compiled) by converting the database to a .MDE file. All changes to the VBA project (modules, forms, or reports) need to be made to the original MDB and then reconverted to MDE. In Access 2007 and Access 2010, the ACCDB database is converted to an ACCDE file. Some tools are available for unlocking and "decompiling", although certain elements including original VBA comments and formatting are normally irretrievable.
--> since .accde/.mde files are compiled, it's not possible to view the source code at all.
So the VBA editor can never appear accidentally like you experienced...be it because of a breakpoint, some Stops in the code or some strange breakpoint error like yours.
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.