I am working on several different access projects that share a lot of code. Right now what I do is importing modules, which is fine as long as I'm the only one working on it, but for the future I need a better solution (also better than password protection).
What would be the best way to share code? I have Visual Studio 2013 for that purpose. I have tried creating a dll and com objects, but I couldn't add the files as a reference to Access, I think maybe it's because it was .NET, I'm not really sure.
As you can see I am not familiar with this subject, and so any hints/links/buzz words would bee highly appreciated.
Thanks, Yotam
One way to share code among VBA projects is to store the common code in a separate .accdb file (say, "CommonCode.accdb") and then add a Reference to that file in the various VBA projects that will use those common procedures and functions.
To add such a reference you need to click the "Browse..." button in the References dialog and then choose "Microsoft Access Databases (*.accdb)" from the "Files of Type" drop-down:
I believe that the best way to share a VBA code is not to let it readable, but compiled.
You can do this by creating an Access Runtime, .accdr.
version control with ms-access: check here and there
well ... these are the links to my own answers to this question, but I do not mind if you check and prefer other's answers
Related
I have seen numerous examples on some SharePoint blogs regarding the use of the SPWebConfigurationModification class to modify SharePoint's web.config.
However, I noticed some examples call the update method at different times. For example:
myWebApp.Update();
myWebApp.Farm.Services.GetValue<SPWebService>().ApplyWebConfigModifications();
Or
myWebApp.Farm.Services.GetValue<SPWebService>().ApplyWebConfigModifications();
myWebApp.Update();
Which is the correct way? The reason why I ask is because I get a "A web configuration modification operation is already running." error when deploying a custom page which requires modifications to the web.config to be made on load balanced server.
I am sure it is probably due to the fact that the web.config changes are not being saved correctly across multiple farms.
Thanks for any help.
The correct order is ApplyWebConfigModifications() then Update(). Are you encapsulating that code in SPSecurity.RunWithElevatedPrivileges?
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.
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
We have a website that uses #include file command to roll info into some web pages. The authors can access the text files to update things like the occasional class or contact information for the department.
My question is this, I don't see anyone using this method and wonder if it is a good idea to keep using it. If not, what method should I transition to instead?
I don't think there is anything wrong with it, and I've done some similar things with PHP. If the people that make the changes are comfortable with how they do it and they can do what they need to, I think you should stick with it. There could be some retraining involved and/or a fair amount of work involved for changing the system.
If you are using ASP.NET then you could bundle that code into a nice little UserControl that will display all of the important information.
Other platforms should allow you to bundle the logic into a class object, and display it using that.
It really depends on the platform that you are using to deploy the application in. The include file could be your best solution if you are deploying in a more limited platform.