.accdr error with A2013

I'd almost have to think that you and the other users have a bad install of 2013, or as you suggest a bad/faulty install of an update or SP. Have you tried a Repair on one of the machines? I'd be curious to see if that resolved the issue.

Ok ... I just tested this and I can change to DR no problem.

BUT ... I have a LOAD of O2013 updates sitting in Windows Updates. So, I will install those tonight and then try the same test.  I would install now, but I'm on a VZN wireless connection while at work, and I want to do the update via hardwired DSL.

mx

I haven't seen this, but am aware that there are bugs in the error messaging for A2013.

 So this is a full install of Office 2013 you were upgraded to?  and is that 32 or the 64 bit version?

 If you rename the database back, does it open and execute? no broken references or anything?

 I'm also wondering about the trusted locations issue, have you set a trusted location in Access 2013 for the DB?

I'm just thinking about anything which might cause execution to fail, leading to the error message.

Jim.

It is the 32 bit version of Office although I'm not sure where it says that.  I would have expected to see it in the about dialog.  The IT folks tell me that they are installing only 32-bit versions.

Renaming the file back to .accdb makes it work just fine.  Yes, locations are trusted.  The app will not open at all so I can't tell if it is even getting to my code.  The install on my PC will not open any .accdr's, even old ones.  But the other computer on my desk, displays the same version information and works just fine.  O2013 was installed on that computer back in the fall.  I just updated my primary computer on the 16th.

My version says 15.0.4605.1003.  I don't know if sp1 is installed.  The about dialog used to specify if service packs were installed but I think I read somewhere that it no longer does.

Pat … BREAKING NEWS JUST IN:

Hi everyone,

We are pleased to announce that we have now published the Access 2013 Runtime SP1 builds to the public.

Both the x86 and x64 installs can be found here:
http://www.microsoft.com/en-us/download/details.aspx?id=39358

This information is not NDA so feel free to share with anyone you need.

--
Jeff Conrad - Access Junkie
Senior SDET – Microsoft Access Test Team "Access 2013 – Changing the world one app at a time."

Thanks Jeff.  We are not using the runtime.  Everyone has the full version installed.  That is why I am using the .accdr extension.  Have you run into this problem before where the retail version (Office 365) refuses to open an .accdr?

"Thanks Jeff." >>. Thanks Joe :-)

I was just posting the notify from Jeff that we just received in the MVP DL and Google MVP DL.

I thought you had mentioned this might be related to SP1 ...

"Access 2013 Runtime SP1"

Pat,

 I don't think this would be related to the Runtime release that Joe posted about.  While it is the same executable, the runtime download is just a package with the right registry keys.  More likely, it was SP1 itself, unless you downloaded the runtime and the installer messed things up.

 SP1 are builds  15.0.4569.1506 and higher, so your on SP1.  SP1 was just released Feb 25th.  Hardly anyone is using 2013, so it doesn't surprise me that something like this might come up at this point.

 See if SP1 is listed in the list of installed programs.  If so, you may want to consider un-installing it, although a call to Microsoft is probably in order.

 This does sound like some kind of major bug.  

Jim.

Pat,

 I just confirmed this here...same problem, almost.

 I receive the warning with the full version, however if I double click on the *.accdr directly, it opens fine.

Jim.

In addition, it runs from a shortcut, both named as .accdr, and as an .accdb with the /runtime switch.

Jim.

I should note that I'm on build 15.0.4569.1503, which is SP1, but pre-release.

It is possible that something broke in the couple of builds after that.

Jim.

Referring to Posted on 2014-04-22 at 15:15:56ID: 40015976

The error message is correct IF you open Access first and then try to open an .accdr which is exactly what the error message is telling us.  There are three other options, ALL of which should open the .accdr without complaint but instead, ALL raise the error message.

Pat,

 Did you get anywhere with this?   And are you running 32 or the 64 bit Edition of Office.

 As I mentioned, I get the message, but not the problem your seeing and I'm only a minor build or two behind.

 If your still having the issue, I'll download and install Access 2013 SP1 released version to make sure I'm on the same build.

Jim.

I rechecked all the user computers.  We are ALL on the same build of Office 2013 32-bit.  I can't tell specifically whether or not SP1 is installed since MS decided that we no longer need to know that but based on the build numbers you posted earlier, it looks like we are.

My PC of course has additional software since I am the developer.  

Since mine is the only PC with the problem, MS wasn't interested in helping.  Therefore, I went back to A2010 yesterday afternoon which is working fine.  I guess I am destined to never move past A2010.

I went through the patch list and none of the computers, including mine, has any Office updates at all.  Mine has some .net framework updates, C++ updates,  and Silverlight updates that the others don't have and the Windows security patches are not identical so I suppose the problem could be caused by one of those.

I will leave this open for another couple of days in case someone has a brilliant idea.

Thanks for trying.

<<I guess I am destined to never move past A2010.>>

 Probably better off anyway; lot's of features dropped in A2013.  A2013 no longer has command bars, DBF support, ADP disappeared, etc.

 2010 is the last release that you can support all the older versions with.

Jim.

My thoughts exactly.  Thanks again.

"A2013 no longer has command bars, "
Well ... not exactly true. The commandbar object model is of course still there, and ... any Custom bars with still show up on the Add-Ins Ribbon.  You just cannot  only have the custom menu showing and not the ribbon - like you still can in A2010. At least, I have not yet seen a way to do this.
Not a problem for me, because I've come to find the Ribbon is superior to the old menu system - but w/o Gunter's tool, I would be telling a different story :-)

Frankly ... I think it's time for everyone to 'just get over it' ... IF ... you still want to work with Access. And with our LARGE company going to O365 shortly ... I'm in !

mx

It's hard to get over it when A2013 simply won't work - period!  Perhaps you have some pull with the PTB to get someone to look into the problem.  How many places in the code could that message be coming from?  It should only come from one place.  It is hard to believe that there is some outside issue but there appears to be.  I can't find any difference in the Office installation on any of the machines.  Before reverting to A2010, we also uninstalled and reinstalled Office 365.  So, now I have both versions of Access.  If you right-click on the .accdr and choose run with A2010 - it runs perfectly.  If you choose run with A2013 - it produces the posted message.

More than likely, it's something that's messed up in the registry.  The only difference between the full and run-time versions of Access is some registry entries.

 There's also the difference with O365 vs Office Pro Plus.

Jim.

Well, by 'get over it' ... I was speaking in VERY general terms. Trust me ... I fully understand the frustration. Even with A2010 - which I've been doing daily for two years ...  I'm still screaming at the little nuances that I find - where I must find a workaround - cuz I know it ain't gonna git fixed by MSFT - which I have no specific 'pull' with the product team, other than to report to them issues. But unfortunately, wherein the PT would LOVE to see every bug fixed - they are only a small part of the Office food chain :-(

I've never worked with the RunTime, so I'm not much help here, sorry.

mx

I love that the ribbon was orgranized by function, and I'd be the first to admit that I do work faster with it, but as a developer, I have a number of issues with it:

1. From a UI perspective, it's terrible - Group text is at the bottom of the group and not the top, arrangement in every group is different, etc.

2. It takes up too much screen real estate.

3. You gave me the ribbon, which is supposed to be more efficient to use,  so why do I need a "quick access toolbar" and a "back stage"?    Sure sounds like the design needs to be tweaked.

 If all they did was change the old menu model to a functional grouping, they would have been way ahead of the game.

 I know I'm speaking to the choir here, but dang seven years later and it still annoys the heck out of me.

Jim.

Thanks for the update Pat.

I believe we can go ahead and close this out with a delete or you can accept your own last comment as answer given it was the best solution for the circumstances.

Jim.

I have to disagree with Jim about the Ribbon.
Disclaimer 1: Initially, I hated the Ribbon, but ... I got over it :-)
Disclaimer 2: Without  Gunter's Ribbon Creator tool, I would not be making any of the comments below.
===
"1. From a UI perspective, it's terrible - Group text is at the bottom of the group and not the top, arrangement in every group is different, etc."

Not really seeing the problem (unfortunately, my screen capture pgrm won't capture the 'tips' below each icon)




"2. It takes up too much screen real estate. "
What space ?  :-)
(you can always minimize/restore the Ribbon)
 

"3. You gave me the ribbon, which is supposed to be more efficient to use,  so why do I need a "quick access toolbar" and a "back stage"?    Sure sounds like the design needs to be tweaked."

With the old menu system, we had tool bars also, so what's the difference ?
I see the Backstage as an extension of the File Menu ... wherein you can ... put a load of options for the user as necessary (although no options shown in the example below)


mx

<<"1. From a UI perspective, it's terrible - Group text is at the bottom of the group and not the top, arrangement in every group is different, etc."

Not really seeing the problem (unfortunately, my screen capture pgrm won't capture the 'tips' below each icon)>>

  Quick Access bar and tabs of the Ribbon read from top to bottom, then I need to jump to the bottom of section to read the section name, then up to read the icon text.

  Cardinal rule of interface design; don't make the user jump around.

<<"2. It takes up too much screen real estate. "
What space ?  :-)
(you can always minimize/restore the Ribbon)>>

 Well yeah, but I can't work with it when it's minimized.  If it's displayed, I've soaked up easily triple what I would use if I had a simple menu bar.

<<
"3. You gave me the ribbon, which is supposed to be more efficient to use,  so why do I need a "quick access toolbar" and a "back stage"?    Sure sounds like the design needs to be tweaked."

With the old menu system, we had tool bars also, so what's the difference ?>>

 The point was, why do I need both?  If the ribbon works so well functionally, then why do we need a quick launch or back stage at all?

Jim.

I was not able to identify a solution.  If I come up with something, I'll start a new thread with the answer and reference this one.