Access 365 Runtime

[Mike Krailo]

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.

 

[isladogs]

@Mike Krailo
I moved your question to a new thread so that it doesn't hijack the thread you posted it in

 

[pbaldy]

This would appear to be the comparable version:

Download and install Microsoft 365 Access Runtime - Microsoft Support

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.

support.microsoft.com

 

[Mike Krailo]

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.

 

[Cronk]

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

 

[Mike Krailo]

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.

 

[pbaldy]

Maybe post the code for that function that's being called?

 

[Mike Krailo]

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.

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

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.

 

[theDBguy]

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.

Hi. One way would be is to add error handlers in your code to tell you what's actually happening when there's a problem. Do you already have them?

 

[Mike Krailo]

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.

 

[theDBguy]

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.

Sounds good. Good luck! Let us know how it goes...

 

[Mike Krailo]

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?

 

[theDBguy]

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.

 

[Mike Krailo]

No, this is just a regular accdb file. Thought maybe there was a way to determine the version of access and 32/64 bit type it was compiled in.

 

[theDBguy]

No, this is just a regular accdb file. Thought maybe there was a way to determine the version of access and 32/64 bit type it was compiled in.

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.

 

[Mike Krailo]

If that is the case then why is there a procedure for decompiling that can clean up a a corrupted database?

 

[theDBguy]

If that is the case then why is there a procedure for decompiling that can clean up a a corrupted database?

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?

 

[Mike Krailo]

Yes, that helps. I did not know that.

 

[theDBguy]

Yes, that helps. I did not know that.

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.