Access 2010 vs 2019 (1 Viewer)

Eljefegeneo

Still trying to learn
Local time
Today, 03:26
Joined
Jan 10, 2011
Messages
904
I have recently started upgrading the computers at work to all windows 10 and either Office 365 or whatever they call it (Access 2019) from Access 2010. I have 6 different databases and I upgraded all of them.

The only changes that I noticed were the declarations, where the new installations are 64 bit and most of the old code was in 32 bit. A few changes, adding PtrSafe to the declarations and all seems OK. I then reversed it and copied the Access 2019 files back to the computer using Access 2019 and so far all seems OK although I have not run through every form or query.

I have attempted to research the differences and the helpful page I found at:

https://www.fmsinc.com/microsoftaccess/history/features.htm

did not bring up anything I needed to be concerned with.

I did find a reference to the change in the "memo" field which is now called Long Text. But I checked the computer using Access 2019 the tables which had memo fields still have them. They are still called "memo" fields.

So, first of all, do I need to change them to "Long Text" and if so do I risk losing the data by doing this, or can I just leave well enough alone?

Second, is there anything else that comes to mind that I might be concerned with in this change over?

Thanks.
 

theDBguy

I’m here to help
Staff member
Local time
Today, 03:26
Joined
Oct 29, 2018
Messages
21,358
Hi. Sounds like you were mixing 2010 and 2019 there towards the end. There's really no practical difference in the file format, but there are differences in features. The one about PtrSafe is not about 2010 or 2019; but rather, it's about 32- or 64-bit Access install. Even 2010 has 64-bit version. Memo fields were also Long Text in 2010, so not sure you're seeing the right thing. That's why I said you may be mixing up things at the end. Cheers!
 

June7

AWF VIP
Local time
Today, 02:26
Joined
Mar 9, 2014
Messages
5,425
I run Access 2010 and Memo fields are called Memo not Long Text. Even new database shows Memo as type, not Long Text. Similarly, Short Text is just Text.

Probably don't have to change the field type in 2019 but you could make copy of db and see what happens if you do. Should not be any loss of data.
 

theDBguy

I’m here to help
Staff member
Local time
Today, 03:26
Joined
Oct 29, 2018
Messages
21,358
I run Access 2010 and Memo fields are called Memo not Long Text. Even new database shows Memo as type, not Long Text. Similarly, Short Text is just Text.

Probably don't have to change the field type in 2019 but you could make copy of db and see what happens if you do. Should not be any loss of data.
@June7. Thanks! I stand corrected. Now, I remember that switch happened with 2013. Cheers!
 

Eljefegeneo

Still trying to learn
Local time
Today, 03:26
Joined
Jan 10, 2011
Messages
904
Yes, 2010 has memo fields and 2019 has long text. I just wanted to know if the difference was real or imaginary. I am going to go with not changing the old field name until I get a problem. And yes, we backup daily!

As for the PtrSafe, that was just an explanation of the only coding I had to change. I use late binding as there was a problem with new computers, Windows 10 and different versions of MS Office, Office 365, Access 2010 etc.

Thanks all. I am going to bed with no worries!
 

isladogs

MVP / VIP
Local time
Today, 10:26
Joined
Jan 14, 2017
Messages
18,186
I have both Access 2010 (32-bit) & 365 )(both 32 & 64-bit)
The naming of Memo fields should be automatically be flipped between that and Long Text as you go back and forth.
If not perhaps a compact will fix that. Either way, no need to do anything about it yourself.

Updating APIs to 64-bit involves more than just adding PtrSafe.
Although that should compile, you also need to change any handles/pointers in declarations or Type statements to LongPtr to ensure correct functionality.
It will still work in 32-bit Access 2010 or later (anything based on VBA7)
Unless any of your users are running version 2007 or earlier, there is no need for conditional compilation

Other things to consider
1. Pivot tables were deprecated after A2010 as was data collection in Access from email
2. Some ActiveX controls do not work in 64-bit e.g. Treeview and Flexgrid
3. Any new features in A365 will not work for your A2010 users e.g. Use of Large number (bigint) datatype, 'modern' charts
 

Eljefegeneo

Still trying to learn
Local time
Today, 03:26
Joined
Jan 10, 2011
Messages
904
Thanks for the info on the "memo" vs "long text". The others I think I have covered.
 

Isaac

Lifelong Learner
Local time
Today, 03:26
Joined
Mar 14, 2017
Messages
8,738
Although that should compile, you also need to change any handles/pointers in declarations or Type statements to LongPtr to ensure correct functionality.
Hi, I was wondering about this statement. In the past all I have done is added PtrSafe. (Maybe I didn't have handles./pointers in declarations or Type statements) and wanted to learn more about what this means. Do you have any example by chance? Maybe I haven't done enough what I was supposed to on changing them.
 

theDBguy

I’m here to help
Staff member
Local time
Today, 03:26
Joined
Oct 29, 2018
Messages
21,358
Hi, I was wondering about this statement. In the past all I have done is added PtrSafe. (Maybe I didn't have handles./pointers in declarations or Type statements) and wanted to learn more about what this means. Do you have any example by chance? Maybe I haven't done enough what I was supposed to on changing them.
Hi. You might find this one helpful. Cheers!
 

isladogs

MVP / VIP
Local time
Today, 10:26
Joined
Jan 14, 2017
Messages
18,186
@Isaac
I have many examples such as this:

Code:
' TWIPS to PIXELS api declarations & constants
'###############################################
'CR checked 05/03/2019
#If VBA7 Then
    Private Declare PtrSafe Function GetDC Lib "user32" (ByVal hwnd As LongPtr) As LongPtr
    Private Declare PtrSafe Function ReleaseDC Lib "user32" (ByVal hwnd As LongPtr, ByVal hdc As LongPtr) As Long
    Private Declare PtrSafe Function GetDeviceCaps Lib "gdi32" (ByVal hdc As LongPtr, ByVal nIndex As Long) As Long
    
    Private Declare PtrSafe Function GetSystemMetrics Lib "user32" (ByVal nIndex As Long) As Long
#Else 'A2007 or earlier
    Private Declare Function GetDC Lib "user32" (ByVal hwnd As Long) As Long
    Private Declare Function ReleaseDC Lib "user32" (ByVal hwnd As Long, ByVal hdc As Long) As Long
    Private Declare Function GetDeviceCaps Lib "gdi32" (ByVal hdc As Long, ByVal nIndex As Long) As Long
    
    Private Declare Function GetSystemMetrics Lib "user32" (ByVal nIndex As Long) As Long
#End If

#If VBA7 Then
    Dim lngDC As LongPtr
#Else
    Dim lngDC As Long
#End If

And another fairly lengthy example
Code:
Private Const WM_GETICON = &H7F
                                
Private Const WM_SETICON = &H80
Private Const IMAGE_BITMAP = 0
Private Const IMAGE_ICON = 1
Private Const IMAGE_CURSOR = 2
Private Const LR_LOADFROMFILE = &H10
                                          
Private Const ICON_SMALL = 0&
Private Const ICON_BIG = 1&

#If VBA7 Then
    Private Declare PtrSafe Function apiLoadImage Lib "user32" _
       Alias "LoadImageA" _
       (ByVal hInst As LongPtr, _
       ByVal lpszName As String, _
       ByVal uType As LongPtr, _
       ByVal cxDesired As LongPtr, _
       ByVal cyDesired As LongPtr, _
       ByVal fuLoad As LongPtr) _
       As Long
    
    Private Declare PtrSafe Function apiSendMessageLong Lib "user32" _
       Alias "SendMessageA" _
       (ByVal hwnd As LongPtr, _
       ByVal wMsg As Long, _
       ByVal wParam As LongPtr, _
       ByVal lParam As LongPtr) _
       As LongPtr
#Else
    Private Declare Function apiLoadImage Lib "user32" _
       Alias "LoadImageA" _
       (ByVal hInst As Long, _
       ByVal lpszName As String, _
       ByVal uType As Long, _
       ByVal cxDesired As Long, _
       ByVal cyDesired As Long, _
       ByVal fuLoad As Long) _
       As Long
    
    Private Declare Function apiSendMessageLong Lib "user32" _
       Alias "SendMessageA" _
       (ByVal hwnd As Long, _
       ByVal wMsg As Long, _
       ByVal wParam As Long, _
       ByVal lParam As Long) _
       As Long
#End If

Private Const SHGFI_ICON = &H100
Private Const SHGFI_DISPLAYNAME = &H200
Private Const SHGFI_TYPENAME = &H400
Private Const SHGFI_ATTRIBUTES = &H800
Private Const SHGFI_ICONLOCATION = &H1000

Private Const FILE_ATTRIBUTE_NORMAL = &H80
Private Const MAX_PATH = 260

Private Type SHFILEINFO
   hIcon As Long
   iIcon As Long
   dwAttributes As Long
   szDisplayName As String * MAX_PATH
   szTypeName As String * 80
End Type

#If VBA7 Then
    Private Declare PtrSafe Function apiSHGetFileInfo Lib "shell32.dll" _
       Alias "SHGetFileInfoA" _
       (ByVal pszPath As String, _
        ByVal dwFileAttributes As LongPtr, _
        psfi As SHFILEINFO, _
        ByVal cbSizeFileInfo As LongPtr, _
        ByVal uFlags As LongPtr) _
        As LongPtr
            
    Private Declare PtrSafe Function apiDestroyIcon Lib "user32" _
       Alias "DestroyIcon" _
       (ByVal hIcon As LongPtr) _
       As LongPtr
#Else
    Private Declare Function apiSHGetFileInfo Lib "shell32.dll" _
       Alias "SHGetFileInfoA" _
       (ByVal pszPath As String, _
        ByVal dwFileAttributes As Long, _
        psfi As SHFILEINFO, _
        ByVal cbSizeFileInfo As Long, _
        ByVal uFlags As Long) _
        As Long
            
    Private Declare Function apiDestroyIcon Lib "user32" _
       Alias "DestroyIcon" _
       (ByVal hIcon As Long) _
       As Long
#End If

Private psfi As SHFILEINFO

Private Const SW_HIDE = 0
Private Const SW_SHOWNORMAL = 1
Private Const SW_SHOWMINIMIZED = 2
Private Const SW_SHOWMAXIMIZED = 3

#If VBA7 Then
    Private Declare PtrSafe Function apiShowWindow Lib "user32" _
       Alias "ShowWindow" _
       (ByVal hwnd As LongPtr, _
       ByVal nCmdShow As LongPtr) _
       As LongPtr
#Else
    Private Declare Function apiShowWindow Lib "user32" _
       Alias "ShowWindow" _
       (ByVal hwnd As Long, _
       ByVal nCmdShow As Long) _
       As Long
#End If
!
As previously mentioned, conditional compilation as above is only needed if you have users running A2007 or earlier.
If not just use the code given in the #If VBA7 section.

Rather than post lots of examples, you may wish to look at some of my example apps, all of which should work in 32/64-bit.
Both of the above were taken from my Attention Seeking app http://www.mendipdatasystems.co.uk/attention-seek/4594398116 which has many modules including some fairly complex APIs
 

Isaac

Lifelong Learner
Local time
Today, 03:26
Joined
Mar 14, 2017
Messages
8,738
Ok, thanks @isladogs
I knew about the conditional compilation (which I've never really needed) but not the additional LongPtr. Guess it shows I have not made use of a whole lot of different API's when using 64 bit.
 

Isaac

Lifelong Learner
Local time
Today, 03:26
Joined
Mar 14, 2017
Messages
8,738
By the way, without having ever seen your Attention Seeking App, I love the name just by itself. It makes me smile.
 

isladogs

MVP / VIP
Local time
Today, 10:26
Joined
Jan 14, 2017
Messages
18,186
I had to convert a large number of APIs at very short notice in my main school commercial databases back in 2012 or so when one of my client schools converted some workstations to 64-bit Office. Meanwhile I still had other users on A2003/A2007.
I had to use conditional compilation though my early attempts were far more complex than needed.
As I didn't really understand at the time which Long needed to be LongPtr and didn't have time to find out, I wrongly changed all of them to LongPtr.
The code compiled and of course, some APIs still worked...but not all.
Over a period of time, I went through and fixed them.

As well as the codekabinett link given earlier, I recommend downloading the Windows API Viewer converter utility.
Its available from http://www.rondebruin.nl/win/dennis/windowsapiviewer.htm
 
Last edited:

Lightwave

Ad astra
Local time
Today, 10:26
Joined
Sep 27, 2004
Messages
1,521
Just curious - I think I read that runtime of latest access version had issues with Bigint variable type.

Is this the case or was I mistaken in that point or has that been fixed now?
 

Users who are viewing this thread

Top Bottom