Has anyone Deploy MSAccess2013 onto MSAccess2010 worstation

[Rx_]

Upgrading MSAccess2010 front-end to MSAccess2013 - then using the MSAccess2013 copy to run on MSAccess2010.

Running one single copy of MS Access is the goal.
Microsoft has problems with the Upward compatibility. And, Microsoft rarely test the backward version compatibility.

Before running a MSAccess2013 file onto the MSAccess2010 workstation, the following will happen:
Open Blank MSAccess 2013 64-Bit on a Windows 2008 64Bit Server.
Import All Objects from a MSAccess2010.

WHY? Opening a MSAccess 2010 with the MSAccess 2013 Application has a problem. The Form and Report Styles revert back to Access 95 when running Access 2013. Yuck!

A solution was suggested to fix the styles: http://hitechcoach.com/index.php?op...article&id=58:backing-up-objects&catid=27:vba

My theory is that Import All Objects will accomplish the same for my hube amount of Forms with code.

Now, I end up with a MSAccess in 2013 format. This will be ready for the next release in MSOffice 2013. This runs on the Access 2013 TEST Server (client).

However, the existing Production server (client front end) is still running Access 2010.

Does anyone have experience running a MSAccess 2013 file on MSAcces 2010 workstations?

Actually, running Access 2010 and Access 2013 on different Citrix servers. The Workstation metaphor is used since it is the same as running on two different workstations.

 

[Rx_]

See attachment: On the Windows 2008 64-bit server running Access 2013 64-bit, used Import All Objects and imported from the Access 2010.

The attached image is the side-by-side view of a form - one in Access 2013 running on Server 2008 and the other running on Windows 7 with Access 2010.

Note the Title bar, then the buttons and window border.
On Office 2013, the style is something like a Windows XP - very square.

So now, what is causing the Style to degrade on Office 2013?
Or, is it the server and nothing to do with MS Access?

 

[GinaWhipp]

I just tested Access 2013 and Access 2010 on Windows 64 bit with no change in UI. Then I tried the same file on a Clients Windows 2008 64 bit Server and yep UI reverted. I'm going to say it's the Server.

As a side note, you're going to observe issues on Windows 10 as well, at least I have.

 

[Rx_]

Thanks!!
Noticed the VM uses a graphics card reference. Wonder if the default keeps it lightweight for memory usage. An article described how to turn up the graphics to 3D. Will ask my resident server guru to look into it and let you know if they find a solution.

Also found a Office 2013 Language update:
The Access 2010 copy used for Import All Objects compiled fine.
The Access 2013 did not compile.
Some code I didn't write actually referenced a chekbox's recordsource.
That might explain why they changed the error code to On Error Resume Next
The code was kind of a one-off quality control effort.

Thought I would throw this out there since it is all verified.
It is a very minor difference in the object model, intellisense and compiler.
But, it might save someone else some headache.

Note: the comment about the 'bad thing stopping on every line' was in the code. So, the compiler didn't find the error, but the code stopped in Access 2010. (sigh) another problem solved that was for a past project now long completed.

 

[GinaWhipp]

No problem... was curious anyway.

When taking over a database I normally run Find/Replace and rem those out then compile and fix anywhere it stops. Though not sure why that would be a problem as you can do both OR perhaps *changed* is a new reserved word. With web apps it might be, just another reason I prefix field names.

 

[Rx_]

That is a good idea.
This one kind of took me by surprise since it compiled in 2007 for the last few years. It wasn't until the Tools Reference was set to the new objects that it failed.

Then there was another distraction. Microsoft ActiveX Data Objects 6.0 Library on Windows 7 and my current Windows 2003 Server was located at C:\Program Files (x86)\ Common Files\System\ado\msado60.tlb
The new 2008 Windows Server (running Office 2013) only listed a Microsoft Active X Data Objects 6.1 (DLL).
Have not have time to look at the different between the 6.0 TLB and the 6.1 DLL.
Was able to use the Browse.. button to find the 6.0 at the exact path on Windows 7 (my development workstation) and 2008 Windows Server.
Since the Development product is being copied up to 2008 Windows Server (for Citrix deployment) my feeling is that keeping them the same is better. But, my feelings are subject to any good arguments for change.

As far as the debugger finding a new error, this is an improvement in Access. The Office 2007 didn't find the error, but it failed at runtime.

 

[GinaWhipp]

Hmm, I'm no help on the ADO Library, don't use any (except for the ones required) for precisely the reason you're having... nothing but issues when moving from one machine to another. Even the Excel one, I would use Late Binding so my code could care less what version the End User has.

Yeah, I think the good news somehow they have managed to make Debug > Compile more efficient in its job. Even if it was an accident... I'll take it!