I have a Access ADP Project that has been a continus project for the last 6 years, so it has hundreds of forms and thosands line of VBA code. After a recent update it not wont compile to create the ADE file. It tells me one of the text boxes does not exist but it does. I deleted the for and re imported it from a working backup and still the same error. I have tryed Importing the whole project into a new ADP file and still wont compile, tryed compact and repair and also /decompile
Does anyone no of any tricks or software package to help fix this problem?
I don't work with ADPs, but in MDBs, there are differences between these two syntaxes for referring to controls on a form:
Me.MyControl
Me!MyControl
The first causes Access to create a hidden property that returns the control. The result of this is compile-time checking of references to controls.
The second uses the default collection of the current form and does not provide compile-time checking.
I assume that VBA works the same in ADPs as in MDBs, so why not try converting the offending control references to bang instead of dot? This would eliminate the compile-time checking and might allow the project to compile without having to reconstruct it laboriously.
If that works, I think I would then try deleting the control (to removed the hidden property definition) and add the control back with a new name and then compact (I don't know if ADPs can be decompiled, but if they can, it should be decompiled as well). Theoretically, this should remove the problematic hidden property definition permanently and if that's the cause of the problem, you should be able to revert to the dot operator and get compile-time checking back.
For what it's worth, I've seen too many corruption problems with the dot operator and always use the bang in all my projects. I'm OK with not having compile-time checking of control references.
And, oh, BTW, with the bang you lose automatic Intellisense (which in some cases is a blessing as Intellisense can get in your way in some contexts), but you can invoke a different Intellisense list with CTRL-SPACE. This list is not limited to the control type, but once you start typing, you get the usual autocomplete that jumps you to the appropriate location in the list.
Sometimes it helps to start a new, empty project and then import all forms/reports/modules from the old one.
If birger's approach doesn't do the trick, consider saving each module using the SaveAsText method. Then, as birger suggested, import, but ONLY the forms, and tables. Then, recreate the modules, using the LoadFromText method.
Sometimes, I found out that I need to manual click Debug -> Compile before making ADE files.
This following steps may help for unable-compile ADP file:
Debug -> Compile
Compact/Repair
then make ADE
Related
The Setup
I have a VB6 dll that works with an Access 2013 application.
There are two versions: dev.dll and prod.dll.
Both share the same code, but differ only by name (which should make them distinct COM objects).
To deploy, I:
Make prod.dll
Copy the development .accdb file to the production version
In production, change the dev.dll reference to prod.dll
The Problem
After doing this, I happened to recheck the dll reference in the development version. It was prod.dll -- not dev.dll as I was expecting!
Curious, I opened both the development and production .accdb files side-by-side.
Sure enough, when I changed the reference for one file, some invisible hand changed the reference in the other.
This behavior persisted when I opened one file by itself and changed its reference. After closing it and reopened the other, the reference had auto-magically changed.
Everything compiles OK. There are no orphan MSACCESS.exe instances floating around in Task Manager.
Questions
Has anyone else observed this behavior?
Should I worry about this?
Is there a fix?
Well some reference to some other Access database is NOT being added or changed out of the blue here.
You ALREADY have a reference to that registered .dll in BOTH applications. If you re-reigsiter the .dll, and regiser under the same name, then both applcations will still go look for that regisered dll by the name you gave it and thus both will change.
I mean, fire up a access database WITHOUT a reference to the regisered .dll, and THEN see what happens?
Answer: nothing at all!!!!
So, access does on startup try to load nd find the regisered .dll. In fact, you see this if you have say a reference to Excel 14. Now run the same applcation on a computer with Excel 15 or 16 - guess, what, the reference changes!!!!
so you have not shared your regsvr32 command you are using, but they have both a .dll, and the name that will appear when you use VBA->tools->references and set a reference to that .dll. If you THEN re-register the .dll, but the text for the reference in VBA stays the same, then access will flip and use the new registered .dll. Unless you give a 100% different name for the text part, then re-registering the .dll means that access on startup is able to see and find the text part name used, and thus will flip and now point to the new .dll.
And bonus question:
Do and can and do you have BOTH .dlls regiserted at the same time and on the same computer? Since if you do, then they will have not only a different path to the .dll, but ALSO a different name and text that displays, right?
So, if both .dlls are regisered on the computer at the same time, then they have different names, and thus this flip will not occur then, will it?
But, you not AT ANY POINT in time demonstrating that some accDB file by magic get, or has or sees some new reference set out of the blue. Your testing and example has the databases WITH AN ALREADY reference set, and you now re-registering the .dll used, but with the same name!!! it is for this reason the flip is occurring here, since the path name to the .dll changes, but not the text reference you see/use/pick when setting up the reference in the first place.
In fact, I would suggest you test this with both .dll's registered, and then set a reference in Access to both .dlls at the same time. Doing so will make what is occurring here very clear!
Now, it is possible that the above is not your case and scenario, and somthing else may well be going on here. But, I would test this with BOTH .dlls registered, and in VBA references settings, now have a reference to both .dlls. Do that, and you get your answer as to what is going on here.
I tried this on Access 2016, but I'm pretty sure this has always been like that since the first versions.
Let's use a formula in a report field, in this case Mid("abc",2):
When I show the report, the result is correct:
Now, if for any reason i've got a syntax error in a VBA Module (I cannot exclude that other categories of problems lead to the same result), not related with the function I've used in my formula, the formula goes into an error state, displaying "#Name?" error message.
And this is the result:
Well this is quite scary because it means that a report that is already validated and used can always show an error and omit information because an error is present in an non-related module.
Potentially ALL the report formula could get broken because a bug in a module; in complex reports with a lot of fields, this can go unnoticed till a customer realizes that instead of a crucial information "#Name?" is written.
I would like to prevent this scenario. Is it possible to raise an exception in the case of a broken formula, instead of just showing #Name?
Are there any other possibilities to achieve this level of reliability?
No, there is not, at least not really.
There is really only one way to avoid this: make sure your code compiles. If your code can't compile, then none of the functions can be trusted. Since VBA allows overriding functions, that's a good thing, since you might've declared a function named Mid somewhere in that section that doesn't compile and might expect the code to use that. Not compiling equals "not a clue what's going on, nothing can be trusted".
For simple projects, the fix is to mash that compile button (Debug -> Compile) after every single change and to never accept a failure to compile.
For more complex projects, you can organize code in different files and reference them (see this answer), and if one file fails to compile, that'll only affect code that references anything from that file (make sure to rename the VB project of each file to avoid name conflicts). For some projects, it's sensible to use this to keep data, forms and reports, and modules all in separate files.
is there a way to trace the compiler command for flash builder? I mean, I want to know the parameters and files that is compiling internally when I click "build" on FB.
Basically I moved a project to Flash Builder, and everything works fine but I have some runtime issues, and looks like the compiler is doing something wrong with some files (like using old files instead of using the one im changing, this occur only for a particular file, the rest works fine or I think that works fine). Also is different the way to embed some file, that's another reason to check what's doing internally.
I ran the game with mxmlc before, and probably I can compare what's the difference if I get the command executed by FB.
Also, I want to know how to do it if I need to research something in future.
Thanks for any help,
Regards
Flash Builder only recompiles if there has been a change to the code. So if you are changing an asset (image), for example, you won't recompile unless you also make a change to the project.
There are a few ways around this:
Easiest way is to just go into a file and press the space bar at the end of a line. It will add an extra byte to your file, but not to the project (compiler is "smart" and gets rid of unused files, classes, and characters). Since this is not a common thing, it shouldn't be an issue
Project->Clean.... That will force your workspace to rebuild and, in most cases, will also recompile your project
If #2 is failing, first delete bin-debug or whatever you are using as your debug folder, then run Project->Clean...
It's a tad bit annoying (especially when editing external libraries), but it allows for quicker re-launches of the debugger, which is the ultimate goal of that behavior.
I'm making some significant changes to some VBA code, and some variables are being deleted and/or renamed. It would be a lot easier to find all the locations I need to update if the compiler would complain to me that the variables don't exist instead of creating it on the fly.
How do I force VBA/Access to require variables to be declared?
You need to use Option Explicit at the top of each VBA code module including forms and reports.
You can set this for all future created modules and VBA code behind forms and reports by going into the VBA editor >> Tools >> Options >> Editor tab and ensuring Require Variable Declaration is checked.
From Access 2003 help:
Require Variable Declaration — Determines whether explicit variable declarations are required in modules. Selecting this adds the Option Explicit statement to general declarations in any new module.
I also use camel case when I Dim my variables. ThisIsAnExampleOfCamelCase. As soon as I exit the VBA code line if Access doesn't change the lower case variable to camel case then I know I've got a typo.
Some History on OPTION EXPLICIT and Access VBA
To follow on from Tony's answer, here's some explanation of why there are issues with OPTION EXPLICIT not being on in some Access code modules.
In Access 95 and Access 97 (the first two Office versions with VBA), Access had a different code editor than the other office programs. In Access 2000, Microsoft implemented the VBE from the other Office apps in Access. At the same time, MS chose to make Access VBA modules behave like the modules in the other apps, which defaulted to not having OPTION EXPLICIT.
Thus, in Access 2000, by default, modules were created without OPTION EXPLICIT.
This was, of course, a really stupid design decision on MS's part, and they reversed it later (I can't remember if it was Access 2002 or 2003 that rectified the problem and defaulted to OPTION EXPLICIT in all new modules again). The reason it was dumb (and MS should have known this) is because Access is a DATABASE APPLICATION DEVELOPMENT tool, and thus is operating on data that is strongly typed. Thus, the code environment should be strongly typed by default so that it is in harmony with the data it is working with.
In Excel or Word, the data is not strongly typed, and it thus makes more sense to use variant data types for just about everything, simply to make it easier for everyone. The downside of implementing that by not using OPTION EXPLICIT is that you can end up with typos that automatically intrdoduce new variables [such as the variable "intrdoduce" -- if I was writing this post with OPTION EXPLICIT, that wouldn't have happened without producing a runtime error! :)]. This is a problem with all such languages that work this way (I pull my hair out working in PHP, where variable names can be distinct by case, i.e., $Var is not the same variable as $var; but I digress), but MS made the decision to implement it that way in Word and Excel on the theory that the people writing code there are going to have an easier time of it if they aren't forced to declare their variables.
So, MS made the mistake of making Access's version of the VBE like the other apps, even though there was no logic internal to Access's own purposes that supported that move. And MS then backed out that change and returned to the previous status quo (i.e., OPTION EXPLICIT by default in all modules).
Thus, you will often see apps that began life in Access 2000 that have modules all over the place without OPTION EXPLICIT. When I have to work on such an app, my first task is to implement OPTION EXPLICIT in all modules and then fix the damned thing so it will compile (which is often quite tough, given that the thing was programmed without it).
This question was quite helpful for Excel, you might see if it'll work for Access:
Lost Variables
Essentialy, MZ-Tools will search through your code and tell you what is not being used. The version for VBA can be found here. Use the Review Source Code feature.
I have a missing reference listed in my References list (in the VBA Code view). It's a reference to an OCX for a product that we no longer use.
I'm fine with removing(unchecking) the reference, but I'm wondering if that is going to come back to bite me.
Is there a way to find out in which forms/reports it might have been used?
Is removing it and then doing a compile of the MDB sufficient?
I believe if you are using Option Strict, then the compile should catch any issues where you have referenced an object that no longer exists
The compile might not catch it if it's using late binding, but usually it'll catch it in the compile. You can also do some testing by running the recompiled MDB.
If the product is a control, then Access doesn't (by default) let you look at the "source" like that.
Otherwise I would do a search in the VBA code to see where it is created.
eg:
Dim p as New Old_Product
Then do a search for Old_Product across the project.
Depending on how mission critical your application is, I would remove it and see what happens.
I'm assuming that you have decommissioned the old product?
In my experience, Access Applications aren't mission critical. If they go down for an hour (while you try and fix the old reference) it isn't the end of the world.