1) Tool to convert VBA to C++ native code? 2) Does Access VBA App compile to native code or MSIL ?

Question

1 - Is there a tool to convert your Access VBA projcet (or portions of it) to C++ native code (not VB .NET MSIL managed code)

2 - When using Access 2007 or 2010... to compile an Access App (to MDE or ACCDE or ADE) so it can run on PC's that do not have Access installed...

Is that Access/VBA code compiled to native code or to .NET MSIL "managedcode" ??

Thanks for any help.

Answer 1

Access is only a Front End Application which allows you to view or write data into a database.  One example of a database is an mdb file, but there are many different type databases that Access can connect to.  the real application that does the connection is the Microsoft Jet Engine (or other drivers) which is part of Windows and doesn't require an Access license.

You can use a number of methods in C++ to connect to your database like ODBC which will accomplish your task.  You can even run some of your queries in you database remotely with SQL without having an Access License.

---

jdweng

Answer 2

Joel, thanks for the note on this but as stated in the other thread we don't have time right now to completely re-code the Access/VBA application in C++.

Regarding the original questions of this thread...

Regarding Question 1:
I would be surprised if there were a tool to convert VBA to C++... but I thought I would ask just in case... as I'm often surprised :)

Regarding Question 2:
I'm still looking for strong confirmation of how Access 2007 & 2010 compiles...

- When you compile an Access 2007 or 2010 project to an MDE or ACCDE or ADE file...

- Is it compiled to 'native code' or is it compiled to .NET MSIL 'managed code" ????

thanks for any help.

Answer 3

#1

I bet there is no such a tool. The only close thing I know is online code (read "syntax") converter 

http://www.developerfusion.com/tools/convert/vb-to-csharp/

#2

I think this kb http://support.microsoft.com/kb/209176 can explain better than I do.

---

Andrey V Artemyev | Saint-Petersburg, Russia
Russian blog artemyev.biztoolbox.ru

Answer 4

As Andrey said, no such tool that I know of to perform such a task that you request for @1 ...

#2

>> When using Access 2007 or 2010... to compile an Access App (to MDE or ACCDE or ADE) so it can run on PC's that do not have Access installed... <<

When you "compile" an Access Application to the MDE or ACCDE format, you are merely stripping the human readable code out of the file, then subsequently locking all code based objects (Forms, Reports, and Modules) from being edited.  With and MDE/ACCDE a user with full blown Access can easily modify your Query objects, Table objects, and Macro objects.

In order to use an Access application without having full blown Access on a client box, you will need to install the Access Runtime libraries for the version you wish to utilize (Access 2007 runtime or Access 2010 runtime).  Since A2007, the Runtime libraries are free to use and distribute, older versions were paid products.

---

Brent Spaulding | Access MVP

Answer 5

Hello Joel ...

>> Access is only a Front End Application which allows you to view or write data into a database.  One example of a database is an mdb file, but there are many different type databases that Access can connect to.  the real application that does the connection is the Microsoft Jet Engine (or other drivers) which is part of Windows and doesn't require an Access license. <<

A2007 and A2010 use Jet's successor named ACE (Access Connectivity Engine).  ACE is not part of Windows, but can be downloaded (here is the 2010 engine).

Also, it is important to note that the Access application is indeed comprized of two parts as you have implied/indicated -- the UI and the database engine.  Access uses the file format that the engine manages in order to store all the objects (at least for MDB's/ACCDB's -- ADP's are different).  Alone with that it is important to note that Access is bound to the engine in the sense that even if your backend is SQL Server, Access will require hooks into the Jet/ACE database engine (again, at least for MDB/ACCDB --- ADP's are different).

Click Here for details on how the Access Application is configured (I know you likely know all this Joel, but I thought I would 'add to the info' you have shared.

---

Brent Spaulding | Access MVP

Answer 6

Brent, thanks for your comments.

Regarding 'compiling' an Access Application to the MDE or ACCDE format _NOT_ preventing a user with full blown Access from accessing &/or changing the applications...Query objects, Table objects, and Macro objects. ...

1 - Is this a big issue? Most of the "intelligence" is in the code in the applications modules... right?

- If your goal is to make it as difficult as possible for someone to 'reverse engineer' an application...
- I would think the code would be the first priority...
- But it is disappointing that you can't protect the queries and table design...
- Regarding Macro's... again... I would think you would put everything in a vba module and not have any Macro's...
- However I've read that some people consider vba code in a modules as Macro's...
- I always thought it was a mis-use of terms... right?

Thanks again for your comments.

Answer 7

#1: There is no MS-based VBA code-conversion tool, but the following website is a review of several products which do that kind of thing

http://webpages.charter.net/bobalston/Documents/Access-WebConversionSoftware.htm

#2: VBA "compiles" into an intermediate P-code in a behind-the-scenes multi-stage compilation process. This p-code is NOT MSIL nor does it directly interface with the .Net framework at all. VBA is the same as the old VB6 dev environment with the restriction that it doesn't compile to native code but stops with the tokenized P-code stage (so no native .exe or .dll files can result). In a "compiled .Mde/.accde" database, the actual VBA source code is removed, leaving behind only the executable P-code image in the database.

HTH.

---

Mark Burns, MCAD, MCP
Sr. Microsoft Access Analyst/Developer
Manager LinkedIn.Com community: Professional Microsoft Access Developers Network (PMADN)

Answer 8

1 - Is there a tool to convert your Access VBA projcet (or portions of it) to C++ native code (not VB .NET MSIL managed code)

No such tool exists.  On the other hand I'm not aware of tools that did this for VB6, FoxPro or just about any other development product in the marketplace anyway.

However, if such a tool existed, you would only be converting the source code, but not the very LARGE NUMBER of dependencies that exist in Access such as the form system, the report's system, the ribbon system, and that of the database engine.

In other words because of so many dependencies such as the database engine etc, then a native compile option to convert the VBA code would not help very much.  The reason as such code would still have a vast dependency on the many components and pieces used by access from and the office suite. (so ribbon, database engine, VBA function set, the report library etc.).

For example VB6 used to have a native compile option as compared to the default p-code compile option. However EVEN when using the native compile option, VB6 still required a set of runtime libraries to be installed on the target computer.  And to be honest, the VB6 code spent a large portion of its time calling that library object model, and therefore using the p-code option as compared to the native compile option was little (small % of time spent in VB6 code anyway). The result usually did not yield a lot of difference in code execution speed. 

However to be fair, if you've turned off a few compiler options such as bounds checking for arrays etc in VB6, then I found code execution speed to be equal of native compiled c++ (they both compiled to native, so not a lot of difference in code speed should/would be seen).

However, I suspect the issue and goal here is NOT code speed, but more of an independent install.

In the case of Access when you compile a project down to an accDE, the source code is compiled into a p-code. While this setup is somewhat similar to .net managed code (they both use p-code) the VAST code libraries of Access would STILL be required regardless even if we had a native code compile vs. that of p-code.  And if you had a VBA to c++, you would STILL be dependent on forms or some VBA code that launches a complex report (remember, Access does not generate code for that report – it is an object with many settings that produces that result – kind of like how an html web page renders).

And to further confuse this issue, there is an increasing amount of managed code making is ways into the parts of the Access product.

One other difference when talking about VBA code (not .net managed), the resulting compiled VBA code to p-code is then executed by Access runtime library. This p-code interpreter does NOT have a JIT like .net net does (JIT = just in time compiler).  What this means is in effect .net managed code does eventually run as native code. This explains why .net code can run quite well. So .net code is not quite highly optimized as natively compiled c++ code, but it often really does not matter.

However I suspect your goal here is code independence as opposed to speed of execution. And in the case of Access such applications are bandwidth and hard drive disk limited as opposed to processing limited anyway. (throwing more processing at Access rare helps application speed).

So just keep in mind that the VBA compiler for Access code does not compile down to .net manage code.  In fact it's based on the same code base used for the VB6 compiler.

However as I've pointed out, such a native compile option for the actual VBA code you see would help a LITTLE in terms of reducing dependencies of all those things that Access uses such as the database engine, the report system or even the ribbon (fluent UI).

In other words what you would really need is not only a native compiler and code converter, but a linker that's capable of going out and statically linking in all those VAST large numbers of dependency of libraries of code that you depend on for the application to run.

In other words, if we had a code converter or even a native compile option, such an .exe file would be of little use without all those code dependent libraries we are using.

So unless we ALSO had a smart linker to pull in all those dependencies that could static or dynamic (.dlls) would not help. I suppose even if such a project would create com objects, this could work, but we don't have such a choice.

Is that Access/VBA code compiled to native code or to .NET MSIL "managedcode" ??

See above = Neither. Access uses the same compiler and p-code system as was used for VB6, but without the native compile option. As noted a native compile option does little to fix this issue of stand alone .exe unless we had a smart linker also.

Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

Answer 9

No one seems to have asked the obvious - What is the specific business need for the conversion?

---

David H