Possible Version Conflict Problem.

[Extra_Cover]

Long shot. Anyone else encountered this problem.

Access 2010 is installed on a server but Access 2013 installed on PCs on the network. My client recently updated the PCs to 2013. There are several apps that update via Task Scheduler but one often falls over, this is used by users on the network.

Could there be a conflict? Also the VBA object library on the server is 14.0 and on the user PCs 15.0. VBA is used in the update.

 

[theDBguy]

Hi. If the server is only used for data, then the database engine should be the same between 2010 and 2013. VBA should not be a factor.

 

[The_Doc_Man]

The first question is whether the database is split (front-end/FE and back-end/BE) or unified (one DB file for all parts).

Second, if several Task Scheduler apps work but one doesn't, the fault is more likely to be in the circumstances of the failing app. Remember that Task Scheduler normally runs what it runs as user SYSTEM, which (believe it or not) might not have the right kind of permissions. I know, you'd think that SYSTEM had access to everything - but if you have an activist IT shop, that won't be true. The ADMIN account will - but SYSTEM might be pared down a bit due to some security bulletins that came out a few years ago about Windows Task Scheduler's ability to do serious damage when running high-powered accounts.

Third, if ANY user has ever DIRECTLY opened the shared file from a 2013 Access workstation, that would have upgraded its references. The 2010 version would not have the right versions of those files and would therefore fall down. Note that if this were a split FE/BE case, opening a linked BE file from a 2013 FE file DOES NOT update references because that is an INDIRECT opening method.

 

[Extra_Cover]

The first question is whether the database is split (front-end/FE and back-end/BE) or unified (one DB file for all parts).

Second, if several Task Scheduler apps work but one doesn't, the fault is more likely to be in the circumstances of the failing app. Remember that Task Scheduler normally runs what it runs as user SYSTEM, which (believe it or not) might not have the right kind of permissions. I know, you'd think that SYSTEM had access to everything - but if you have an activist IT shop, that won't be true. The ADMIN account will - but SYSTEM might be pared down a bit due to some security bulletins that came out a few years ago about Windows Task Scheduler's ability to do serious damage when running high-powered accounts.

Third, if ANY user has ever DIRECTLY opened the shared file from a 2013 Access workstation, that would have upgraded its references. The 2010 version would not have the right versions of those files and would therefore fall down. Note that if this were a split FE/BE case, opening a linked BE file from a 2013 FE file DOES NOT update references because that is an INDIRECT opening method.

Thanks for the reply Doc.

1. No the App is not split.

2. The task runs with Admin privileges.

3. This is the interesting one. I got a user to open an App on the server that it not used by any user. I then opened the App on the server and found a broken reference, it was looking for 15. So I re-set to 14. However when I tried the same with App that is falling over there was no broken reference??

The application is 15 years old (really!) and apart the odd problem has had no issues. After further investigation I did find out that the update problems coincide with an Office upgrade on user PCs. This must be the reason?

Splitting the database is the obvious solution. Originally the App was a standalone used by just one user but has evolved over time so that now several users access it. However the users require the ability to refresh data from an ODBC source at the end of the day. So I now have find out how to delete and re-import tables in the back-end from the front-end.

 

[gemma-the-husky]

If you open a database with A2016, the references will update to A2016
If you THEN open the same database with A2013, it will fail, because A2013 can't process the A2016 libraries.

[EDIT. I meant 2003 not 2013. I am pretty sure that 2013/2016 are the same, although they may not be]

1. Split the database
2. Don't use the same copy of the database for multiple users. Even though you can in principle, don't. It can lead to corruption
3. Issue a Accde/mde. (based on the OLDEST version of access in use) (the references won't update)

If you never had problems before, you may find the mde/accde is sufficient, although I am sure we would all advise the other ideas as well.

 

[Extra_Cover]

If you open a database with A2016, the references will update to A2016
If you THEN open the same database with A2013, it will fail, because A2013 can't process the A2016 libraries.

1. Split the database
2. Don't use the same copy of the database for multiple users. Even though you can in principle, don't. It can lead to corruption
3. Issue a Accde/mde. (based on the OLDEST version of access in use) (the references won't update)

If you never had problems before, you may find the mde/accde is sufficient, although I am sure we would all advise the other ideas as well.

accde of course (head slap!!). In my defense it is a very old App that has run for 15 years with no problems - 'if it's not broke don't fix it'.

Many thanks.