Updating database to new format?

[Nitman]

Dear,


Our charity organisation have an old database made in Access 2003 with usernames and password. The database consists of a backend and a frontend. I have read in an article that the function with users logging into the database and given different permissions will be gone if I update. Is this true? Or what is it that have been removed? I think the change was to done after Access 2007.

Thanks,
Nitman

[ranman256]

There's no need to upgrade. You wont gain anything but loose your logins.

[jwhite]

Workgroup Security is deprecated in 2007 and 2010, and 2013+ it is no longer supported. I agree with ranman256 - no need to upgrade the Access component of MS-Access. If you will be installing a new version of MS-Office, don't install the MS-Access component of the new version, and you should be just fine.

[NTC]

I will disagree - though not for any of the technical aspects. The advice given is technically correct. I maintain a 10 year limit and believe all organizations should upgrade as there becomes more & more hassles in allowing yourself to be out-of-date; an example of exactly what you are experiencing now.

You should create a brand new, empty database in your more current version - and then import the objects of this old database. Depending on the custom code one must then tweak; if everything is generic there may be little to no tweaking needed. If you continue to need user log-in & edit versus enter controls - then that must be built.

[Micron]

On the subject of upgrades, I've read in this forum more than once that upgrading to 2016 right now is not advised - too many program bugs. So if the OP's new version is 2016, which is not stated, then what? I can ask because I'm stuck in version 2007 for now.

[CJ_London]

old database made in Access 2003 with usernames and password

the above is assuming you are using workgroup security. Your post doesn't really say whether you are or not. If you are not then there will not be an issue in upgrading in this regard. I'm with NTC on upgrading.

[NTC]

2016 definitely did have some noticeable bugs. But my view now is that it is shaken out and I would not hesitate to use it. The only reason I have not upgraded at least 1 machine to it is only because I haven't been confronted with the need. I keep each version on a separate machine in order to develop in the version that the client is using - and so will be adding a 2016 - just haven't gotten around to it. One can develop in an older version i.e. if starting from scratch one can develop in 2010 for a 2016 user - but if the client comes to me with a database already built in 2016 there can be features/libraries not understood by an older version so I would develop using 2016 but that just hasn't happened yet.

2010 and beyond has some nice improvements for the developer with intellisense offering form object names and such so I am happy to phase out 2007. 2013 and beyond has better ability to place the back end tables at a 365 account and that is pretty cool.

[Nitman]

Thanks for your comments.

Yes, it is Access 2016 I am thinking of upgrading to. Yes, it is workgroup security. When we upgraded all OS to Win10 last year we ran into problems using the old Access version. We have about 30 PCs and most of them was able to make database work in Access RT 2016. A few machines have the the full version of 2016.

As our database have sensitive data I think we still need to maintain the login part of the database somehow. Are there alternatives for that? Or maybe we can maintain the old database but write a new frontend application that connects to the database?

My reason for asking is that we have been thinking of possible improvements that can be done. Most importantly making the update of the database across the centers easier by moving the backend to a cloud service and possibly all centers work towards that.

[Micron]

As long as you're OK in the knowledge that the best security one can apply to Access will never be as good as other applications but you would be content with thwarting the user group you have, then there are things you can do to protect data and its integrity. Things that I have done or would consider, some of which can be overcome by users with too much curiosity and more than a basic level of knowledge:
- split the db (not for security reasons, but it helps)
- use a password when linking the back end tables (yes, I know this can be discovered) - not the same as a password to open the be file.
- when ready to be released, the front ends become accde files so that code cannot be viewed
- bypass key disabled (leave yourself an 'Easter egg' that you can use to enable it)
- navigation options are limited, nav pane objects hidden.
- startup code
enforces nav options and/or hidden objects
checks that the fe is not an unauthorized copy
checks that it is the current version and either facilitates downloads or simply requires it
checks that the user is authorized to enter (use *network login id and if useful, the computer being used to log in) against a table of users
gets the user level from same table; assigns user properties to custom dbUser object such as FName, LName, pc ID, EmplNo, LoginID, EmailAddress, UsrLvl and anything else needed. Each operation can be governed by checking dbUser.Lvl to allow or deny that operation such as opening a form.

* many use the Environ function for this; I have seen one instance where that stopped working after years of use due to some network change but don't recall what that was. I always have used fosUserName(), which is readily available for copying.
Hope some of that helps.