3

I have a working MS-Access project. All of the events and vba code functions as intended when existing as an .accdb

When I compile to a .accde all of the vba events tied to updating a textbox, combo box or clicking a button no longer run. I have tried different locations for the file and it still runs the same.

EDIT: Just double checked my trusted locations and the file is located in a trusted location. I even ticked the option to allow vba code to run no matter the security.

Also can confirm that the onLoad() events do work..

braX
  • 11,506
  • 5
  • 20
  • 33
Chris Chevalier
  • 620
  • 1
  • 7
  • 20
  • what are the settings in the trust center for the active x controls? – Sorceri Jan 27 '16 at 18:11
  • 2
    With the .accdb file try to manually run a 'Compile' command (VBA Editor --> Debug --> Compile) to ensure there is no warnings/issues as any compiler error can cause issues with a compiled .accde files not firing events – Fink Jan 27 '16 at 20:40
  • 1
    Is this both (.accdb working and .accde not working) on the same computer? – Andre Jan 27 '16 at 20:57

5 Answers5

3

With the .accdb file try to manually run a 'Compile' command (VBA Editor --> Debug --> Compile) to ensure there is no warnings/issues as any compiler error can cause issues with a compiled .accde files not firing events

this solved my problem

Andre
  • 26,751
  • 7
  • 36
  • 80
Chris Chevalier
  • 620
  • 1
  • 7
  • 20
  • You should **always** make sure your code compiles. It helps to add Debug -> Compile to the VBA Editor toolbar. – Andre Jan 29 '16 at 16:21
  • 1
    How do you create an ACCDE from an ACCDB if the ACCDB won't compile without error? I thought compile is part of the conversion process and have seen the conversion fail due to compile errors. – HansUp Jan 29 '16 at 17:23
  • @hansup That is why I am confused as well.. creating the accde I never had error. And compiling it from there had no errors either but solved it. – Chris Chevalier Jan 29 '16 at 17:57
  • I added some comments and hit compile again. Then it started working. My code didn't change. I'm convinced Access is a wreck and doesn't know what the hell is going on. – HackSlash Aug 21 '18 at 22:40
2

I had the same problem as Chris Chevalier above, and I would have been pulling out my hair, if I had any left.

[Extensive description deleted - it merely showed what I tried that DID NOT work]

Here's what I did that WORKED:

[THE STEPS I WENT THROUGH]

  1. Created a new database; imported all native tables (2), re-linked all linked tables (9), imported modules (1) and queries (numerous). Imported all forms that had minimal VBA code in their modules (about 8).
  2. Tested Operation so far. Made sure I knew what should work and what not to try yet.
  3. Created .accde file and tested it. It worked, therefore, so far, so good.
  4. Began importing the more complex-VBA-code-module forms, one at a time. After each import, I would test the functionality of that form and its code, then created the .accde file (numbered sequentially so I could track what I was doing) and tested that. For the first few forms, it worked fine, then on one form import, it crashed.
  5. Went back to the original .accdb file and looked at the code for the form that made the .accde file crash (not run VBA code). Fortunately, there were only 3 procedures in that form's code module, two were simple code, and one was (critical point) an EMPTY ONCLOSE EVENT PROCEDURE.
  6. I deleted the empty event procedure, re-created the .accde file, and it WORKED!!

[THE SOLUTION]

I went back to the original .accdb file - the full program that worked fine as an .accdb file but would not run VBA code as an .accde file - and I deleted the empty OnClose event procedure from the offending form's code module, re-created the .accde file for the full program, and IT NOW WORKS!

By deleting that single offending empty event procedure, the .accde file will now run all my VBA code.

This is what I found that works for me. It will take more experimentation (for which I don't have time right now) to determine if this is the cause of most similar instances of VBA code not running from an .accde file.

  • A full [Decompile](https://stackoverflow.com/a/3268188/3820271) might have helped, too. – Andre Dec 11 '19 at 23:12
  • This just helped me fix the same issue that I was getting on an Access 2016 (accdb) database. After I compiled into an executable (accde), none of the events were firing on the accde. The VB code was clean so the issue was driving me mad until I read this post and deleted all empty events in the VB code. Now the compiled accde works perfectly. – Pay it forward Nov 25 '21 at 13:38
0

OK with a quick little DB App on Access 2013 I ran into this problem. I found several different explanation across multiple support sites like this one, but every one had been left open without a solution or at least a solution that worked for me. The Trusted location solution had no effect, recompiling the code, deleting the VB in the form -saving the form (sans code) and then replacing the code in the form and compiling did not work.

So let's get this straight: the accdb has gone through multiple testing and debug compile completes with out note and has been used operationally for half a year. However, when I decided to harden the Db making both the front end and back end accde files, the back end compiled (there is locking code in the backend) and the accde worked fine, the front end compiled with out error, but the accde file none of it VBA worked. The default startup form opened, but none of the vb subs seemed to be executed - the form_load sub didn't do anything and when the buttons were pressed nothing happened (all except the button that executed an embedded macro - that button worked).

After trying all the different solutions and banging my head on the wall for a while I decided it had to be something in the original accbd file. So I created a new blank accdb and imported all the Table links, forms, Queries, and modules into the new db. Tested the accdb and everything was working; compiled and made the accde - it didn't work. Same problem. hummmm? It's not the Access installation because the back end compiles and it's accde works fine. I thought I reestablished the link between the form(s) and the VB by deleting the code and saving the form without the code, then adding(pasting from notepad) the code back in and saving the form again, but that didn't work. So I tried an experiment. I created a new form with a button that ran code to pop up a message, compiled the DB and made the accde and the new form worked (all the others still didn't). Would I have to remake every form? Well let's try a short cut I copied and pasted each form to it's original name with a 2 appended, then deleted every original form and renamed all the copies. Some quick tests and all the DB functions are fine, the compile is fine and the Accde --- it works! No code change; no error to find - just recopying the form(s) some how reconnected the VB to the forms once the DB was made into a ACCDE.

Mark Sowards
  • 171
  • 1
  • 5
  • 13
0

I was facing similar issue.I just opened .accdb file which was working perfectly, then went to vba code & deleted all my empty functions. After that .accde file works perfectly

Saad Khawaja
  • 96
  • 1
  • 4
-1

This is a dangerous flaw in Access since there is no warning that the code has failed. While compiling the code before creating the .accde file does correct the problem, if you forget this step catastrophic results could ensue.

In my case, I had code to link to the backend in the same folder as the front end. As a result of this flaw the front end was linked and records were written to the wrong backend.

It happened that on my opening form I had a text box referencing a subroutine to calculate the data path of the backend which gave a "#Name?" error when loaded. I have now made use of this by hiding that text box and naming it txtTestCode and using an On Open macro event "If IsError([txtTestCode])" to generate a messagebox to warn that the "Code is not running, run Debug>Compile on .accdb to check for errors and remove empty Sub or Function declarations." Note that using code rather than a macro would fail in this case.

I now use DLookUp("[Database]","[MSysObjects]","Name = ""AnyLinkedTable""") to provide the backend data path so it will show even when the code fails.

PJD
  • 1
  • 2
  • This does not seem to provide and answer to the OP's question. If you can explain how it does, I'll remove my comment, otherwise you should consider removing this as an answer. – Rich Michaels Nov 29 '20 at 20:12