Creating An Executable (exe) Out Of Microsoft Access (mdb, mde) Tips and Tricks

Was this article helpfull to you ?


  • Total voters
    17

nIGHTmAYOR

Registered User.
Local time
Today, 13:42
Joined
Sep 2, 2008
Messages
240
As I got to see that this forum is really trying to help access programmers , I decided to use it to post my article in here to benefit its seekers .
Please do note the following :

Methods applied are unconventional and rely on my experimentation of the situation since I got to realize that there were minimal documentations for our subject of discussion J

Also please pardon my English , I've did my best yet it’s a fact that English is my third language.

Quick Introduction
Why wouldn't Microsoft make it easy to compile an MS Access Project into a distributed executable?
1 – Microsoft has managed to create a monster by creating MS Access , and by realizing the risk and the fact that they would have to put many applications (such as Axapta , Great Plains , mind you Visual Studio .net) to sleep , they had to cripple it a little from being a developers platform and tam it into becoming a small business solution.
2 – For a peculiar reason programmers through-out time have always been valued based on complexity and not on achievement (So an Oracle programmer would get paid for developing a phone book application yet an Access Programmer gets a tap on the back :) which leads elite programmers to refrain from such beast called Microsoft Access.

Now , Now enough chit chat and let's get to work:
Step 1 : Make sure that your application security is not reliant on Microsoft Security file .mdw (for many reasons 1st its unsecured , 2nd it would still give away that this is an MS Access application, 3rd it would conflict with users who have other access applications installed on their own PCs who are about to use yours) you will have to script your own security modal which isn’t so difficult , all you need is to script a login form , an administration form , and every form and report on your application to check if authorized to run or edit (On_Open event) and thus leading the Form/Report to close "DoCmd.Close Form.Name" Or denying data manipulation through "Form.AllowEdits = False" / "Form.AllowDeletions = False" (I am trying to make it look simple so you wouldn’t cry).

Step2: Make sure you have scripted your own menus and tool bars (it's easy and fun so don't you get lazy).

Step3: Make sure your Startup Form is selected , your databse window is set to hide and that you have your own icon installed as project and form icon (Insert icon in your project folder , use string ".\youriconname.ico" instead of full path because usually paths vary PC to Another ;)

Step4: Implement Microsoft Script disabling "Startup Form Over-ride by using Shift Key"

Create New Model :
Code:
[COLOR=black][FONT=Arial]Public Function SetProperties(strPropName As String, varPropType As Variant, varPropValue As Variant) As Integer[/FONT][/COLOR]
[COLOR=black][FONT=Arial]On Error GoTo Err_SetProperties[/FONT][/COLOR]
[COLOR=black][FONT=Arial]Dim db As DAO.Database, prp As DAO.Property[/FONT][/COLOR]
[COLOR=black][FONT=Arial]Set db = CurrentDb[/FONT][/COLOR]
[COLOR=black][FONT=Arial]db.Properties(strPropName) = varPropValue[/FONT][/COLOR]
[COLOR=black][FONT=Arial]SetProperties = True[/FONT][/COLOR]
[COLOR=black][FONT=Arial]Set db = Nothing[/FONT][/COLOR]
 
[COLOR=black][FONT=Arial]Exit_SetProperties:[/FONT][/COLOR]
[COLOR=black][FONT=Arial]Exit Function[/FONT][/COLOR]
 
[COLOR=black][FONT=Arial]Err_SetProperties:[/FONT][/COLOR]
[COLOR=black][FONT=Arial]If Err = 3270 Then 'Property not found[/FONT][/COLOR]
[COLOR=black][FONT=Arial]Set prp = db.CreateProperty(strPropName, varPropType, varPropValue)[/FONT][/COLOR]
[COLOR=black][FONT=Arial]db.Properties.Append prp[/FONT][/COLOR]
[COLOR=black][FONT=Arial]Resume Next[/FONT][/COLOR]
[COLOR=black][FONT=Arial]Else[/FONT][/COLOR]
[COLOR=black][FONT=Arial]SetProperties = False[/FONT][/COLOR]
[COLOR=black][FONT=Arial]MsgBox "Runtime Error # " & Err.Number & vbCrLf & vbLf & Err.Description[/FONT][/COLOR]
[COLOR=black][FONT=Arial]Resume Exit_SetProperties[/FONT][/COLOR]
[COLOR=black][FONT=Arial]End If[/FONT][/COLOR]
[COLOR=black][FONT=Arial]End Function[/FONT][/COLOR]
……………………………
Now Create a label named bDisableBypassKey and add the following code to its Click event :

Code:
[FONT=Arial]Private Sub bDisableBypassKey_Click()[/FONT]
[FONT=Arial]On Error GoTo Err_bDisableBypassKey_Click[/FONT]
[FONT=Arial]'Dim strInput As String[/FONT]
[FONT=Arial]'Dim strMsg As String[/FONT]
[FONT=Arial]'Beep[/FONT]
[FONT=Arial]'strMsg = "Do you want to enable the Bypass Key?" & vbCrLf & vbLf & "Please key the [/FONT]
[FONT=Arial]'programmer's password to enable the Bypass Key."[/FONT]
[FONT=Arial]'strInput = InputBox(Prompt:=strMsg, Title:="Disable Bypass Key Password")[/FONT]
[FONT=Arial]'If strInput = "TypeYourPasswordHere" Then[/FONT]
[FONT=Arial]' SetProperties "AllowBypassKey", dbBoolean, True[/FONT]
[FONT=Arial]' Beep[/FONT]
[FONT=Arial]' MsgBox "The Bypass Key has been enabled." & vbCrLf & vbLf & "The Shift key will allow the users to bypass the startup options the next time the database is opened.", vbInformation, "Set Startup Properties"[/FONT]
[FONT=Arial]'Else[/FONT]
[FONT=Arial]Beep[/FONT]
[FONT=Arial]SetProperties "AllowBypassKey", dbBoolean, False[/FONT]
[FONT=Arial]' MsgBox "Incorrect ''AllowBypassKey'' Password!" & vbCrLf & vbLf & "The Bypass Key was disabled." & vbCrLf & vbLf & "The Shift key will NOT allow the users to bypass the startup options the next time the database is opened.", vbCritical, "Invalid Password"[/FONT]
[FONT=Arial]'Exit Sub[/FONT]
[FONT=Arial]' End If[/FONT]
[FONT=Arial]Exit_bDisableBypassKey_Click:[/FONT]
[FONT=Arial]Exit Sub[/FONT]
[FONT=Arial]Err_bDisableBypassKey_Click:[/FONT]
[FONT=Arial]MsgBox "Runtime Error # " & Err.Number & vbCrLf & vbLf & Err.Description[/FONT]
[FONT=Arial]Resume Exit_bDisableBypassKey_Click[/FONT]
[FONT=Arial]End Sub[/FONT]
……………………………
(above script is a raw and dangerous script , if not handled with care you might end up losing designer's access to your project also do note that I have managed to disable its back door since you shouldn’t be leaving such an advantage in the hands of end users) .
Also do not click your disable label until final stage of operation.

Step5: Cover all your form errors with proper addressing messages or procedures (Unlike MS Access , programs shouldn’t generate run time errors , and usually a program with a runtime error will crash and exit), now for an easy solution for those who are lazy enough use the general Form Error section and add the following (On Error Resume Next) or maybe add a message box or two stating that an error has occurred and user should be more careful (You lazy you!).

Step6: Create a .mde file (Save your VB scripts from being stolen until someone comes up with a proper tool to decode it :) , you can also skip this stage if you like , or if for a peculiar reason Microsoft Access denied it -Happens with huge projects).

Step7: Create a photo dimensioned 362x290 pixel (Smart developers tried 1x1 pixel image which worked up fine on their platforms but generated errors and crashes on other users' platforms so stick to the standard , oh and darken the area where Microsoft overlays its version details ;)) in BMP format as your splash screen (This will replace Microsoft Access splash screen on running), give it the same name as your database/project (i.e if your database/project is named myproject.mdb etc. name your photo myproject.bmp ) and place it in your project's folder.

Step8: Rename your database / project file extension (The neat trick) into dll (i.e if your database / project is named myproject.mdb etc. name it myproject.dll ), Also move security workgroup file (system.mdw usualy) used while database creation to project's folder and rename its extension into ocx (i.e if your security workgroup file is named myproject.mdw etc. name it myproject.ocx ).

Step9 : Create a Visual Basic 5 or higher project (Lets get down and dirty for a minute) that all to be done is to run a shell command (Batch file like executable) running the following code in Open event of its Startup Form:

Code:
[LEFT][COLOR=black][FONT=Arial]Dim strPathToProgram As String[/FONT][/COLOR]
[FONT=Arial][COLOR=black]strPathToProgram = App.Path & "\MSACCESS.EXE " & App.Path & "\myproject.dll /wrkgrp " & [/COLOR][/FONT][COLOR=#333333][FONT=Arial]Chr(34) & App.path & "\[/FONT][/COLOR][COLOR=black][FONT=Arial]myproject.[/FONT][/COLOR][COLOR=#333333][FONT=Arial]ocx"[/FONT][/COLOR][COLOR=black][FONT=Arial] & Chr(34)[/FONT][/COLOR]
[FONT=Arial][COLOR=black]Shell ("" & strPathToProgram & "")[/COLOR][/FONT]
[COLOR=black][FONT=Arial]End[/FONT][/COLOR][/LEFT]

while making sure Form Parameter "Make Visible in Taskbar" is set to False , Startup Form is invisible and then compile it to the same Project Folder (Adding up an icon file wouldn’t hurt).
(Now attached to this article you will find the source code to such project and a compiled example of its EXE)

Step10 : Keep a copy of file MSACCESS.EXE usually found in Microsoft Office folder in Program Files to your project folder (Saves Junior programmers the hassle of searching registry for Microsoft Office or Microsoft Access Runtime installation folder , also note that this doesn’t work with MS Office 2007 in which case you have to make your executable file created on Step9 lookup MS Office 2007 installation path in registry key "HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Office \ 12.0 \ Access \ InstallRoot : Path" value and add it to your shell command).

Et Voila !

Important Notices:
1 - Now do note the following , your project is still reliant on Microsoft Office Access and while I do know how to make it un-reliant , the technique to it is still illegal as it requires certain tampering to Microsoft Access Runtime files installation and registration technique which Microsoft denies.

2 – It is better to include Microsoft Access Runtime environment 2000 / 2002 and not 2003 or 2007 to your installation as you will be faced upon first start by MS Access confirm security level of application which is a confusing dialogue to end user.


3 – You can always use command line switches to stealthily install Microsoft Access Runtime during installation of your application which I recommend setup factory as an installation packager of choice (A bit techy here).

4 – Finally do note that Command Line switches of Microsoft Access malfunctions if paths include spaces so do try to restrict/deny installation paths that is not compliant with old dos fundamentals of naming (A bit techy here).



Best Regards,
nIGHTmAYOR
 

Attachments

Last edited:
Cool stuff. Hard to read but cool. Thanks for sharing. Hope the exe thing doesn't violate some kind of copy law - :p
 
1) I should note that Access's security is always "on"; it's just made transparent by default. Even a default database will make calls to the default system.mdw to check for permissions. Are you saying that runtime will also provide the system.mdw for users who don't have a full version of Access installed?

2) The download link is for an "Alternative Version" of Access Run Time... Alternative to what? Even more disquieting, is that there is no information about this application...

3) Wouldn't the file still be openable by Access directly, even if the extension is changed?


It basically sounds like we'd be just creating a loader program which then opens the Access without telling the users it's an Access... is it?
 
....
It basically sounds like we'd be just creating a loader program which then opens the Access without telling the users it's an Access... is it?

Yes.

I am curious about the system.mdw thing now tough...
 
please attach a sample of your executable exe file...

to amaze us here... :)
 
Banana please read the section where it says copy the project's mdw to the project folder then rename it to myproject.ocx ;)
 
Thanks for posting your solution. In your important notice #1:

Important Notices:
1 - Now do note the following , your project is still reliant on Microsoft Office Access and while I do know how to make it un-reliant , the technique to it is still illegal as it require certain tampering to Microsoft Access Runtime files installation and registration technique which Microsoft denies.

Are you saying this is illegal and that you know it's illegal and that by you telling us, we know it's illegal? Thus, by doing this we are knowingly breaking the law? (Better than un-knowingly breaking the law, mind you, but not much.)
 
:o mea culpa.

I missed that line.

Now to figure out exactly what "Alternative version: Access Runtime" is alternative to what and how is it different from the one included in developer editions...
 
Whoa... I would not want to test that in a court -espieacilaly(?) a US court .

you are on thin ground ...- has anyone look at the linceses, ...
 
but seriously banana the reason why i posted this article was because i ran a test erlier on this site and thought you were helpfull.

Whoa, whoa, whoa.

Don't misunderstand my questions as criticisms!!! The only thing my questions could possibly mean is that I'm very interested in this and am trying to understand the details about it.

I apologize if I sounded harsh, but rest assured, I'm not being harsh.
 
Whoa... I would not want to test that in a court -espieacilaly(?) a US court .

you are on thin ground ...- has anyone look at the linceses, ...

Actually, the posted solution should be OK because it sounds as that all we'd be doing is putting our splash screen over the Access thus hiding the fact it's Access file. The illegal thing is to make the .exe run without any Access version or runtime engine installed, which he claims to know, but didn't post this at all.

FWIW, Nigelshaw posted something similar.
 
As for the legality issues of techniques mentioned above , they are 100% legal unless I noted other wise.

I wouldn't have even thought of this had you not mentioned it. Are you saying the only part that is not legal is the... Well, I can't tell what you were telling us was illegal: tampering with runtime files? The technique?

Please reiterate for us which part of what you're suggesting is illegal. It is unclear to me, and I don't want to do or promote anything illegal. In fact, I'd suggest that you remove anything in the process that is illegal (if any of it is).

BTW, I never said it but I do appreciate learning this. I just need the one question answered.
 
Banana Answering Your Questions :
1 - You pack the created system.mdw with your project as listed in step 8 if you are concerned , you can always make your executable save the path of myproject.ocx to the registry key of default Microsoft Access work group file and restore the old path on exit ;)

2 - The link is for downloading Microsoft Access Runtime

3 - Yes you can still run it via MS Access if you are aware of the trick but my intention of releasing this trick is opening your eyes to its possibilities , so what about creating a packed installation file (through setup factory, winrar or the like) that would unpack files to remote temp location / delete upon exit , or what about denying file access through registry that only your exe can unlock ? Its your call , I'm just demonstrating.

Now finaly do note that yes we do install and rely on Microsoft Access runtime but think of it as the dotNet frame work upgrade you have to install to run Visual Studio applications only lighter.
 
Last edited:
Now to figure out exactly what "Alternative version: Access Runtime" is alternative to what and how is it different from the one included in developer editions...

Okay, so I did some searching.

From what I can read, it's basically a leaner version of runtime that doesn't depend on IE files and will run essentially identically to the version included in Microsoft Office Developer (MOD).

However, this was intended for those with license to MOD but it seems that Microsoft has done nothing to prevent downloads for anyone who doesn't have MOD installed.

More information on Alternative Version of Access Runtime

A thread from 2005 on another forum asking questions about this file and a MVP's answer.

I would consider it gray area; maybe Microsoft did in fact decided to let it slip but without a word of announcement (I'm pretty sure someone would have had found out and locked it up considering that there were posts asking about it from 2005 and even earlier... but I'm just grasping at straws here.)

To be explicit, everything else (e.g. creating a screenshot and overlaying the Access splash, treating the .mdb as a .dll) should be perfectly fine. It's just that this runtime file may not be intended for everyone (thought Microsoft certainly doesn't do anything to stop this...).

Soooo.... the best thing I can say is caveat emptor!
 
It's just that this runtime file may not be intended for everyone (thought Microsoft certainly doesn't do anything to stop this...).

See this from Microsoft's Access 2007 Help:
Deploy an Access 2007 application

Show All
Hide All
Microsoft Office Access 2007 provides a feature-rich platform for developing database applications. A database application is a computer program that provides both a way to store and manage data and a user interface that follows the logic of business tasks (application logic).
To deploy Office Access 2007 applications that can run without an installation of Access 2007 on a user's computer, you can distribute them along with the Access 2007 Runtime, which is available for free from the Microsoft.com Download Center.

I always thought that this meant anyone could use it to deploy their Access applications, as long as you follow the rules.
 
Erm for 2007 version, yes. Not so for earlier version. The runtime in question is for 2000.

IINM, 2007 runtime cannot run pre-2007 files.... So for a dinosaur (e.g. me), I would have to use the runtime, which usually required that I cough up some dough for Microsoft Office Developer edition.
 
Erm for 2007 version, yes. Not so for earlier version. The runtime in question is for 2000.

IINM, 2007 runtime cannot run pre-2007 files.... So for a dinosaur (e.g. me), I would have to use the runtime, which usually required that I cough up some dough for Microsoft Office Developer edition.

You are correct sir, as usual. I have once again fallen prey to a lack of attention to detail.
 
Well, you know what they say; an missed detail deserves another missed detail. :D (See my first post.... Doh!)

or something like that, I think.
 
I have had PMs of aditional concerns about fully securing a Microsoft Access project source since we are talking about end users and off site installations, Please note the following :

1 - Not even a compiled Visual Basic / c / vc(++) / java etc. executables are source secured (Just google decompilers).

2 - An Access Project that had a custom implimented security model , database window hidden , Shift bypassing disabled , mde compiled , mde compiler junk stripped (Third party packages recquired ex: http://www.everythingaccess.com/mdeprotector.htm), extension manipulated can pause more challenge at reverse engineering than a compiled Visual Basic project.

I guess most of the above techniques were covered during main demonstration however feel free to enquire.

Best regards,
nIGHTmAYOR
 
An Access Project that had a custom implimented security model , database window hidden , Shift bypassing disabled , mde compiled , mde compiler junk stripped (Third party packages recquired ex: http://www.everythingaccess.com/mdeprotector.htm), extension manipulated can pause more challenge at reverse engineering than a compiled Visual Basic project.

Hmm, that actually is an excellent point and something that many would overlook. It also bears to stress that many "security holes" are simply just developers' fault.

One more thing though this is really tangential- in security faqs, it is possible to distribute an secured database using default system.mdw, the trick being that you need a specific .mdw to develop/edit/whatever and that permissions is not available when system.mdw is used. Since the developer's .mdw doesn't have to be distributed, this is actually more secure.
 

Users who are viewing this thread

Back
Top Bottom