Access 2010 to 2016 upgrade questions

%3CLINGO-SUB%20id%3D%22lingo-sub-1452599%22%20slang%3D%22en-US%22%3EAccess%202010%20to%202016%20upgrade%20questions%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1452599%22%20slang%3D%22en-US%22%3E%3CP%3EHello%20All%3A%3CBR%20%2F%3E%3CBR%20%2F%3EI%20have%20a%20major%20client%20prepping%20for%20an%20Access%202010%20to%202016%20upgrade%20and%20I've%20a%20few%20questions.%20This%20particular%20client%20has%20inventory%201000s%20of%20Access%20files%20on%20their%20system.%20Some%20of%20the%20files%20are%20quite%20aged%20(and%20have%20not%20been%20opened%20in%20years).%20The%20files%20most%20likely%20only%20exist%20on%20the%20system%20because%20of%20data%20retention%20requirements.%26nbsp%3B%3CBR%20%2F%3E%3CBR%20%2F%3EBut%2C%20that%20reality%20does%20present%20some%20issues%20and%20their%20IT%20folks%20are%20trying%20to%20work%20through%20some%20issues.%20One%20of%20concerns%20they%20have%20is%20should%20they%20require%20all%20employees%20%22convert%22%202010%20files%20to%202016%20files%20(even%20though%20they%20are%20both%20.accdb%20file%20format).%3CBR%20%2F%3E%3CBR%20%2F%3EThe%20security%20folks%20are%20concerned%20that%20if%20every%20single%202010%20file%20is%20not%20run%20through%20a%20%3CSTRONG%3ESaveAs-%26gt%3BAccess%20Database%3C%2FSTRONG%3E%20process%20that%20somehow%20the%202010%20file%20will%20present%20security%20risks.%20I've%20explained%20to%20them%20that%20both%202010%20and%202016%20files%20are%20.accdb.%20But%2C%20they%20need%20more%20information%20to%20be%20assured%20the%20unconverted%202010%20files%20will%20not%20present%20security%20risks.%20(Please%20know%2C%20I%20do%20understand%20we%20are%20going%20to%20run%20into%20all%20kinds%20of%20fun%20things%20with%20features%20that%20are%20no%20longer%20supported%20in%202016.%20We%20have%20been%20preparing%20for%20this.%20But%2C%20this%20question%20is%20specifically%20related%20to%20security%20issues%20of%20not%20running%20unused%202010%20databases%20through%20a%20%3CSTRONG%3ESave%20As-%26gt%3BAccess%20Database%3C%2FSTRONG%3E%20process.)%3CBR%20%2F%3E%3CBR%20%2F%3EAny%20links%20documenting%20security%20considerations%20when%20moving%20from%202010%20to%202016%20will%20be%20appreciated.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThanks%20in%20Advance%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-1452599%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EAccess%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1452665%22%20slang%3D%22en-US%22%3ERe%3A%20Access%202010%20to%202016%20upgrade%20questions%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1452665%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F694686%22%20target%3D%22_blank%22%3E%40AccessDev%3C%2FA%3E%26nbsp%3BI%20can't%20think%20of%20any%20security%20related%20issues%20you're%20likely%20to%20encounter%2C%20but%20that's%20something%20only%20you%20can%20determine%20by%20examining%20each%20accdb%20for%20any%20security%20features%20implemented.%20It's%20sort%20of%20hard%20to%20predict%20since%20we%20don't%20really%20know%20what%2C%20if%20anything%20was%20implemented.%20Inherently%2C%20though%2C%20there%20should%20be%20no%20lessening%20of%20security.%20But%20then%2C%20Access%20is%20not%20known%20to%20be%20a%20highly%20secure%20application%20to%20begin%20with.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EYou%20are%20likely%20to%20find%20at%20least%20a%20few%20differences%20that%20may%20require%20updates%2C%20but%20again%2C%20each%20accdb%20is%20unique%20and%20will%20need%20to%20be%20checked.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20can%20state%20that%20more%20recent%20versions%20of%20Access%20have%20been%20less%20tolerant%20of%20ambiguity%20in%20VBA%2C%20so%20you%20may%20find%20yourself%20revisiting%20some%20of%20the%20code%20to%20provide%20fully%20qualified%20references.%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAnd%2C%20of%20course%2C%26nbsp%3B%20if%20any%20of%20those%20accdbs%20implemented%20features%20deprecated%20in%20later%20versions%2C%20they'll%20need%20to%20be%20addressed.%26nbsp%3B%3CBR%20%2F%3E%3CBR%20%2F%3EOn%20the%20whole%2C%20it%20should%20go%20pretty%20well%2C%20though.%3C%2FP%3E%3C%2FLINGO-BODY%3E
Occasional Visitor

Hello All:

I have a major client prepping for an Access 2010 to 2016 upgrade and I've a few questions. This particular client has inventory 1000s of Access files on their system. Some of the files are quite aged (and have not been opened in years). The files most likely only exist on the system because of data retention requirements. 

But, that reality does present some issues and their IT folks are trying to work through some issues. One of concerns they have is should they require all employees "convert" 2010 files to 2016 files (even though they are both .accdb file format).

The security folks are concerned that if every single 2010 file is not run through a SaveAs->Access Database process that somehow the 2010 file will present security risks. I've explained to them that both 2010 and 2016 files are .accdb. But, they need more information to be assured the unconverted 2010 files will not present security risks. (Please know, I do understand we are going to run into all kinds of fun things with features that are no longer supported in 2016. We have been preparing for this. But, this question is specifically related to security issues of not running unused 2010 databases through a Save As->Access Database process.)

Any links documenting security considerations when moving from 2010 to 2016 will be appreciated.

 

Thanks in Advance

1 Reply

@AccessDev I can't think of any security related issues you're likely to encounter, but that's something only you can determine by examining each accdb for any security features implemented. It's sort of hard to predict since we don't really know what, if anything was implemented. Inherently, though, there should be no lessening of security. But then, Access is not known to be a highly secure application to begin with.

 

You are likely to find at least a few differences that may require updates, but again, each accdb is unique and will need to be checked.

 

I can state that more recent versions of Access have been less tolerant of ambiguity in VBA, so you may find yourself revisiting some of the code to provide fully qualified references. 

 

And, of course,  if any of those accdbs implemented features deprecated in later versions, they'll need to be addressed. 

On the whole, it should go pretty well, though.