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.
Related
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.
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 have a MDB database with plenty of VBA code, there are also connection strings to database. I need to have both the connection strings hidden, and the VBA code unavailable. In general I need to disable all functionality that is granted through shift-clicking the database file.
I tried making an MDE but it seemed to have no actual impact even though no errors were thrown, the MDE is exactly as accessible.
Thanks!
In addition to creating an MDE, you can:
disable shift-clicking
hide the database window
(this link shows how to do it manually in the options - it's also possible with VBA, but I can't find an example right now. I can look tomorrow if you're interested)
At work, we have a "publish" process where we create an MDE and do the things linked above.
EDIT:
Creating an MDE is a realistic way to prevent access to the VBA code - MDEs contain no code and you can't edit forms and reports.
The only thing you can do in an MDE is opening the database window and view/edit the tables. But you can kind of prevent that by disabling shift-clicking and hiding the database window (see my links above).
Note that it's still possible to link the tables in another MS Access database and view/edit them. So there's no 100% proof way to secure anything that you put into a table.
But when you put the connection strings into the VBA code and completely remove the code by creating an MDE, it's not possible to get the connection string out of the MDE.
I have an application that creates an Jet database at run-time, and imports ~100k records so that I can make use of the indexing for performance reasons (1 minute versus nearly 10 when not using a Jet database).
The database is created using ADO Extensibility in Excel, and everything works just fine. However, my issue comes whenever I then open the MDB file in Access front-end, it automatically starts to "repair" the database.
The data is still fine after the "repair", however my main output query can not then be viewed in Access as it tells me it cannot represent the joins, and if I then view it in SQL the required joins are not there, and the query can no longer run. This still happens if I let it get "repaired" but do not open that query, i.e. it is the "repair" that breaks the query, not the act of trying to view it in Access. The funny thing about this is that I used the Access GUI query designer to construct the SQL as my life is too short to worry about it's crazy bracketing style, but it then later decides that it's too complex for itself??
Also, nothing else appears to be affected so I can only assume it's this one query it doesn't like.
This isn't a deal-breaker for me as my fix is to make the MDB hidden and advise users who can see it not to open it.
However, I would really like it if the database could be opened and I didn't have to hide it away like that. Therefore, my question is whether there is any way to prevent the MDB being "repaired" automatically?
Thanks!
Microsoft Access is "repairing" the file when opened because it is missing some tables that are specific to the Microsoft Access user interface. Since you created the MDB file directly using OLEDB with Microsoft.ACE.OLEDB.12.0, these tables are not present, and must be created when Access opens the MDB the first time. There are several ways you can circumvent this:
1) Name the MDB something other than .mdb - e.g.: MyAccessDatabase.mad - this will prevent Windows from using Microsoft Access to open the file.
2) Use COM+ to open an instance of Microsoft Access, and have it create the .MDB file. This .MDB file will then have all the necessary tables present and will not need to repair the file.
FYI, whenever Microsoft Access opens an MDB that needs repairing in this fashion, it will inspect all the QueryDef objects for invalid SQL and correct them as necessary. This is why your "complex" query is breaking.
I'm using the Access Developer Extensions to attempt to source control this access database in TFS, however, I'm not sure I am doing it right. I can add a .mdb to source control and create a database from that source control.
I'm probably making a stupid mistake, but I can't figure out how to close the database I created from source control and reopen it while it's still under source.
Does anyone know of any tips or guides on this? I've searched for help on Access Developer Extentsions but I haven't found much. Thanks in advance guys!
I think I found what I was doing wrong. My database automatically compacts on close, so when it tried to do this Access asked me if I wanted "to remove the compacted database from source control". I thought this meant it would just not store the .mdb file, but still keep the objects (like tables, vba, queries, forms, etc) under source. However, this appears to completely remove it... from MSDN:
"Changes to Microsoft Access Behavior
Using the Compact Database Command
In order to take a database that is under source code control and deliver it to a user, you need a way to cut the database's ties to source code control. When you compact a database that is under source code control, Microsoft Access 2000 prompts you to remove the database from source code control.
To remove the database from source code control, Microsoft Access simply removes the Visual SourceSafe properties from the Microsoft Access database and its objects."
http://msdn.microsoft.com/en-us/library/aa155494(v=office.10).aspx
When I said do not remove compacted database from source control, my database and it's objects stayed under source.