Have you tried to republish it under Windows 11?

Also you may need to actually install any of the Active x controls the app needs as Windows 11 seems to deal with unregistered active x controls differently… Especially if you previously just copied the .ocx files around before…

 

 

I didn't touch any of the .ocx files.  The laptop just upgraded it to Windows 11.  To my knowledge, none of the .ocx files were modified but I could be wrong.  How do I know which ones were not registered.  Below is a list of the references that I use.

I haven't worked with Access for over a decade, but I do know that Windows 11 dropped Internet Explorer, so may of the Active x controls that used to be there by default are not there anymore, AND the upgrade also strips out a lot of the IE controls that might have been left behind.

If your database depended on these to just be there you might have to see if you can find installers, or try to recompile the app under windows 11…

Also if you are using Access 2016 or earlier to compile your app I don't think it is 100% compatible with Windows 11

 

To your knowledge, do any of the references above involve Windows Explorer?

You will have to search that as I haven't worked in Access development for a decade… But I am pretty sure if you try to recompile under Windows 11 it will tell you if controls are missing…

 

will not run properly

What happens?  Do you get any error messages?  Can you post a screenshot.

 

If it was a Reference or ActiveX issue, it would spit out errors to you.

 

Does your code compile without errors?

Did you validate that a Trusted Location is still defined for the database?

Can you share you Access Edition, build, bitness.

 

Perhaps run an Office Repair, maybe the OS upgrade messed something up.

 

 

But if you've rolled back things, there no way for us to help you resolve the issue.

As Daniel said, we need a little more details as to the nature of the error(s).  There is no issue per say  with running Access 365 under Windows 11.

 

But a few things that easily can go wrong:

1. Bitness - Old was 32, new is 64.   You said this wasn't an issue though.
2. References, which Daniel spoke of.  You need to try and compile the app on the new machine.
3. You relied on a mapped drive for a connection to your backend which stores the data.   This might be true even if both your Front End (the app part) and the backend (the DB with the data) are on the same machine.
   
   
   but without specifics on the error/problem, we're all just taking shots in the dark pretty much.
    

I don't run the 64 bit version of MS Access.  Only 32 Bit. One problem I've run into in the past is that Microsoft gives the same names to all of their controls / files / dlls etc.  Has caused a lost of headaches previously.  This, however, has not reared it's head until now. I bought a new Alienware laptop to use as the test bed machine.  I'll try all of the steps recommended and report back on this string.  Thank you all for your input.

<<One problem I've run into in the past is that Microsoft gives the same names to all of their controls / files / dlls etc.  Has caused a lost of headaches previously.>>

  This is especially true starting with Office 2013 and up.   It's not possible to run multiple versions of Office on the same machine anymore.

 

  In the past, you could get away with it by installing to separate directories, but not any more.

 

   And with Office 2016 and up, they all identify internally as Office version 16.0

 

Jim.

Hi Jim,

just to mention: I've installed 32Bit of A2007, A2010 and A2013 on the same machine with no problems. I Don't know if that is still possible using a higher version (of course the singleton versions, not A365).

Cheers,

Christian

Christian,

 

<<just to mention: I've installed 32Bit of A2007, A2010 and A2013 on the same machine with no problems.>>

 

 Yes, that is certainly doable.   You can even mix up the bitness a bit.  ie. run 2010 as 32 bit and 2013 as 64.  (you can't mix bitness though within a single version).

  2010 was the last “full” version of Access, which included things like ADP's.   A2013 was when they tossed a lot of features out, which I believe was in preparation for moving to a single code base starting with Office 2016.

 

<<I Don't know if that is still possible using a higher version (of course the singleton versions, not A365).>>

 

 It's not.  Once you get on 2013 or up, you can't mix versions.   i.e. 2013 and 2016 on the same machine won't fly.  Only way to run multiple versions on the same PC is to use virtual machines.

 

 That applies to the perpetual editions as well as the Office 365 ones.    Starting with 2016, the perpetual editions are O365 at a given point in time, and all internally identify as version 16.

 

 and FWIW, I'm not spilling the beans here in anyway.   This is all public knowledge mentioned in numerous places.

 

Jim.

I always declare my recordsets as “Dim rs As ADODB.Recordset”.  Thank you for that reminder.

 

I really miss the ADP's.  They were fast and efficient front-end connections to SQL Server and we built an entire ERP for a repair facility with them.  Had 500 concurrent users and never slowed down.  I get that ADPs could have impacted the C# adoption but Access Reporting has been really helpful.  

 

I only use Office 365.  I have to upgrade the RAM on the new machine with the 64GB I bought and install the high iops SSD.

 

Thank you all for your support and incredible insights.  Very grateful.

 

Standby

see image below

Based on the comments above, this is what I have updated my references to.

 

When I try to compile, it fails

 

see screenshot

I have purchased an Alienware laptop (clean) w/ Windows 11.  I9 - 65gb RAM, 2tb SSD + 1tb Sony 990 Hi-IOPS SSD

 

Here's the new order in my references where I'm still getting the error:

 

Hi,

if everything is right you should see "Recordset" after typing "." after "ADODB". Otherwise there is still something wrong. Of course you should not have a module named "ADODB" or something like that.

If available, use 6.1 instead of 6.0.

I would sort the ADODB before ADOX.

Cheers,

Christian

Fixed the Problem.  Now runs in Windows 11

 

Do you truly need all those references?

This is also where Late Binding can be beneficial.

Hi,

oh, I see the problem, didn't saw it before: You have the ADO Recordset library included, and the right one is the one in the blue line.

The Recordset library is a "light" ADO library with only a subset of the objects of the ADO library, but included there so you should simply remove the Recordset library (which is why it's 6.0 where the full library is 6.1).

Cheers,

Christian