Deployment and © protection Help.

[w8ingforyou]

Hey guys.

I Have a Big Question Which i am Trying to Find answer but Google didn't Help.

Problem : i have a program, Tool (accdb) prepared and i want to protect my Property, i deploy using SSE Deploying solution,

Desired solution: how do i deploy the tool in such a way that it protects the code completely and the UI, (FE) is safeguarded from Property Threats, i have seen a few other developers doing it in demo dbs that they deploy, (Attached.)

Ps. I have also seen a Tool called Quick License Manager

Very Confused on what would work and how to do it, kindly advise.

Very Frustrated Jr.Dev
Regards

Saketh Sharath

 

[isladogs]

The database you provided is commercial software available from here:
http://https://www.microsoftaccessexpert.com/default.aspx

I don't know anything about the company or whether they are reputable or whether this database is any good.

Its a DEMO of error handling code and my first impression is that it doesn't look at all professional

If you were wondering why nobody had answered this before, this may be because this file is a 64-bit ACCDE file so you've significantly reduced the potential audience

As its an ACCDE file you can't view the program code.
Apparently you get the code (ACCDB file) if you buy it. Price $100-$200. Not cheap!

There are many features that need to be considered if you want to make a db secure.
Making an ACCDE file is just one of the ways of protecting your db as it means the code cannot be viewed or edited.

Its easy enough to convert ACCDB to ACCDE files
In Access 2016 its File... Save As ... Make ACCDE
It may be slightly different in other versions

NOTE: make sure you keep the original ACCDB file or you will be 'locked out' from making any changes in the future

Unlike ACCDB files, ACCDE come in 32-bit & 64-bit versions:
To make 32-bit ACCDE you must create it in 32-bit Access
Similarly 64-bit ACCDE MUST be made in 64-bit Access
Each will only work if users have THAT version of Access and hardly anyone uses 64-bit Access.

I do have a copy for business purposes - mainly so I can distribute 64-bit ACCDE files to the few clients who use it.
Normally I stick to 32-bit Access.

You might find this post useful Converting 32 bit to 64 bit???

I have also seen a Tool called Quick License Manager

Sorry - never heard of it

My advice would be to thoroughly research using Google & sites such as this to find out what you need to do to set up security features in Access.
Don't purchase anything unless you are confident its worth the money

 

[ashleedawg]

No problem, just send me all your code and I'll take a look... (Kidding!)


First, you'll proably want to "add trust" to the database by adding a digital signature to your VBA project (see this and this) otherwise, users of a protected version could get a scary warning every time they open the db.
https://support.office.com/en-us/ar...ignature-2f6b7d18-a9d3-400d-9f63-9029551e61a1

To add trust, you'll need to obtain a Digital Signature if you don't already have. You can get one from sites like globalsign, or there are free options, especially if the application is only going to be distributed within your organization.

As ridders shared, you can save an Access database as an ACCDE executable-only file (formerly known as MDE) to enhance security and improve performance. This prevents users from modifying the database design, while still providing the functionality required by most users. (Backup first!) After the database is "trusted", convert a copy to ACCDE (File -> Save As -> ACCDE) See this and this.

The ACCDE file can't run on it's own but Microsoft Access Runtime is a free-to-distribute application that allows others to open you database without purchasing an Access license. You can find the 2016 version here.

Finally you can create a professional-looking executable Installation Package with a free application like Inno. You'll need to select the custom options to have the ACCDE open with the Access Runtime EXE, or I believe there's an option to associate all ACCDE files with Access Runtime on the client computer. Alternatively, you can customize the installation script (before compiling it to EXE) to ask the user whether they want to use MS Runtime, or their existing installation of Access - if their version is correct for your DB.

As for protecting your intellectual property, here is an interesting post from stackexchange. Basically, copyright is implicit (especially if you add a clearly visible ©2017 statement), but your licensing terms need to be clearly stated as accessible (the custom Inno intallation package will help with that). Remember that there is no enforceable international/universal copyright law; however here are government links to Copyright Acts in Canada, USA & UK.




And I suppose I should disclaim: I'm not a lawyer so don't take my word on this or any legal topics.. you're responsible for your own due diligence!

 

[w8ingforyou]

Thank you both for a very resourceful Responses.,

 

[alijoseph]

Informative thread.

 

[gemma-the-husky]

what you probably also need is

a) a method of preventing your app being freely copied, irrespective of whether the code is hidden, thereby preventing an unlicenced copy running
b) maybe a method of adding an expiry date to any licence you provide.

not sure if the licence managers you are looking at include such features.

c) a method of supporting your app/users in the event of any run-time problems.

 

[Pat Hartman]

Access isn't particularly secure so I would not use it for something "shrink wrapped" that gets wide distribution. However I have a couple of apps that are sold but they are not the type of app that people are inclined to steal so Access is less of a problem.

Follow the directions you'll find regarding the bypass shift key. Compile to .accde and rename to .accdr. Hide all the objects so that if someone renames back to .accde, they still won't see anything. Every hurdle you can put in place adds one more brick to the wall. You can even rename it to some other extension that you make up yourself - myapp.axyx. You'll have to distribute a shortcut that includes the path to the Access runtime engine to run it but no one will be able to open the file by double-clicking on the file in the file manager. Access doesn't care what the extension is. It is Windows that uses the extension to determine what application to use to open a file when you double-click on it. If you don't want to open via double-click, renaming the extension is a fairly high bar for the merely curious.

Inside the app, I developed a "token" that is generated specifically for a client. It includes an expiration date and flags that activate several extra cost features. I can't share this for obvious reasons but I can give you some ideas you can use if you need them.

One thing I would like to add but don't have the technical skills to implement is to have the app "phone home" and have the token validated by a web page every time the app opens. This would ensure that only the authorized user actually uses the app and it would allow me to control seat licenses. Currently, we offer only a site license so the user can install it as many times as he wants. Again, it is a pretty specialized app and so is not of general interest so this isn't a particular worry.

So far, these methods have worked for me without a problem for over 10 years.