Related
As a caveat to this question I am a beginner Access 2016 programmer of 2 months, but believe I have some intermediate to relatively advanced knowledge of the software as it's just about all I've been doing at work the last two months. I also realize now that I'm asking for trouble using hyperlinked fields as most people believe they're more hassle than they're worth (at least in older Access versions, it's surprisingly a little difficult to find Access 2016 information and opinions in 2018.. at least for me cause I'm apparently incapable of using "the google machine" properly), but I'm in a little too deep now.
At the moment I am trying to deploy a new database system but have run into some issues when testing. After turning my .accdb file into a .accde file the command to "Edit Hyperlink..." vanishes entirely from the shortcut menu when right-clicking. My employer would really like this functionality to be present in the final product, as he wants to display the file name but link to the file location in a shared network drive. I also need document control at his small company to be able to edit the hyperlinks but don't want them using an .accdb file that they could inadvertently make design changes to, or god knows what.
I have attempted to make a custom shortcut menu using this VBA module, which is executed by an AutoExec Macro, running upon opening the database.
Public Function CreateCustomRightClickMenu()
Const msoBarPopup As Long = 5, msoControlButton As Long = 1
' Create a shortcut menu named "CustomRightClickMenu"
With Application.CommandBars
With .Add(name:="CustomRightClickMenu", Position:=msoBarPopup, MenuBar:=False, Temporary:=True)
' Add cut command
.Controls.Add type:=msoControlButton, id:=21
' Add copy command
.Controls.Add type:=msoControlButton, id:=19
' Add paste command
.Controls.Add type:=msoControlButton, id:=22
' Add hyperlink command.
.Controls.Add type:=msoControlButton, id:=1576
' Add edit hyperlink command.
.Controls.Add type:=msoControlButton, id:=1577
End With
End With
End Function
I can get this function to work just fine in the .accde file, but the "Edit Hyperlink..." command is still unusable - it's greyed out. Is there some way to override this?
The only information I could find as to why this is the case is because a compiled .accde file restricts all design tools. I thought this explanation was rather... lackluster. Editing hyperlinks constitutes as a design tool? How would a hyperlinked field ever be advantageous then, in an automated system? And by automated I mean one that can run freely without a DBA sitting in some back-end file all day and updating the file's address lying beneath the display text. I will be on the opposite end of the country in a month and a half and will not be able to dip my toes in the back-end anymore so to speak.
Additionally, I saw many solutions for this problem in earlier versions of Access, but not in 2016. So my question is, what is it about the 2016 version in particular that is making this so difficult?
Or, can this be done at all?
Alternatively I've thought about using attachments and was assured that they don't bloat your system because Access will compress the files. After testing this I'm relatively sure it's not the case. I attached one 900kb .pdf file to 3 separate records in a database copy, and the .accdb file's size increased ~2700kb, as is to be expected. Compact and Repair had no effect on the final file size (3,974kb). 900kb files weren't realistic for my system though, and if my math is correct I should be able to store about 11,000-13,000 records in a 2GB Access database if I have 3 50kb files per record, subtracting 1000-2000 to account for the space of my access objects. Is this a realistic calculation, and what problems will I run into if I try and go this route?
EDIT: After briefly glancing over this webpage yesterday:
https://codekabinett.com/rdumps.php?Lang=2&targetDoc=access-hyperlink-data-type
I thought about it some more and realized I could just have our Doc control enter hyperlinks in the format "DisplayText#FileFullPathway#" ignoring sub address and scroll tip text.
And so far so good.
Then something interesting happened. I sent out a beta .accde file for DC to play with today, and the Edit Hyperlink... tool was magically available when I was getting her to test something unrelated (yesterday on her same machine the command either wouldn't be there, or if I had the CustomMenu set-up then the command was greyed out). I had deleted my custom menu from the entire database, no VBA module exists for anything menu related and the form's ShortcutMenu property is now blank. You'd think I'd be relieved but this is bothering me even more now - if I didn't enable it who did, and how come it wasn't there yesterday prior to having wasted all this time coming up with a workaround? Maybe I'm supposed to have that menu command and it was just bugged yesterday, but my travels through the Googlesphere yesterday suggest otherwise. This is driving me bonkers. For now my problem is resolved but I'd still like to know what's happening here.
I get the "There isn't enought memory to perform this operation. Please close unneeded programs and try again."
The only thing I do and I can recreate the problem:
I open the form, it works!
I open in structure view, I delete a label. I save. I open the form! Puf ERROR!
I have 4GB of ram and only 1,5GB occupied...
I had a situation like that once, and the only cure I found was to decompile the application. Decompile discards all the compiled code, and gives you an opportunity re-compile your application's source code anew. That will allow you to overcome a situation where the existing compiled code has become corrupted.
It's not a terribly difficult process. Fortunately, #David-W-Fenton described it in clear detail in a previous Stack Overflow answer: HOW TO decompile and recompile
Also read what Tony Toews says about Access database corruption: Corrupt Microsoft Access MDBs FAQ
I'm using Access 2003 on a duo-core machine with 4GB of RAM, running Windows XP (Service Pack 3) [5.1.2600]
Periodically, I get an error msg "There isn't enough memory to perform this operation. Close unneeded programs and try the operation again."
A check of Task Manager indicates that there is plenty of free memory. Closing other open programs makes no difference.
This happens sporadically, and under different circumstances: sometimes whilst saving Form design or VBA code changes, sometimes when several Forms are open and in use.
If attempting to save design changes, and this error occurs, the Access objects are corrupted and can't be recovered.
Any suggestions on what might be causing this would be very welcome.
MTIA
The VBA project in your front end is likely corrupted. You need to rebuild it from scratch and then use proper Access coding practices:
in VBE options, turn off COMPILE ON DEMAND (see Michael Kaplan's article on DECOMPILE for details of why).
in VBE options, turn on REQUIRE VARIABLE DECLARATION.
in the VBE, customize your toolbar so that the COMPILE button is easily accessible (it's on the Debug menu). I also recommend adding the CALL STACK button (from the VIEW menu), as it's handy for debugging errors in break mode. The point here is to make debugging and compiling as easy as possible.
having set up your environment, go through all the modules in your newly recovered project and add OPTION EXPLICIT to the top of every module that lacks it. Then compile. You'll quickly find out where you have invalid code and you'll need to fix it.
from now on, when programming, compile frequently, after every two or three lines of code. I probably compile my project 100 or more times a day when coding.
periodically decompile your project and compact and recompile it. This will clean out any crud that accumulates during regular development.
These practices insure that the code in a non-corrupt project stays in as clean a condition as possible. It will do nothing to recover an already corrupted project.
In regard to how to rebuild the project, I think I'd go the drastic route of exporting all the objects with Application.SaveAsText and importing them into a new blank database with Application.LoadFromText. This is superior to simply importing from your existing corrupted front end because the import can import corrupt structures that won't survive a SaveAsText/LoadFromText cycle.
I program daily in Access, working with non-trivial apps that use lots of code, including plenty of standalone class modules. I have not lost an object to code corruption in over 5 years, and that was back in the day when I was still using A97.
Having tripped across this old post of mine, and seeing it's had a fair bit of interest, I thought maybe an update would be in order?
So 2 years down the track, doing a lot of 2007 app work as well as older 2003 (and even '97) apps, I'm finding that 2007 is less prone to really nasty crashes than 2003 - where Access object definitions (forms and reports esp.) would be easily corrupted.
I still follow the suggestions 1-6 (above) by David-W-Fenton religiously though, plus the use of Application.SaveAsText (see Tony Toews' suggestion and link above).
These days, whether it's 97, 2003 or 2007 I'm working on, if Access gives any hint of "being weird | crashing | throwing inexplicable errors" etc, I do the following:
Immediately close the Access app
Backup the mdb/accdb file
Re-open the app whilst holding down [Shift] so nothing runs
Export all objects as text using Application.SaveAsText (as another backup)
Close and re-open the app using the /decompile switch
Recompile the VBA code
Do a Compact/Repair.
This doesn't solve everything, but it does significantly reduce the number of corruptions of Access objects from what I'm able to observe.
Oh my.
I worked in a shop for many years that used Access as their platform of choice. The application eventually got so large that it began hitting an internal memory limitation of Access 2003. They began experiencing the exact same problem that you are having. As you have noticed, there is no external indication of memory problems when this happens.
The company talked at length with Microsoft about the problem, and I believe Microsoft eventually supplied them with a patch. So you might want to talk to Microsoft about this, if it sounds like a similar situation to what you are experiencing, as they may be able to supply you with the same patch.
Ultimately the long-term solution is to break the application into smaller pieces. Moving to Access 2007 didn't help; in fact, it made things worse because Access 2007 has more moving parts.
Quick solution; guaranteed to work:
Open VBA (Alt-F11)
In the immediate window enter the following:
Application.SaveAsText acForm, "corrupt form name here", CurrentProject.Path & "\zzTempRevive"
then
Application.LoadFromText acForm, "corrupt form name here", CurrentProject.Path & "\zzTempRevive"
That's it :) Hope this helps others!
This is also the default error message when Access has no idea what the problem actually is. Now if your MDB is particularly large, say more than 800 forms and reports with modules then, yes the MDB could be too large although that gave you a message when you went to create MDEs. ACC2000: "Microsoft Access Was Unable to Create an MDE Database" Error Message
I have had this happen occasionally myself. And my current MDBs aren't quite that large. Note that compact and repair doesn't detect errors in objects other than tables, indexes or relationships. So importing into another MDB is the only way to correct these errors.
Are you working on this MDB over the network? That's about the only thing I can think of that might cause this problem.
As I know that it's either forms or reports that most likely get corrupted, I created a new mdb, and only imported tables (attached), queries, scripts (one only), modules and menus. Then I used LoadFromText to import Forms and Reports via a function, and then did the usual decompile/compile and compact/repair etc.
So far, touch wood, I haven't had another crash in some days, so I'll probably stick with this recovery method.
Many thanks to all for your suggestions.
I have encountered this problem many times and finally found a solution that worked. I don't know what causes the problem, but I do know how to solve it.
Usually the error occurs when you open a form. What you need to do is completely re-create that form. The easiest way to do so is to first export the form to a text file with the undocumented function Application.SaveAsText. Then you delete the form from your database and re-load it with Application.LoadFromText.
The database that I am working on (in MS-Access XP) seems to have become corrupted somehow. It no longer supports any events - clicks, change, update events, nothing seems to work. This is the error that I get:
The expression On Change you entered as the event property setting produced the following error: Object or class does not support the set of events.
What can I do to make events start working again? I have tried Tools->Database Utilities->Compact and Repair Database..., but it didn't help at all. Also, it hasn't been like this the whole time - events were originally working, but now nothing works, not even the auto-generated command buttons.
Compact and repair generally won't solve problems that happens in objects other than tables and indexes. Importing usually fixes those but maybe try a decompile and then an import. Decompile or how to reduce Microsoft Access MDB/MDE size and decrease start-up times
I encountered the same problem once and documented my trouble shooting steps here. The expression On Click you entered ...
Also see Corrupt Objects within a Corrupt Microsoft Access MDB
Long discussion summarized.
One page that might have a solution that might help is Errors using multiple versions of Access under Vista/Windows 7 This is basically a permissions problem into the registry.
Another suggestion is to to repair the Office 2003 installation in control panel. A2003 then reverts to using Version 11 of the library, but only until A2007 is used again, then the problem reappears.
The original poster stated "Okay, after a few restarts, it seems that removing the 2007 runtime did fix the problem for me. "
Tony alluded to this in his long string of comments, but this sounds exactly like the dueling Access registration problem. I hadn't used A2007 until recently (I had the runtime installed to test if a database developed in A2003 could be deployed under it -- it could -- but hadn't used it since that testing was completely), and when I run A2007 after I've been using A2003, it has to reconfigure itself. The other day, something went wrong during the A2003 reconfiguration (after having last run A2007) and I got errors similar to yours. Running A2007 (to re-register everything as A2007) and then running A2003 (to re-register everything as A2003) fixed the problem.
The key is that when the re-registration fails, Access doesn't necessarily know it the next time it runs, so you end up running in an environment that is partly registered for A2003 and partly for A2007. The way to restore it is to run the other version of Access. That is, if A2003 is launching without the reconfiguration notice, then close it down and run A2007 so it reconfigures itself and re-registers itself as the real Access. Then when you run A2003 next, it will re-register itself as the authoritative version of Access and your A2003 app should have all of its references in proper shape.
Yes, this is very annoying.
And time-consuming.
I don't know why MS seems to think this is something that doesn't need to be fixed. While I know they don't give a rat's ass about developers who need to run A2003 and A2007 side by side, there are plenty of end users who might have an A2007 runtime app installed but also have A2003 installed as part of their base Office installation.
This has been going on forever, so I doubt it will ever be fixed.
I have encountered the same problems many times in Access 2013. From a page on MS web site, I found the answer which solved my problem. I am sharing it here.
I copied the code safely somewhere else outside Access, in the Notepad++.
Then I deleted entire vent Procedure, with its code, which was not firing.
Created fresh Event procedure, and restored the code from Notepad++ to the newly created Event Procedure.
The event earlier not firing started without any glitch. The issue got solved.
I don't know why the problem appears. This problem has come up many times and every time it is resolved with the same solution.
Try it.
Try to decompile and recompile the database.
If that does not work, I usually create a new database and import everything from this one to the new one. If something is corrupted, I will encounter issues at that time and be able to fix it.
Can you see the code in your code modules? If so, cut and paste it somewhere safe. Then flip the HasModule setting for each form to false, repair the database, and restore the code to newly created code modules.
You decompile the database by adding the flag /decompile to the start-up options i.e.
msaccess.exe “C:\my_folder\mydb.mdb” /decompile
I find that solves most of my problems. If not then another one is to re-secure the database by running the security wizard. This basically makes a new db and imports all the objects for you
I had a similar problem. When it started I created a new version of the code by copying the database. This did not help. However, deleting the form from the new database and importing it from the original solved the issue. I did not receive any warnings of corrupted code or other. It simply just worked without any changes to the VBA etc. Bit weird all in all
I compacted the database (Access 2010) into a new one. No joy. Deleted the form that was not working and imported it from the old database. No joy. Recompiled. JOY! Not sure why it quit and why it now works. I suspect a problem with a large amount of text in a linked text box on the form.
I have created an MS Access 2003 application, set up as a split front-end/back-end configuration, with a user group of about five people. The front end .mdb sits on a network file server, and it contains all the queries, forms, reports, and VBA code, plus links to all the tables in the back end .mdb and some links to ODBC data sources like an AS/400. The back end sits on the same network file server, and it just has the table data in it.
This was working well until I "went live" and my handful of users started coming up with enhancement requests, bug reports, etc. I have been rolling out new code by developing/testing in my own copy of the front-end .mdb in another network folder (which is linked to the same back-end .mdb), then posting my completed file in a "come-and-get-it" folder, alerting the users, and they go copy/paste the new front-end file to their own folders on the network. This way, each user can update their front end when they're at a 'stopping point' without having to boot everyone out at once.
I've found that when I'm developing now, sometimes Access becomes extremely slow. Like, when I am developing a form and attempt to click a drop-down on the properties box, the drop-down arrow will push in, but it will take a few seconds before the list of options appears. Or there's tons of lag in selecting & moving controls on a form. Or lots of keyboard lag.
Then, at other times, there's no lag at all.
I'm wondering if it's because I'm linked to the same back end as the other users. I did make a reasonable effort to set up the queries, forms, reports etc. with minimal record locking, if any at all, depending on the need. But I may have missed something, or perhaps there is some other performance issue I need to address.
But I'm wondering if there is an even better way for me to set up my own development back-end .mdb, so I can be testing my code on "safe" data instead of the same live data as the rest of the users. I'm afraid that it's only a matter of time before I corrupt some data, probably at the worst possible moment.
Obviously, I could just set up a separate back-end .mdb and manually reconfigure the table links in the front end every time, using the Linked Table Manager. But I'm hoping there is a more elegant solution than that.
And I'm wondering if there are any other performance issues I should be considering in this multi-user, split database configuration.
EDIT: I should have added that I'm stuck with MS Access (not MS-SQL or any other "real" back end); for more details see my comment to this post.
If all your users are sharing the front end, that's THE WRONG CONFIGURATION.
Each user should have an individual copy of the front end. Sharing a front end is guaranteed to lead to frequent corruption of the shared front end, as well as odd corruptions of forms and modules in the front end.
It's not clear to me how you could be developing in the same copy of the front end that the end users are using, since starting with A2000, that is prohibited (because of the "monolithic save model," where the entire VBA project is stored in a single BLOB field in a single record in one of the system tables).
I really don't think the problems are caused by using the production data (though it's likely not a good idea to develop against production data, as others have said). I think they are caused by poor coding practices and lack of maintainance of your front end code.
turn off COMPILE ON DEMAND in the VBE options.
make sure you require OPTION EXPLICIT.
compile your code frequently, after every few lines of code -- to make this easy, add the COMPILE button to your VBE toolbar (while I'm at it, I also add the CALL STACK button).
periodically make a backup of your front end and decompile and recompile the code. This is accomplished by launching Access with the /decompile switch, opening your front end, closing Access, opening your front end with Access (with the SHIFT key held down to bypass the startup code), then compacting the decompiled front end (with the SHIFT key held down), then compiling the whole project and compacting one last time. You should do this before any major code release.
A few other thoughts:
you don't say if it's a Windows server. Linux servers accessed over SAMBA have exhibited problems in the past (though some people swear by them and say they're vastly faster than Windows servers), and historically Novell servers have needed to have settings tweaked to enable Jet files to be reliably edited. There are also some settings (like OPLOCKS) that can be adjusted on a Windows server to make things work better.
store your Jet MDBs in shares with short paths. \Server\Data\MyProject\MyReallyLongFolderName\Access\Databases\ is going to be much slower reading data than \Server\Databases. This really makes a huge difference.
linked tables store metadata that can become outdated. There are two easy steps and one drastic one to be taken to fix it. First, compact the back end, and then compact the front end. That's the easy one. If that doesn't help, completely delete the links and recreate them from scratch.
you might also consider distributing an MDE to your end users instead of an MDB, as it cannot uncompile (which an MDB can).
see Tony Toews's Performance FAQ for other generalized performance information.
1) Relink Access tables from code
http://www.mvps.org/access/tables/tbl0009.htm
Once I'm ready to publish a new MDE to the users I relink the tables, make the MDE and copy the MDE to the server.
2) I specifically created the free Auto FE Updater utility so that I could make changes to the FE MDE as often as I wanted and be quite confident that the next time someone went to run the app that it would pull in the latest version. For more info on the errors or the Auto FE Updater utility see the free Auto FE Updater utility at http://www.granite.ab.ca/access/autofe.htm at my website to keep the FE on each PC up to date.
3) Now when working on site at a clients I make the updates to the table structure after hours when everyone is out of the system. See HOW TO: Detect User Idle Time or Inactivity in Access 2000 (Q210297) http://support.microsoft.com/?kbid=210297 ACC: How to Detect User Idle Time or Inactivity (Q128814) http://support.microsoft.com/?kbid=128814
However we found that the code which runs on the timer event must be disabled for the programmers. Otherwise weird things start happening when you're editing code.
Also print preview would sometimes not allow the users to run a menu item to export the report to Excel or others. So you had to right click on the Previewed report to get some type of internal focus back on the report so they could then export it. This was also helped by extending the timer to five minutes.
The downside to extending the timer to five minutes was if a person stays in the same form and at the same control for considerable parts of the day, ie someone doing the same inquiries, the routine didn't realize that they had actually done something. I'll be putting in some logic sometime to reset this timer whenever they do something in the program.
4) In reference to another person commenting about scripts and such to update the schema see Compare'Em http://home.gci.net/~mike-noel/CompareEM-LITE/CompareEM.htm. While it has its quirks it does create the VBA code to update tables, fields, indexes and relationships.
Use VBA to unlink and re-link your tables to the new target when switching from dev to prod. It's been to many years for me to remember the syntax--I just know the function was simple to write.
Or use MS-Access to talk to MS-Access through ODBC, or some other data connection that lives outside of the client mdb.
As with all file base databases, you will eventually run into problems with peak usage or when you go over a small magical number somewhere between 2 and 30.
Also, Access tends to corrupt frequently, so backup, compact and repair need to be done on an frequent basis. 3rd party tools used to exist to automate this task.
As far as performance goes, the data is being processed client side, so you might want to use something like netmeter to watch how much data is going over the wire. The same principle about indexing and avoiding table scans apply to file base dbs as well.
Many good suggestions from other people. Here's my 2 millicents worth. My backend data is on server accessed through a Drive mapping. In my case, the Y drive. Production users get the mapping through a login script using active directory. Then the following scenarios are easily done by batch file:
Develop against local computer by doing a subst command in a batch file
run reports against last nights data by pointing Y to the backup server (read only)
run reports against end of month data by pointing to the right directory
test against specialized scenarios by keeping a special directory
In my environment (average 5 simultaneous users, 1000's of rows, not 10,000's.) corruption has occurred, but it's rare and manageable. Only once in the last several years have we resorted to the previous days backup. We use SQL Server for our higher volume stuff, but it's not as convenient to develop against, probably because we don't have a SQL admin on site.
You might also find some of the answers to this question (how to extract schemas from access) to be useful as well. Once you've extracted a schema using one of the techniques that were suggested you gain a whole range of new options like the ability to use source control on the schemas, as well as being able to easily build "clean" testing environments.
Edit to respond to comment:
There's no easy way to source control an Access database in it's native format, but schema files are just text files like any other. Hence, you can check them in and out of the source control software of your choice for easy version control/rollbacks.
Or course, it relies on you having a series of scripts set up to re-build your database from the schema. Once you do, it's normally fairly trivial to create an option/alternative version that rebuilds it in a different location, allowing you to build test environments from any previous committed version of the schema. I hope that clarifies a bit!
If you want to update the back end MDB schema automatically when you release a new FE to the clients then see Compare'Em http://home.gci.net/~mike-noel/CompareEM-LITE/CompareEM.htm will happily generate the VBA code need to recreate an MDB. Or the code to create the differences between two MDBs so you can do a version upgrade of the already existing BE MDB. It's a bit quirky but works.
I use it all the time.
You need to understand that a shared mdb file for the data is not a robust solution. Microsoft would suggest that SQL Server or some other server based database would be a far better solution and would allow you to use the same access front end. The migration wizard would help you make the changeover if you wanted to go that way.
As another uses pointed out, corruption will occur. It is simply a question of how often, not if.
To understand the performance issues you need to understand that to the server the mdb file with the data in it is simply that, a file. Since no code runs on the server, the server does not understand transactions, record locking etc. It simply knows that there is a file that a bunch of people are trying to read and write simultaniously.
With a database system such as SQL Server, Oracle, DB2. MySQL etc. the database program runs on the server and looks to the server like a single program accessing the database file. It is the database program (running on the server) that handles record locking, transactions, concurrency, logging, data backup/recovery and all the other nice things one wants from a database.
Since a database program designed to run on the server is designed to do that and only that, it can do it far better and more efficently that a program like Access reading an writing a shared file (mdb).
There are two rules for developing against live data
The first rule is . . . never develop
against live data. Not ever.
The second rule is . . .never develop
against live data. Not ever.
You can programatically change the bindings for linked tables, so you can write a macro to change your links when you're deploying a new version.
The application is slow because it's MS Access, and it doesn't like many concurrent users (where many is any number > 1).