How to distribute an Access app? (1 Viewer)

[Libre]

Hello and thanks in advance for any input. I'm about to deploy an Access db I've been working on for months.
I'm an independent developer and I've been as I say developing this huge application for months. There will be a front end and a back end. I'm almost ready to go with it - at least the first beta version - but my question is, how would you secure it?
What I found is there's Runtime Mode which I looked at and it does prevent any design mode views or code windows. I don't really like the red bar at the top but I can live with it. Aesthetics are very important in my applications. The other method is create an executable accde file. Here, however, I find I'm able to get the navigation pane, see the tables and queries, go into design mode. That surprised me.
What do you do? Previously, I've worked in companies and always had the original accdb - distribution wasn't a big issue. I've used the accde but again - the tables and queries etc are visible. The toolbar is there. Here, as I said, I'm selling a product. I don't want the user to ever see a code window or be in design mode.

 

[Edgar_]

I don't want the user to ever see a code window or be in design mode.

Test your accde file and make sure you have good error handling

how would you secure it?

I would worry more about the previous point, add some login form to serve as the only security before making things more complicated, once you see the product is viable and will grant you sales, migrate it to a secure platform if security is vital

I find I'm able to get the navigation pane, see the tables and queries, go into design mode.

Hide the app, show only forms

Users won't want to deal with hard setups, so I suggest you automate the installation and updates.

 

[Trevor G]

You can always hide the tables, queries etc in the navigation pane and you can hide the navigation pane also restrict allowing any keyboard method to show the navigation pane as well as using right mouse button. There are additional options to restrict anyone wanting to share (possible share in a company/organisation) without a deployment exe command which can include how many users can access the DB as well as administrative options. And notifying you if they looked to add additional users etc.

I think you've done a really good job on the creation of its potential and distribution to your target audience.

I'm sure others can add to my reply.

 

[Libre]

You can always hide the tables, queries etc in the navigation pane and you can hide the navigation pane also restrict allowing any keyboard method to show the navigation pane as well as using right mouse button. There are additional options to restrict anyone wanting to share (possible share in a company/organisation) without a deployment exe command which can include how many users can access the DB as well as administrative options. And notifying you if they looked to add additional users etc.

I think you've done a really good job on the creation of its potential and distribution to your target audience.

I'm sure others can add to my reply.

Thank you and above you for the comments.
Yes - I've turned off Navigation and Toolbar. Once I saved as accde the toolbar is gone but the nav pane pops up with good ole F11 - which I rely on heavily usually. But even though the nav pane comes up, there's no design mode which is a BIG relief.
HOWEVER the modules are there and dbl clicking brings up my code.
Is there a way that I can hide those modules? I do a lot of coding there.
Oh of course - select them and choose "hidden" I guess. Duh.

 

[Gasman]

If I make an accde and try and go into the VBE window, I can see the modules, but cannot view/change them?

 

[isladogs]

There are several additional things you can do to make your ACCDE file more secure.
Have a look at my article on improving Access security for several suggestions to choose from:

Improve Access Security 2

This article explains how to apply various security measures to make your databases as secure as possible. An example app is used to illustrate the possible methods available

www.isladogs.co.uk

I would also recommend you distribute your FE / BE using a professional installer app. This will make the installation process very straightforward for end users and also allow you to do things like ensure the install location is trusted automatically.

 

[CJ_London]

users can still see hidden objects simply by going into file>options>current database>navigation options

changing the file extension to .accdr will put the app into 'runtime' mode (no nav window, limited ribbon) but this will mean shortcut menus are also disabled. May not matter in your app, but if you expect users to rely on them, you will need to write your own - and of course there is nothing to stop users changing the file extension back again.

With a .,accde, users cannot go to design view for forms/reports/modules, but they can still do so for tables and queries. I assume your tables are in a password protected BE file. You can move your queries there as well with consideration for how you would pass parameters. Users can still view the design but not make changes.

Better still, don't have linked tables (or queries), instead when the app opens, the first lines of code would be something like.

if BE is nothing set BE = opendatabase "BEName", "Password"

where BE is a public object in a standard module
Publie BE as dao.database

to populate a form, instead of specifying a controlsource you would have code in the load event

set recordset=BE.somequery

 

[Libre]

There are several additional things you can do to make your ACCDE file more secure.
Have a look at my article on improving Access security for several suggestions to choose from:

Improve Access Security 2

This article explains how to apply various security measures to make your databases as secure as possible. An example app is used to illustrate the possible methods available

www.isladogs.co.uk

I would also recommend you distribute your FE / BE using a professional installer app. This will make the installation process very straightforward for end users and also allow you to do things like ensure the install location is trusted automatically.

OK - reading the link. There's a lot of useful stuff here. Really what I need to know. I'm willing to invest the time to digest it.
I would like to explain, although this isn't my first install even remote install. My brother has one of my apps - he uses to run his diamond biz. I regularly update his FE and not so regularly but still often enough have to update his BE. I - or we - have the procedure down pat. But I'm not worried about an accde in his case. He is my brother. He's been running my application for like 22 years, with millions in sales and thousands of customers - by the way. He depends on it. I look at it now, and it seems crude - I've learned so much since. This new app is KILLER.
The scoop: I've been, as I said, developing it on my own for months. I had the second meeting - zoom demo - with the owners and they said YES by golly! I had no assurance they would, and they gave me no commitment - until today. I had faith in it. It will transform their business - like my bro's app transformed his. But now, they said yes - they met my price and I didn't budge - and they were really amazed - and for the second time - and I knew they had to say yes and they did. Now, however, comes the distribution part where I AM concerned about unintentional or intentional access and the consequences. Now, I do have a log-in - one of the first parts I made. And the "designer" (me) or the "superadmin" can assign roles and rights to view/change/delete etc. Yes I have that - but I didn't think to put it on the BE as well (I just split it today) - as someone said I should and yeah - hide them and put the log-in with only me(?) able to open? See, in a way I'm not trying to stop them from ripping me off as much as trying to keep the BE safe and secure. Yah we all know this.
OK I have to read the rest of your linked page.

 

[theDBguy]

When you read Colin's article, one common theme you should pick up is that you can never make an Access application completely secured. So, you will have to decide what's really important for you to protect. If it's the code, you can use ACCDE files and maybe use VB Watchdog to add another layer of security to prevent others from easily reverse engineering your code. If it's data, then an Access BE may not be what you want to use. If it's the table structure, then again, an Access BE may not suit your need there. Form designs and report designs are pretty much safe with ACCDE. However, queries are wide open, and users will be able to create their own as well. Just my 2 cents...

 

[Libre]

As they say "locks are for honest men". So all I want to do is cover my original work the best I can. And I've been working on the log-in for the BE and already decided hell, I'm giving one level down from me ("Designer") to the "SuperAdmin" level which would allow the owners access to the BE. I mean, you're right - I can't go nuts trying to protect it because first of all they have a business to run and if they were capable of "reverse engineering" my program, they wouldn't have reached out to me in the first place to develop it (I didn't mention) but I was recommended by a former coworker who now works for this new company. So I'm going with accde - any upgrades of course will require the accdb at my end anyway.

 

[theDBguy]

As they say "locks are for honest men". So all I want to do is cover my original work the best I can. And I've been working on the log-in for the BE and already decided hell, I'm giving one level down from me ("Designer") to the "SuperAdmin" level which would allow the owners access to the BE. I mean, you're right - I can't go nuts trying to protect it because first of all they have a business to run and if they were capable of "reverse engineering" my program, they wouldn't have reached out to me in the first place to develop it (I didn't mention) but I was recommended by a former coworker who now works for this new company. So I'm going with accde - any upgrades of course will require the accdb at my end anyway.

I would also recommend using ACCDE and rename them to ACCDR before distribution, for additional measure. Good luck!

 

[Pat Hartman]

Access applications can never be truly secured. Colin has lots of good information on how to impede the users. But, don't ever think the app is actually secure. Therefore, you should probably get yourself a lawyer to write a good contract spelling out that the customer is licensing the product and does not own it and is not allowed to do anything to attempt to reveal the inner workings. Obviously, you can't know for sure but most companies don't want to get sued over something like this so as long as the app isn't useful to individuals, there will be little incentive to steal your intellectual property. Make it clear that they own their data and provide exports that allow them to get their data back should they decide to change platforms in the future.

 

[Libre]

Another question about deployment: do you put an error handler into EACH AND EVERY procedure and button click? Everything regardless?
Here's the one I use - look ok?

Private Sub cmdClose_Click()
On Error GoTo Err_cmdClose
'code
'code
'code
Exit_cmdClose:
Exit Sub
Err_cmdClose:
MsgBox Err.Description
Resume Exit_cmdClose
End Sub

 

[Josef P.]

Error handling should be mandatory in the procedure that is called first. In the other procedures, error handling can be useful in order to obtain good information about the cause of the error.

But please do not simply call a MsgBox in the error handling in every procedure, as this will result in the error not being passed upwards.

Northwind 2.2 contains an example of error handling.
Youtube: AP: Enhanced Global Error Handlers in Northwind 2.2 With Tom van Stiphout and Kim Young

 

[CJ_London]

I don’t- only where there is a risk an unhandled error could occur which depends on your code.

Issue is, just bi passing the error could just pass the issue down the line - perhaps resulting in malformed data or user making a wrong decision based on what what happens next.

@Josef P. gives a good reply

 

[gemma-the-husky]

Error handling is not as simple as merely making sure that there are no unhandled errors.

Some errors might indicate a dangerous/catastrophic problem that can't be simply recovered from.

 

[Libre]

Error handling is not as simple as merely making sure that there are no unhandled errors.

Some errors might indicate a dangerous/catastrophic problem that can't be simply recovered from.

I'm basically trying to keep the debug option from coming up. No user wants to see that. I don't know if there's any way to guarantee no errors are going to occur.

 

[Libre]

Error handling should be mandatory in the procedure that is called first. In the other procedures, error handling can be useful in order to obtain good information about the cause of the error.

But please do not simply call a MsgBox in the error handling in every procedure, as this will result in the error not being passed upwards.

Northwind 2.2 contains an example of error handling.
Youtube: AP: Enhanced Global Error Handlers in Northwind 2.2 With Tom van Stiphout and Kim Young

I've watched the link- or much of it carefully. I've vastly improved my error handling - now writing to an external error log for example. Also having a global handler rather than millions of individual ones. I'm super glad I looked into this before pasting my former code into every procedure!

 

[gemma-the-husky]

I'm basically trying to keep the debug option from coming up. No user wants to see that. I don't know if there's any way to guarantee no errors are going to occur.

Yes, you don't want unhandled errors but you might need to react differently depending on the actual error, and that is much more difficult to handle, and identify report and resolve the true cause.

 

[Libre]

Yes, you don't want unhandled errors but you might need to react differently depending on the actual error, and that is much more difficult to handle, and identify report and resolve the true cause.

Based on the almost infinite nature of what COULD happen, it doesn't seem reasonable to handle every possible eventuality.
What I've got now, is an external error log, displaying the timestamp, the error description, the error number, and the line it occurred on (need line numbers for that one - which I am adding with MZ Tools). Then I have an exit from the handler so the code doesn't just get stuck in there. I don't know what else I can do. The program will be "battle tested" for at least a month I'm hoping. I'm going forward without knowing what's around the bend. I will say, based on the answers I got in this thread, my error handling is FAR FAR superior to what it was.