What runtime is needed for an application that was compiled using M365 version of access. Can't get my database to run on other office computers. It used to work with the 2010 runtime but broke after I put Data Macros in there. Maybe I'm missing something.
Download the Microsoft 365 Access Runtime which allows you to run Microsoft 365 Access applications if you don't have the desktop version of Microsoft 365 Access and need to use an application built to run with Access 2010 or later.
Your users may have a different "bit" version of Office than you do. Are you developing in 32-bit or 64-bit version of Office. Make sure it is the same as your users.
Sorry about the wrong area to post isladogs. I did try to install the O365 32-bit version and got the same error. I used 32-bit since there is a 2013 32-bit version of Office Home edition on the one I'm testing on. Same exact error as noted above but I'm not getting any click to run error pointed out in that link. It's strange that this was all working fine a couple of weeks ago and now it doesn't work on any other computer in the office.
Pat, didn't see your post till after I posted. Yes, I'm developing on 64-bit and some users have 32-bit office and runtime. I could have swore it was working fine a couple of weeks ago.
This error (number 2001) can occur if the database is not in a trusted location. Try running the db in a folder where it has been made a trusted location File | Options | Trust Center | Trust Center settings | Trusted Locations | Add new location
Cronk, I tried that already including allow all macro's and still fails to launch on anybody else's computer. I've tried both 64-bit and 32-bit runtimes on different computers but no luck. Same exact error message.
In addition, I just tried sharing another older database that was developed on Access 2010 and it has the same problem. This leads me to believe it is a recent widows update thing but I'm surprised no one else has mentioned this. All of our office computers are running win10 with various versions of office installed. I have been experimenting on two of them using different runtimes.
I looked at that Startup function and had to comment out one line of code and it started up on all of the other computers, however, there are other runtime errors occurring now that never occurred previously. And if you look at the function that is commented out, all it does is get the username and set a tempvars for it. Certainly nothing that should cause a problem as it doesn't on my computer.
Code:
Function Startup()
' Set tempvars DBuser that contains the current windows username used for logging purposes
UserNameWindows
DoCmd.OpenForm "HardwareList"
End Function
and here is the called function
Code:
Function UserNameWindows() As String
Dim LoggedInUser As String
LoggedInUser = Nz(Environ("USERNAME"), vbNullString)
TempVars!DBuser = LoggedInUser
End Function
And the generic error message that pops up when trying to do normal things like edit a record or move an item or search for an item is:
How do you troubleshoot this sort of problem on a machine that just has the runtime installed? Again, the app works on any machine that has a recent version of Access on it. I need it to work on the one's that don't have access on their system.
How do you troubleshoot this sort of problem on a machine that just has the runtime installed? Again, the app works on any machine that has a recent version of Access on it. I need it to work on the one's that don't have access on their system.
Ah, maybe not enough of them. I'll go over everything and add in error handling. It's just frustrating seeing everything work on my machine and not on anyone else's when 2 or 3 weeks ago it worked fine on the other computers. I might have to get vbwatchdog.
Ah, maybe not enough of them. I'll go over everything and add in error handling. It's just frustrating seeing everything work on my machine and not on anyone else's when 2 or 3 weeks ago it worked fine on the other computers. I might have to get vbwatchdog.
I just found an older version of the database before putting the data macro's in there for auditing and all of the transaction coding that I did recently. It works without issue. I can't remember when I switched over to M365 64-bit but it wasn't that long ago and I'm wondering if going back to 32-bit version of M365 would help. Is there a way to tell which version/bit a database was complied in?
I just found an older version of the database before putting the data macro's in there for auditing and all of the transaction coding that I did recently. It works without issue. I can't remember when I switched over to M365 64-bit but it wasn't that long ago and I'm wondering if going back to 32-bit version of M365 would help. Is there a way to tell which version/bit a database was complied in?
Hi. Are you asking about determining if an ACCDE file was created in 32- or 64-bit Access? If so, there used to be a way, but I'm not sure what is the new way now.
Okay, for an ACCDB file, the code is compiled at runtime. So, whether it's compiled as 32- or 64-bit will be based on which computer you're running it.
Hi. That's a separate issue than determining the bitness of the compiled code. When you run your VBA code for the first time on the same machine, it gets compiled. If you run it again, it doesn't need to be compiled again. But, if you take it to a different machine with a different bitness, then it gets compiled again. Does that help?
No worries. So, when you create a ACCDE file, the code is compiled permanently. When you take it to another machine, it can't be recompiled again. So, if it was compiled using 32-bit and you try to run it on a 64-bit, then it doesn't work.
support.microsoft.com
