Stopping 2013 from opening 2010 (1 Viewer)

[aaronb50]

So I have a few programs on the server that are 2010 and when someone opens them using 2013, I guess converts it, and no one using 2010 can use it anymore.

I know I can use SysCmd(acSysCmdAccessVer) to get the version.

Can I put this as the very first line of code the program sees and if someone is using 2013, give them a msgbox telling them to see the admin and then docmd.quit to shut it down before anything bad happens?

Or does that conversion or whatever 2013 is doing to the program happen before I can catch it?

 

[CJ_London]

I think the conversion happens when the db is first opened - the user will be prompted with something like 'this database is in an earlier version of access - do you want to update it?' and the user chooses yes - although it will still work if they no. So perhaps some user training required?

sounds like you have not split your database. you should have tables only in a .accdb back end and everything else in a front end - and each user should have a copy of the front end on their machine and not be using the one on the network.

Ideally the front end should be compiled to .accde (in 2010) so users cannot change the code - not experienced it but perhaps someone else can advise if 2013 will run a 2010 .accde? or whether a 2013 .accde file is also required.

google 'splitting access database' for plenty of threads on the subject.

 

[aaronb50]

And you said it, I should have a copy on each machine.

I have it on the server so that anytime we make a change to any of the front ends, the shortcut takes everyone to the same updated version and I don't have to go around and put a new local copy on everyone's machine. And I know that is frowned upon but other then when we move to a new version of Access its never been an issue.

But I think that is what I'm going to do. It would only take a few hours to go around an put a local copy up on everyone's computer. And then just make updates as needed. And that would save me a ton of headaches.

And sometime next year when everyone has migrated to 2013, we can go back to running the front end off the server if we want. But......... maybe after spending some time with the program on local machines, I will find its not that much of an upkeep and just keep doing it that way.

Thank you so much!!!!

 

[CJ_London]

there are plenty of threads on this and other forums on the subject of checking local versions against master versions and updating the local version if required. The all you do is update the master version and the rest takes care of itself

 

[gemma-the-husky]

application.version will give you the version, though

(it's a string, not a number. I think they missed 13 for bad luck!)
11.0 is A2003
12.0 is A2007
14.0 is A2010
15.0 is A2013


Having said that, I can't think that opening a A2010 database with A2013 will change it. It doesn't convert it, as you put it. What might happen is that the dbs remembers the last version used, and tries to use that, so by using A2013 the user has already "set" the last version.

I expect your A2010 users could open access directly, and THEN open the database without issue.

Or give them a shortcut to open the target database with A2010.

and don't forget the suggestions already made about not sharing the dbs.

 

[Frothingslosh]

This is a problem I ran into constantly when I worked at a place that used 2003, 2007, and 2013 on different machines. The problem arises because as soon as the database is opened, 2013 automatically updates the references to their 2013 versions - MS Office 15 Reference Library, Excel 15 Reference Library, etc. In fact, it would also replace the dao 3.6 library with the access database engine object library with mdb files.

Then, when re-opened on a lower-version machine, that lower level machine could not revert the changes. I don't know why. Instead, you would have to go in and hand-change the references for any office products (and the dao library if it was an mdb).

The only 'fix' we were able to implement was to create side-by-side mdb and accdb versions.

And you said it, I should have a copy on each machine.

I have it on the server so that anytime we make a change to any of the front ends, the shortcut takes everyone to the same updated version and I don't have to go around and put a new local copy on everyone's machine. And I know that is frowned upon but other then when we move to a new version of Access its never been an issue.

But I think that is what I'm going to do. It would only take a few hours to go around an put a local copy up on everyone's computer. And then just make updates as needed. And that would save me a ton of headaches.

And sometime next year when everyone has migrated to 2013, we can go back to running the front end off the server if we want. But......... maybe after spending some time with the program on local machines, I will find its not that much of an upkeep and just keep doing it that way.

Thank you so much!!!!

Two easy solutions. The one at my current place of employment is to simply distribute a shortcut to each user. The shortcut points to a batch file on the network, and the batch file first checks for BLOCK.txt (to lock out users if necessary), and if it doesn't exist, automatically downloads a copy of the front end to the local machine, replacing any existing copies. Then it executes the local copy. This approach could, in theory, cause a lot of network traffic, but all of these apps have no more than 15-20 users in a 6,000+ person company, and the traffic pales in comparison to all the calls to the ginormous SQL server databases we maintain. The network can handle it.

Another option, based on code originally posted by Bob Larson, can be found HERE.

 

[aaronb50]

Thank you everyone for all the information. My original question has definitely been answered:

No I can not shut the program down before what happens happens. And I know have a way better understanding of what is actually happening.

I am going to give my boss two options.

The first, it would take less then an hour to move all the front ends to one folder and send out an email to everyone with a link to that folder and tell them to bring down a copy of what programs they need by the end of the week and turn their shortcuts off. Basically I can get a local copy of all programs on everyone computer in less then an hours worth of work.
And this will be my suggestion.

Or if he still want to run off the server, I can make a 2010 version and a 2013 version for the ones that need it. Then make a 3rd program that checks what version they are running. Their new shortcut will point to that 3rd program and it will open the correct version for them. I don't like this, I think it involves more upkeep but he seems to want to work off the server so I'll give him the option.

Either way I believe we can make this work. And I have a much better game plan going into this when we do it again in 3 years. lol

Thanks again all!!!!

 

[aaronb50]

Oh........ and I will definitely look into figuring out how to get a local copy to check to see if its the latest and then download the newest if its not.

That a genius way to keep local copies without the hassle of having to manually update them.

 

[gemma-the-husky]

@frosthing slosh.

that's a good point about the references being updated.. It prompted me to wonder though ...

I use A2003 mdb databases. I open a .accdb dbs and A2010 installs automatically. I later open one of my A2003 and it opens with A2010.

So, I reopen A2003, and it installs again. Now I open the A2003 mdb, without getting a references issue.

also, I use outlook 2013. (which - unproven - I believe is not compatible with outlook) so I open A2013 and open the mdb database with it, to test outlook. Now I go back to A2003, and I can still use the mdb database without having to change the references.

So I wonder at which point the references change?

 

[CJ_London]

Dave's comment has prompted another thought.

I haven't been able to test it but if the 2013 users had 2010 runtime installed as well - does this swap in silently and quickly?

Alternative would be 2010 users having 2013 runtime

Problem with runtime is you need to design with runtime in mind i.e. no access to ribbon/navigation window/shortcut menus so you need to write your own.

Also, I believe all versions need to be the same 'bit', don't think you can have 64bit full version and 32 bit runtime for example.

 

[Minty]

I develop on 2010, but almost everyone uses 2013 run-time without problem, I also have tried where possible to use late binding, which helps.
I don't think the runtime updated the references, I think that is done by the underlying office installation files.

 

[CJ_London]

interesting - do they run compiled code or uncompiled code?

 

[Minty]

The databases are distributed as an accdb file. Never thought to send out an accde as it's only for internal use. Might be worth looking at though. Are there any benefits either way?

Edit - As an aside we have developed a problem with the spell checker stopped working in access as a result of either office or windows updates. We have had to install a version of sharepoint designer to get around the problem Which sort of reinforces my view that is the office install that does for the references.

 

[CJ_London]

I always use .accde, primarily because I am supporting clients rather than developing for internal use.

Benefit of .accde is the code, form and report designs are protected from user interference. I also believe they are less susceptible to corruption, but can't prove it!

 

[Frothingslosh]

Well, at the previous employer, the final solution in the end was that word came down from on high that all access usage was to be terminated immediately because Access is a poorly-designed, limited, ineffective program not suited for a business environment, and that the company's already-massively-overworked C# programmers were to immediately convert all several dozen Access applications to C# executables. (This does include the 16,000 like app I wrote to handle the a painfully non-standard business process that is driven by exceptions rather than rules.) Oddly, this ruling coincided with a new BI manager coming on who hated Access with a passion because, in her words, 'it's a toy that doesn't even work, much less meet the requirements of even a small business'.

Anyway, that aside, that auto-install of the 2010 runtime Dave mentioned wasn't happening at that place. You simply could not open an .accdb with 2003, period, and opening an .mdb with 2013 caused the references to get borked. (Strangely, I don't recall issues going to and from 2007, just between 2003 and 2013.) I even at one point suggesting installing the 2013 runtime where necessary, and was told it wasn't an option, because the IT company we used (which that manager I mentioned came from) refused to support Access and any program or procedure involving it.

I can tell you that references are updated very first thing, even before the AutoExec macro is run. I learned that one the hard way. And it's not something you can work around with late binding - even things like Left() and IsNull() were returning errors when the references were busted.

 

[CJ_London]

2013 does not support 97 mdb, although I guess OK for 2000/2003 - but many 'upgrades' may not have happened because 2000/2003 ran a 97 db without problems. So you may have 2003 installed, but running a 97 db

Access support of Jet 3.x IISAM
You can no longer open an Access 97 database in Access 2013. You'll need to upgrade the file. To do this, open it in Access 2010 or Access 2007, save it in the .accdb file format, and then open it in Access 2013.
This change also affects databases that are linked to Access 97 databases