Upgrading to Access 2016 or 2021

[DavidK111]

Hello - I have been using Microsoft Access 2010 for many years.



It has been a great tool because it allows me to use it's drag and drop "intuitive" interface to create macros that I can run daily that import files, run queries, and export the results of those queries. The best part of Access 2010 is that I haven't had to do hardly any SQL (or other programming) and have been able to easily edit the relevant queries and imports/exports using the Macros features whenever the content or structure of my tables or queries need to be revised. Then each day, I simply run the Macro (one click essentially) and it runs all of my the imports, runs the queries, and then runs the exports (which I then import manually to various locations online). In other words, the best part of using Access is that I don't have to reach out to a developer or programmer every time that a file changed, or that a query or table column needed to be edited.

So, my question is whether Access 2016 or Access 2021 will be able to do the same kind of thing. I believe I had read awhile back that Macros are no longer as easy to use in the newer versions of Access, so I figured I would check here first to see if it is recommended that I stick with Access 2010.

Also, if you have broader insight into other tools that I should possibly use (such as another drag and drop tool that is similar to Access, or even a basic option that uses MySQL or other SQL databases....but designed to be used by non-programmer types), please feel free to suggest any alternative tools.

(And just an FYI, I am having problems with Access 2010 where it keeps freezing, after upgrading to a Windows 11 Computer. That is the reason I am considering upgrading now.)
Thanks for any suggestions!

[ranman256]

we have all versions and the db seems to work fine with all.

The problems begin when you use different reference versions, like office references. (vbe, tools, references) 1 pc uses Office access v15 driver, but others use Office Access v16 driver. so once v16 folks open it, it upgrades the driver so v15 users cant open anymore.
so you must make 2 versions for them to share : app15.accdb and app16.accdb

also user PTRSAFE for all DECLARE function so both Win32 & Win64 can open the db.

#If Win64 Then      'Public Declare PtrSafe Function
     Private Declare PtrSafe Function GetSystemMenu Lib "user32" (ByVal hWnd As Long, ByVal bRevert As Long) As LongPtr
 #Else
      Private Declare Function GetSystemMenu Lib "user32" (ByVal hWnd As Long, ByVal bRevert As Long) As Long
#End If

then the older db still work for new pc/office.

[CJ_London]

I still use 2010 for development as I have clients using all versions from 2010 and upwards. I’ve converted all my apps to work in 32 or 64 bit as ranman suggested (ptrSafe and longptr). I don’t use macros so no idea if that is an issue or not although suspect not since I don’t think macros can use APIs.

i do have 64bit 365 on a win 11 machine which runs 32bit 2010 developed apps with the only problem being populating a web control on a form - but no issues with freezing.

Basically later versions do more, not less

[isladogs]

also user PTRSAFE for all DECLARE function so both Win32 & Win64 can open the db.

The Windows bitness is irrelevant. What matters is the Office bitness

The hWnd definition in the Win64 section of that API declaration example is incorrect. It needs to be LongPtr
Better to use #If VBA7 which works in both bitnesses for A2010 or later:

#If VBA7 Then 'for use with A2010 or later (32/64-bit)     
       Private Declare PtrSafe Function GetSystemMenu Lib "user32" (ByVal hWnd As LongPtr, ByVal bRevert As Long) As LongPtr
 #Else 'for A2007 or earlier
      Private Declare Function GetSystemMenu Lib "user32" (ByVal hWnd As Long, ByVal bRevert As Long) As Long
#End If

If all users are running A2010 or later, that can be simplified to just:

Private Declare PtrSafe Function GetSystemMenu Lib "user32" (ByVal hWnd As LongPtr, ByVal bRevert As Long) As LongPtr

In case it helps, I have a series of 5 articles on this topic starting with: 32 to 64-bit Conversion (isladogs.co.uk)

[Micron]

Isladogs, you must have that as boiler plate somewhere, or you could bookmark threads where you've posted this same information on the subject. That would give you quick access as it seems you're going to continually have to post these corrections given that they're being "overlooked".

[isladogs]

Isladogs, you must have that as boiler plate somewhere, or you could bookmark threads where you've posted this same information on the subject. That would give you quick access as it seems you're going to continually have to post these corrections given that they're being "overlooked".

Yes doing that would save a lot of time.
I've posted repeated corrections on this subject in numerous threads mainly as information for the OP and anyone else reading them.
It would of course be better if the examples given were correct in the first place!

To clarify, the code I corrected will compile without error but it won't work in 64-bit Access.
The hWnd argument is a handle to a window and requires the additional memory space provided by LongPtr to work in 64-bit Access