If you are using VBA to perform actions on opening, saving or deleting record you have the option of putting the code in two different places.
Perhaps the most obvious is when you log in to RE as supervisor you can go into the Visual Basic for Applications environment (found under the Tools menu) and capture your events in the System project. This is the “inside” solution as it resides inside the database and can be programed from inside the RE application.
The other option is to use the RE7VBA tool. This executable is found in the Raiser’s Edge directory along side RE7.exe. Running this program opens up a similar environment except that you can save your work in a file and compile it to a DLL. This is the “outside” solution for opposite reasons
What are the pros and cons of each?
- Writing code on the “inside” is available immediately for everyone. This is a good and bad thing. This works well for simple business rules that should apply to everyone always. It also means that any mistakes will affect everyone too. Writing on the “outside” means that some users can have some customisations but not others.
- On the inside – You only need to install it in one place, you only need to update it in one place. Outside solutions need to be installed on each PC which can be a challenge for a large organisation.
- All code on the inside must reside in the same place. It is possible that you have conflicting code. Code that does different things and must be ordered for it to work. It also means that when you update the code you need to be careful you do not affect other items. Whereas code written outside can be split functionally.
- Code written for modal modules (such as import) can be debugged (sometimes – see next point) when developed on the outside whereas you cannot set break points when developing on the inside.
- There are instances where debuging on the outside solution crashes! These are known bugs (e.g. BB260636 and BB233120).
For development purposes my preference (despite the known crashes) is the outside method. Being able to step through import process is a real bonus and makes the whole process much more manageable.
Hello David,
We are experiencing that dll’s written with the RE7VBA tool is not running on certain databases.
The case seem to be that it is not running when you use the DLL on a database that has VBA not enabled. Any experience with that?
Hi Victor,
You are quite right. In order to be able to run a VBA script whether they are inside or out of Raiser’s Edge (i.e. written using the RE7VBA tool) you have to own the RE:VBA module. This is different from a plug-in where anyone can run them.