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

Was this article helpfull to you ?


  • Total voters
    17
I was following the details in the original message up until he recommended using a vb application to use shell to launch the Access application. I've tried & tried to get shell to work with an Access 2007 database that's been encrypted but I've had absolutely no luck so I ended up using the OpenDatabase method on a dao.DBEngine object. The problem I'm having is that I've added some code to one of my Access forms' on error event to let the user know which field has a duplicate value. If I run the database directly, the error event is raised and I trap it properly. However, if I run the database through my vb application, the event isn't raised (or at least I don't get to the on error event for the form since I've added a msgbox that's supposed to be displayed first thing and its never shown)

Any thoughts/recommendations?

Thanks
Lution
 
I voted this article as confusing because the whole description of the problem is completely in error. Michael Kaplan always used to post in reply to these questions that the workset for a VB6 database application was, in fact, as big as or larger than the workset for an Access runtime application. That is, it may seem like you're putting in a lot of stuff you don't need, but the comparable development platforms that *can* compile an EXE are just as large (with just as many outside dependencies) as an Access runtime app. I don't have his expertise, nor can I find one of his posts, but to really argue that there's something wrong with runtime approach you'd have to show that it was deficient in comparison to the alternatives. That is not possible, so the basic premise fails.
 
I was following the details in the original message up until he recommended using a vb application to use shell to launch the Access application. I've tried & tried to get shell to work with an Access 2007 database that's been encrypted but I've had absolutely no luck so I ended up using the OpenDatabase method on a dao.DBEngine object.

first of all i did hint that its quite different in ms access 2007 :

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).
and thus your other problem lays in that you tried an entirely different approach which lead to this error you are having.

while describing why such error occured will end out as a quite confusing paragraph here is bottom line :
1 - running your database through MSACCESS.EXE is essential and the key to avoiding all peculiar errors you might encounter.
2 - here is a fast solution you can use to experiment with your issue :
in Cmd prompt type the following (judging that your windows and office setup is in their defaults) :
C:\Progra~1\Micros~1\Office12\MSACCESS.EXE C:\MyApp\MYPROJ~1.DLL /wrkgrp "C:\MyApp\MYPROJ~1.OCX"


of course you have to revise upper path A to Z through Dir /X command.

now hopefully your application will work properly then and such path can be implimented successfully within EXE , but the problem you will be facing is how to aquire such a path dynamicaly each time someone runs your application. and thus you will be needing extra knowledge with registry and Shell extensions such as %WINDIR% and %PROGRAMFILES% which is easy but then is yours to research.
 
dfnton
please waste a couple of minutes to read a post before critisizing because OBVIOUSLY you haven't even read a single line of which .. apparently your judgment was based on your view of topic!

and your supposed to be an AWF Vip ...
 
nIGHTmAYOR, I found your article to be very enlightening and I will definitely be playing with it when I get time.

Thank you for sharing your thoughts and solutions and for participating as a Solution Provider within this Forum. Keep up the good work.

.
 
dfnton
please waste a couple of minutes to read a post before critisizing because OBVIOUSLY you haven't even read a single line of which .. apparently your judgment was based on your view of topic!

and your supposed to be an AWF Vip ...

I read the post. It's still confusing and badly worded. I would take out the whole introductory quick introduction, as it is misleading and wrong in what it implies, despite the fact that what follows is basically correct.
 
I didn't have any trouble getting the location of MSACCESS.exe from the registry, there were plenty of examples on the web to use. To be clear, I'm not using workgroup security on the database. I'm opening the database in exclusive mode and using the Encrypt database option that is available in 2007 (I haven't used previous versions so I'm not sure if this option is new or not). Even running from a shell window (yes I added the folder where MSACCESS.exe is to my PATH environment variable) I was unable to successfully open the database without it asking me for the password I used to encrypt the database.

Even though I've split the front and back-end, I still want to protect my front-end as much as possible to keep users from mucking up the system and to force competitors to at least work a little bit to figure out what I've done.

-Lution
 
1 - ok i'm not realy sure what phase you are in and what troubles came with but all i saw were covered issues , securing back end was tackled during illustration (disabling bypassing and compiling your project/stripping out the hash).

2 - you are mixing encryption with password protection
encryption is a mean to cypher raw data so they are not accessed through text editors to that the only mean to access them would be through your application.
on the other hand password protecting your database is a very basic and volenerable mean to protect logins to your project and thus why i recommended scripting your own security forms and disabling access to design view.

3 - please on any correspondance state :
--wether the issue you had erlier of vb script malfunctioning was solved by using command line switches.
--have you applied the disabling shift bypass script and if you could over-ride it.
--have u compiled your project.
--did you script your login forms.

finaly my posted methode does not cover security holes generated by users nore ultimate means to defy crackers , it just assumes that user is aware of what he's doing and he has all security matters thought of and i just walk him through the process of finalizing his project.
 
Ok as per request i managed to attach a working model of the EXE project discussed above to add to your work along with its source code in visual basic 6 format . Please follow the instructions above carefully before requesting assistance .
Best regards :)
nIGHTmAYOR
 
I've found this software utility named MDE Compiler .. and seems that it's what we've been searching for .. find it here MDECOMPILER.COM

Hope it is useful for all of us :) , I've just tested it and works nice..

Mikotron
 
this site does the very exact trick that is the topic of this post (5 years old now) and yet charge you heaps of money for it :)
 
I've found this software utility named MDE Compiler .. and seems that it's what we've been searching for .. find it here MDECOMPILER.COM

Hope it is useful for all of us :) , I've just tested it and works nice..

It still requires Access or Access Runtime so I don't see the point.

Moreover, any use of the runtime in a configuration that supressess the "Powered by Access" message in the status bar is in breach of the Runtime licence.

What is the obsession with pretending an application isn't run in Access? Kind of pathetic denialism really.
 

Users who are viewing this thread

Back
Top Bottom