Question Installing

[Acme]

Hi All,
My application is close to done so I am looking at install procedures. I like SageKey but they are still testing the MS2013 install wizard. So I plan on trying Inno. I am using MSA 13 and my main question or hurdle is thus: How do I tell the wizard what to do to relink the front end with tables on the back end? I guess its part of the setup.exe script, but I don't know what it would look like. Any tips?

Also, just in general, am I right in concluding that you cannot encrypt a database and have it run without giving users the password, which sort of defeats the purpose of encrypting to begin with, no? I guess password protecting the vba code and saving the front and back ends as accde, then setting the icon to open the front end un runtime is the best alternative then, do you agree?

Lastly, I would like to let some of you check out the app when it is done. It is my first one, and it took a couple months. Once I get a working install, I can make it available to you if you tell me you are interested.

Thanks,

 

[ions]

I use SageKey and it's pretty good. It's not perfect but it's good. Their customer support is excellent.

You have to write your own VBA to relink the Backend when you open the application. I just finished doing that myself.

There are many examples on the internet but if you have Connections to multiple backends or sources (excel) files you may need to really write it on your own and understand every line of code.

 

[ions]

As to your second question. I also disable the Shift Key using VBA so they can't modify the queries and tables which are still left exposed in a .mde or .accde. They can still import the queries and tables into another Access container if it's a .mde and Shift disabled. There is nothing you can do about this.

I also use FMS Code Tools to obfuscate my VBA because there are people who can reverse engineer .mde but it is known to be very difficult. I do it for that extra added protection.

 

[Pat Hartman]

As ions already mentioned, you need your own relink form. The install wizard cannot do this for you since it requires opening the database and since you won't know the BE location ahead of time, the form will have to interact with the user to locate it. There are many examples floating around. If you have multiple BE's, you need to relink them one at a time. In general, code in your opening form attempts to open a table and if it gets an error, opens the relink form. The relink form does the relinking and then opens the main form. You should also have a button somewhere or an item on the switchboard to call up the relinking form should the client want to move the BE. Of course in house applications can be delivered pre-linked and you would not want to allow the user to relink by himself but you still need the feature for yourself so you may want to include the form anyway but make it password controlled.

It is best to create an .accde and rename it to .accdr for distribution. This isn't foolproof since anyone can simply rename it back but it does force a full version of Access to pretend to be the runtime engine when it opens the file. There is no secure way to lock down your application. There are things you can do but almost all are well known and can be circumvented by a knowledgeable hacker. So the best you can hope for is to prevent accidental modifications by fat-fingered users.

I've used the SageKey installer and it is pretty straightforward. It sets the trusted locations for you and it also prevents the "Installing......." issue that occurs when multiple versions of Access are installed and they fight over the registry. It also creates directories and can install ancillary files for you.

 

[gemma-the-husky]

personally, i don't worry about tables being exposed. it's their data, and it makes sense for them to be able to see it. in most systems you can get an odbc link that exposes the data tables, and data can be interrogated by many external programmes.

i am not too bothered about queries either. it can be useful in some cases. you could always put the sql for all the queries in a table, and get the sql from there instead of having stored queries. that might make it harder.

passwording a *de database seems pointless. there is no code avaialble.

however, have a look at everythingaccess.com code protector to see what can be recovered from a *de. pretty much the lot!

becuase of this, i store no (or very very few) public constants. All I have is vars that are all initiallised at runtime, and many of those with some simple encryption/decryption so they are not plain text anywhere in the dbs.

 

[ions]

Gemma,

When I obfuscate my code with FMS Code tools it does the following. You may find it useful.

Renames all Variables including public constants to cryptic names such as V123
Removes all comments,
Removes all White space.
Removes all Indents.
Removes Line Continuation Chars