UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> References Issue After Development Machine Upgrade, Access 2016    
 
   
john_willmott
post May 20 2020, 08:00 AM
Post#1



Posts: 536
Joined: 12-July 03
From: South Wales, UK


I have a FE/BE database which I developed for a client over the past 12 years, and been through numerous version changes!

I have been developing the front end on my machine with access 2013 32bit.

All the clients machines were upgraded to access 2016 32bit about 6 months ago. All the of the monthly FEs which are accde have been working fine on their machines.

Just tried to load the next version of the updated FE (first one produced on my 2016 version) and on the clients machine it now has a message box saying "Searching for referenced file: MSO.DLL"

The FE works fine on my machine and it works on one of their PCs. Because of Covid19, most of the office staff are at home, and are not using their PC's - they have a virtual PC on the using some terminal server software which is where the issue has been reported.

Am I correct in assuming the clients machines do not have the 2016 office references installed?

I cannot see the terminal server from my connection and the network guy is based in the netherlands and it is really difficult to get hold of him. I need to email him with instructions.

2 images references in the version developed in 2013 and 2016 (although they are both snap shots taken using 2016)

Any suggestions as to where I should start will be most welcome?

Regards

John




Attached File(s)
Attached File  FE_References_In_2013.png ( 24.76K )Number of downloads: 1
Attached File  FE_Reference_in_2016.png ( 19.5K )Number of downloads: 0
 
Go to the top of the page
 
GroverParkGeorge
post May 20 2020, 08:55 AM
Post#2


UA Admin
Posts: 37,493
Joined: 20-June 02
From: Newcastle, WA


"All the of the monthly FEs which are accde have been working fine on their machines."

So you apparently compiled this version of the accde with your version of Access, which 2016. And those users who do not have Access 2016 installed are getting this error.
That's probably because they don't have the same version of the DLL in question.

You should, as a general rule, compile accdes using the same version of Access that your users will have.

--------------------
My Real Name Is George. Grover Park Consulting is where I did business for 20 years.
How to Ask a Good Question
Beginning SQL Server
Go to the top of the page
 
vtd
post May 20 2020, 08:12 PM
Post#3


Retired Moderator
Posts: 19,777
Joined: 14-July 05
From: Sydney NSW Australia


>>...and are not using their PC's - they have a virtual PC on the using some terminal server software which is where the issue has been reported.<<

Not entirely sure of your description but if your user connects to a Terminal Server (aka Remote Desktop Server) then runs your database application (which means that the Terminal Server hosts MSAccess.exe + your database, the remote PC the user sits in front is more or less a dumb terminal), then you need to check the References collection of your database on the Terminal Server. There must be an Access installation on the Terminal Server.
Go to the top of the page
 
FrankRuperto
post May 20 2020, 09:22 PM
Post#4



Posts: 1,101
Joined: 21-September 14
From: Tampa, Florida USA


Hi John,

Access versions are not downward compatible. As a general rule of thumb, always compile with the lowest Access version if you need to distribute frontends to users with higher versions, e.g. compile with Access 2010 and distribute to users that have 2010, '13, '16, '19 installed.

Recent Windows 10 updates 2020-04 and 2020-05 removed several library references, DLL's and OCX's: https://www.forbes.com/sites/antonyleather/...s/#2adca857fcab
This post has been edited by FrankRuperto: May 20 2020, 09:29 PM

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix, Oracle & PostgreSQL db's.
Go to the top of the page
 
john_willmott
post May 21 2020, 10:37 AM
Post#5



Posts: 536
Joined: 12-July 03
From: South Wales, UK


Thanks for the reply,

To clarify: I was developing in 2013, but have now gone to 2016 on my development machine.

All client machines and the terminal server changed from 2013 to 2016 about six months ago.

It is only the users who are using a virtual desktop on the terminal server who are having the problem. The version developed in 2013 runs fine on the terminal server and on PCs with 2016.

The new front end developed in 2016 works on PCs running 2016 but not on the terminal server.

They have reverted back to the last version developed in 2013 which is working.
Go to the top of the page
 
john_willmott
post May 21 2020, 10:40 AM
Post#6



Posts: 536
Joined: 12-July 03
From: South Wales, UK


Thans for your reply.

Your explanation fits with an issue of the access installed on the terminal server. Will it be just a case of copying the 2016 MSO.DLL to (somewhere on the terminal server ??????)

Regards
John
Go to the top of the page
 
FrankRuperto
post May 21 2020, 10:54 AM
Post#7



Posts: 1,101
Joined: 21-September 14
From: Tampa, Florida USA


I think you will be better off re-installing 2016, but first rollback that Windows Update and disable updates so it doesn't re-install it and remove your DLL's, etc again. There's also some documented issues when remoting into a workstation that's running Access 2016.

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix, Oracle & PostgreSQL db's.
Go to the top of the page
 
vtd
post May 21 2020, 03:24 PM
Post#8


Retired Moderator
Posts: 19,777
Joined: 14-July 05
From: Sydney NSW Australia


>>Will it be just a case of copying the 2016 MSO.DLL to (somewhere on the terminal server ??????)<<

If the terminal server has Access 2016, the MSO.dll should already be there somewhere. You may only need to re-register it with regsvr.exe.

OTOH, it sound to me that the Access version on the terminal server is Access 2013, not Access 2016. Confirm the Access version on the Terminal Server with whoever looks it to be sure.
Go to the top of the page
 
john_willmott
post May 22 2020, 06:59 AM
Post#9



Posts: 536
Joined: 12-July 03
From: South Wales, UK


Thanks for the reply.

I pointed the network guy at these issues - It was running 2016 on terminal server - not sure why is had not installed correctly but he just copied the MSO.DLL from the office365 folder to the office 2016 part of shared folder on the terminal server and it worked!

Thanks to everyone for all your help.

Regards

John
Go to the top of the page
 


Custom Search


RSSSearch   Top   Lo-Fi    9th July 2020 - 09:43 PM