Page 1 of 2 12 LastLast
Results 1 to 15 of 28
  1. #1
    Sck is offline Advanced Beginner
    Windows 8 Access 2013
    Join Date
    Jul 2010
    Posts
    82

    32 bit to 64 bit - How difficult??


    it appears that the company i work for has decided that all future Office upgrades and and new computers are going to have the 64 bit version of Office 2016. I have NO input or pull to change the decision so i have to live with it. I have about 15 multi user Access applications that i have developed over the past 10 years that were all developed in the 32 bit enviroment. They all just use the standard Access form objects (comboboxes, listboxs, tabstrip, ......) and connect to Access backends via linked tables. All the processing is done via VBA. Several of them export to Excel and format/process the output using calls to Excel VBA.

    I dont currently have the 64bit version so i cant start looking into what is going to be required.

    I am just looking for thoughts on how big a project I have in front of me.
    the part that I KNOW is going to be a pain is the maintaining of 2 versions of each application until everyone is on the new version. Several of these tools are mission critical so I will have to make the changes ASAP but I want to manage expectations going in to the change.

    Also, can I run both the 64 and 32 bit versions of Office (at least Access and Excel) on the same machine?

  2. #2
    ranman256's Avatar
    ranman256 is online now VIP
    Windows Vista Access 2010 32bit
    Join Date
    Apr 2014
    Location
    Kentucky
    Posts
    9,521
    convert your API calls using PtrSafe:

    Declare PtrSafe Function MyMathFunc Lib "User32" (ByVal N As LongLong) As Long

    (a global replace will do this fast) and you can run it on both OS's.
    or
    Code:
    #if Win64 then
       Declare PtrSafe Function MyMathFunc Lib "User32" (ByVal N As LongLong) As Long
    #else
       Declare Function MyMathFunc Lib "User32" (ByVal N As Long) As Long
    #end if

  3. #3
    CJ_London is online now VIP
    Windows 10 Access 2010 32bit
    Join Date
    Mar 2015
    Posts
    11,397
    if your users use .accde then you will need two versions - one for each bit - so modifying code such as Ranman suggests means you need two machines to create the .accde. You cannot run 64bit and 32bit side by side on the same machine. If your users use .accdb's then subject to making these changes it should run in either environment.

    Note it is only long pointer types (e.g. hwnd) that need to be handled. Typically used in API calls (where you must also use PtrSafe) but you might also be using them in your general code.

    Slight alternative is to use LongPtr which will be interpreted correcting in 32b or 64 bit i.e.

    Declare PtrSafe Function MyMathFunc Lib "User32" (ByVal N As LongPtr) As Long

    Note it is only long pointer types (e.g. hwnd) (which are longs in 32bit and longlongs in 64bit) that need to be handled. Typically used in API calls but you might also be using them in your general code. Do not do a blanket change of all longs to longptr. It won't affect 32bit, but it will affect 64bit.

    I KNOW is going to be a pain is the maintaining of 2 versions
    In summary you need one development copy and one machine for each bit version if providing users with .accde's. Backends should be .accdb and contain no code, so are not affected.

    Also, can I run both the 64 and 32 bit versions of Office (at least Access and Excel) on the same machine?
    Nope, you will need two machines unless you are going to play around with virtual drives. So far as I am aware, the only benefit of 64bit office is for excel power users who want more than a million rows of data. I can't speak for Excel VBA (I would expect same rules as with Access VBA) but an excel file will work in either environment - except a file with more than a million rows can only be opened in 64bit. So providing your excel file has less than a million rows, either version of Access will open the file.

    When 64bit was introduced, a number of Active X controls were not converted so these need to be replaced with something else. However as time has gone on many of these now have a 64 bit equivalent

  4. #4
    Sck is offline Advanced Beginner
    Windows 8 Access 2013
    Join Date
    Jul 2010
    Posts
    82
    thanks it looks like 99% of the code will be fine. I am not doing anything really in depth in terms of actual code. most of it is just simple data manipulations and read/writes. Wish I could argue the point about changing to 64 bit but I is not up to me. I have a feeling that they will run into enough issues that they may change the standard but only time will tell. now to convince them that it is going to require a 2nd machine so I can make the updates.

  5. #5
    isladogs's Avatar
    isladogs is offline MVP / VIP
    Windows 10 Access 2010 32bit
    Join Date
    Jan 2014
    Location
    Somerset, UK
    Posts
    5,954
    Agree with Ajax's comments.
    For maximum flexibility, you should use LongPtr (which works in both 32-bit & 64-bit) instead of LongLong (which only works in 64-bit).

    For example:

    Code:
    #If VBA7 Then 'need datatype LongPtr    
    Private Declare PtrSafe Function apiGetClientRect Lib "user32" Alias "GetClientRect" (ByVal hWnd As LongPtr, lpRect As typRect) As Long
        Private Declare PtrSafe Function apiGetWindowRect Lib "user32" Alias "GetWindowRect" (ByVal hWnd As LongPtr, lpRect As typRect) As Long
        Private Declare PtrSafe Function apiSetWindowPos Lib "user32" Alias "SetWindowPos" (ByVal hWnd As LongPtr, ByVal hWndInsertAfter As LongPtr, _
            ByVal X As Long, ByVal Y As Long, ByVal cx As Long, ByVal cy As Long, ByVal wFlags As Long) As Long
        Private Declare PtrSafe Function apiShowWindow Lib "user32" Alias "ShowWindow" (ByVal hWnd As LongPtr, ByVal nCmdShow As Long) As Long
    #Else
        Private Declare Function apiGetClientRect Lib "user32" Alias "GetClientRect" (ByVal hWnd As Long, lpRect As typRect) As Long
        Private Declare Function apiGetWindowRect Lib "user32" Alias "GetWindowRect" (ByVal hWnd As Long, lpRect As typRect) As Long
        Private Declare Function apiSetWindowPos Lib "user32" Alias "SetWindowPos" (ByVal hWnd As Long, ByVal hWndInsertAfter As Long, _
            ByVal X As Long, ByVal Y As Long, ByVal cx As Long, ByVal cy As Long, ByVal wFlags As Long) As Long
        Private Declare Function apiShowWindow Lib "user32" Alias "ShowWindow" (ByVal hWnd As Long, ByVal nCmdShow As Long) As Long
    #End If
    If all your users are running Access 2010 or later (VBA7), the first section will normally run whether it is 32-bit or 64-bit.
    The second section is needed for users running 2007 or earlier

    So if none of your users have pre-2010 it is often enough to just write:
    Code:
     Private Declare PtrSafe Function apiGetClientRect Lib "user32" Alias "GetClientRect" (ByVal hWnd As LongPtr, lpRect As typRect) As Long    Private Declare PtrSafe Function apiGetWindowRect Lib "user32" Alias "GetWindowRect" (ByVal hWnd As LongPtr, lpRect As typRect) As Long
        Private Declare PtrSafe Function apiSetWindowPos Lib "user32" Alias "SetWindowPos" (ByVal hWnd As LongPtr, ByVal hWndInsertAfter As LongPtr, _
            ByVal X As Long, ByVal Y As Long, ByVal cx As Long, ByVal cy As Long, ByVal wFlags As Long) As Long
        Private Declare PtrSafe Function apiShowWindow Lib "user32" Alias "ShowWindow" (ByVal hWnd As LongPtr, ByVal nCmdShow As Long) As Long
    The exception will be for items which are 32-bit or 64-bit specific e.g. GetTickCount / GetTickCount64. In those cases, you need a construct like
    Code:
    #If VBA7 then 
      
    #ElseIf Win64 Then
    
    #Else
    
    #End If
    Ajax's is absolutely correct in stating that only pointers such as hWnd need LongPtr
    However for several years, I used a blunt force approach and converted all Longs to LongPtr. Its incorrect to do so but it always worked perfectly!

    Here are two very good articles to help you:
    https://codekabinett.com/page.php?Theme=5&a...tion-VBA-64-bit and https://docs.microsoft.com/en-gb/office/VBA...ations-overview
    Colin, Access MVP, Website, email
    The more I learn, the more I know I don't know. When I don't know, I keep quiet!
    If I don't know that I don't know, I don't know whether to answer

  6. #6
    CJ_London is online now VIP
    Windows 10 Access 2010 32bit
    Join Date
    Mar 2015
    Posts
    11,397
    Several years ago one of my clients move to 64bit office - 6 months later they moved back to 32bit. I don't have a definitive answer why they moved back but understand it was down to a number of business critical issues connecting to other systems (not access) which either could not interact to 64bit office or the cost of upgrading so they could was too high.

  7. #7
    Roby-chan82 is offline Novice
    Windows 10 Access 2016
    Join Date
    Feb 2019
    Location
    Verona, Italy
    Posts
    9
    Hello Everyone from Italy!
    I'm new to this forum. I have a similar problem, but I'm asking help because I'm not good with VB.
    I have a DB of customers that was built years ago in a old pc running 32bit and Access 2003 (maybe, I don't remember well).
    Now I bought a new pc, with Win10, and purchased MSOffice 2016.
    The problem is that I cannot open my DB. Here is the error:

    Code:
    Private Declare Function ChooseFont Lib "comdlg32.dll" Alias "ChooseFontA" _
    (pChoosefont As FONTSTRUC) As Long
    Private Declare Function GlobalLock Lib "kernel32" (ByVal hMem As Long) As Long
    Private Declare Function GlobalAlloc Lib "kernel32" _
      (ByVal wFlags As Long, ByVal dwBytes As Long) As Long
    Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" _
    (hpvDest As Any, hpvSource As Any, ByVal cbCopy As Long)
    Private Declare Function GetDeviceCaps Lib "gdi32" _
      (ByVal hdc As Long, ByVal nIndex As Long) As Long
    Private Declare Function GetDC Lib "user32" (ByVal hWnd As Long) As Long
    Click image for larger version. 

Name:	Access Error Visual Basic.jpg 
Views:	53 
Size:	111.7 KB 
ID:	37421

    Can you help me to modify this part of the code, so that I can open my DB?
    Thank you very much, and greetings from Verona!
    Roby

  8. #8
    isladogs's Avatar
    isladogs is offline MVP / VIP
    Windows 10 Access 2010 32bit
    Join Date
    Jan 2014
    Location
    Somerset, UK
    Posts
    5,954
    You've installed the 64-bit version of Access 2016 because that was the option you've selected.
    If you have no special reason for using 64-bit Access, I would uninstall and install the 32-bit version from the same source (CE or online)

    Otherwise if you want to keep 64-bit, the code below should allow it to work in both 32-bit & 64-bit:

    Code:
    #If VBA7 Then
    Private Declare PtrSafe Function ChooseFont Lib "comdlg32.dll" Alias "ChooseFontA" _
    (pChoosefont As FONTSTRUC) As Long
    Private Declare PtrSafeFunction GlobalLock Lib "kernel32" (ByVal hMem As LongPtr) As LongPtr
    Private Declare PtrSafeFunction GlobalAlloc Lib "kernel32" _
    (ByVal wFlags As Long, ByVal dwBytes As LongPtr) As LongPtr
    Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" _
    (hpvDest As Any, hpvSource As Any, ByVal cbCopy As LongPtr)
    Private Declare PtrSafeFunction GetDeviceCaps Lib "gdi32" _
    (ByVal hdc As LongPtr, ByVal nIndex As Long) As Long
    Private Declare PtrSafe Function GetDC Lib "user32" (ByVal hWnd As LongPtr) As LongPtr
    #Else
    Private Declare Function ChooseFont Lib "comdlg32.dll" Alias "ChooseFontA" _
    (pChoosefont As FONTSTRUC) As Long
    Private Declare Function GlobalLock Lib "kernel32" (ByVal hMem As Long) As Long
    Private Declare Function GlobalAlloc Lib "kernel32" _
    (ByVal wFlags As Long, ByVal dwBytes As Long) As Long
    Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" _
    (hpvDest As Any, hpvSource As Any, ByVal cbCopy As Long)
    Private Declare Function GetDeviceCaps Lib "gdi32" _
    (ByVal hdc As Long, ByVal nIndex As Long) As Long
    Private Declare Function GetDC Lib "user32" (ByVal hWnd As Long) As Long
    #End If
    If you only have 64-bit Access available, hold the shift key down whilst the open it in order to bypass the startup code
    Colin, Access MVP, Website, email
    The more I learn, the more I know I don't know. When I don't know, I keep quiet!
    If I don't know that I don't know, I don't know whether to answer

  9. #9
    Sck is offline Advanced Beginner
    Windows 8 Access 2013
    Join Date
    Jul 2010
    Posts
    82
    ok I have edited/changed most of the 64bit offending code in my tools but there are a couple lines I wanted to have yall look at:

    Private Declare PtrSafe Function apiGetUserName Lib"advapi32.dll" Alias _
    "GetUserNameA" (ByVal lpBufferAs String, nSize As Long) As Long

    Private Declare PtrSafe Function GetSystemMetrics Lib"user32.dll" (ByVal nIndex As Long) As Long

    do I need to use the LongLong in these? really not sure when it is required or not. the code seems to be working as is but I want to make sure it is correct. (working does not always equal correct)

  10. #10
    isladogs's Avatar
    isladogs is offline MVP / VIP
    Windows 10 Access 2010 32bit
    Join Date
    Jan 2014
    Location
    Somerset, UK
    Posts
    5,954
    Always use LongPtr (where needed) rather than LongLong. LongPtr works in both bitnesses. LongLong only works in 64-bit.

    Rather than pick off individual API declarations one by one, suggest you download a guide to assist you do it yourself.
    For example: Windows API Viewer for Excel (also applies to Access)
    Colin, Access MVP, Website, email
    The more I learn, the more I know I don't know. When I don't know, I keep quiet!
    If I don't know that I don't know, I don't know whether to answer

  11. #11
    CJ_London is online now VIP
    Windows 10 Access 2010 32bit
    Join Date
    Mar 2015
    Posts
    11,397
    to be clear, not all longs need to be changed - only those which are pointers - the guide Colin provided a link to will help. Hwnd for example is a pointer

  12. #12
    Roby-chan82 is offline Novice
    Windows 10 Access 2016
    Join Date
    Feb 2019
    Location
    Verona, Italy
    Posts
    9
    I went to the entire code of VB and added "PtrSafe" right after every "declare". Somehow it's working perfectly!!
    The whole job took me 15/20 minutes...
    Thanks!
    Roby

    Quote Originally Posted by isladogs View Post
    You've installed the 64-bit version of Access 2016 because that was the option you've selected.
    If you have no special reason for using 64-bit Access, I would uninstall and install the 32-bit version from the same source (CE or online)

    Otherwise if you want to keep 64-bit, the code below should allow it to work in both 32-bit & 64-bit:

    Code:
    #If VBA7 Then
    Private Declare PtrSafe Function ChooseFont Lib "comdlg32.dll" Alias "ChooseFontA" _
    (pChoosefont As FONTSTRUC) As Long
    Private Declare PtrSafeFunction GlobalLock Lib "kernel32" (ByVal hMem As LongPtr) As LongPtr
    Private Declare PtrSafeFunction GlobalAlloc Lib "kernel32" _
    (ByVal wFlags As Long, ByVal dwBytes As LongPtr) As LongPtr
    Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" _
    (hpvDest As Any, hpvSource As Any, ByVal cbCopy As LongPtr)
    Private Declare PtrSafeFunction GetDeviceCaps Lib "gdi32" _
    (ByVal hdc As LongPtr, ByVal nIndex As Long) As Long
    Private Declare PtrSafe Function GetDC Lib "user32" (ByVal hWnd As LongPtr) As LongPtr
    #Else
    Private Declare Function ChooseFont Lib "comdlg32.dll" Alias "ChooseFontA" _
    (pChoosefont As FONTSTRUC) As Long
    Private Declare Function GlobalLock Lib "kernel32" (ByVal hMem As Long) As Long
    Private Declare Function GlobalAlloc Lib "kernel32" _
    (ByVal wFlags As Long, ByVal dwBytes As Long) As Long
    Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" _
    (hpvDest As Any, hpvSource As Any, ByVal cbCopy As Long)
    Private Declare Function GetDeviceCaps Lib "gdi32" _
    (ByVal hdc As Long, ByVal nIndex As Long) As Long
    Private Declare Function GetDC Lib "user32" (ByVal hWnd As Long) As Long
    #End If
    If you only have 64-bit Access available, hold the shift key down whilst the open it in order to bypass the startup code

  13. #13
    isladogs's Avatar
    isladogs is offline MVP / VIP
    Windows 10 Access 2010 32bit
    Join Date
    Jan 2014
    Location
    Somerset, UK
    Posts
    5,954
    If you've only added PtrSafe then it may well compile but not necessarily work.
    You need to apply LongPtr to all Long values associated with pointers e.g. hWnd.

    The only way to know for certain that its now correct is to try code that depends on each API in turn
    Colin, Access MVP, Website, email
    The more I learn, the more I know I don't know. When I don't know, I keep quiet!
    If I don't know that I don't know, I don't know whether to answer

  14. #14
    Roby-chan82 is offline Novice
    Windows 10 Access 2016
    Join Date
    Feb 2019
    Location
    Verona, Italy
    Posts
    9

    I tried to paste the code for both 32 and 64 but!

    The DB was working perfectly, But I wanted to try your code.
    I made a copy of the original DB, and went through VB code, pasted yours (overwriting the same point), and it gives me back sentences in RED, which I suppose are wrong.
    Here is a screenshot:

    Click image for larger version. 

Name:	Cattura vb.jpg 
Views:	37 
Size:	192.5 KB 
ID:	37595

    I tried to hold shift down when opening, but the result is the same!
    What's wrong?
    Thank you...
    Roby

    UPDATE:
    Colin... I kept your code, but added here and there a few PtrSafe, and now the code is in Black and Blue.
    I saved, closed and re-opend and it works!
    Click image for larger version. 

Name:	Cattura vb 2.jpg 
Views:	38 
Size:	182.5 KB 
ID:	37596

    Let me know what you think, Colin!

    Quote Originally Posted by isladogs View Post
    You've installed the 64-bit version of Access 2016 because that was the option you've selected.
    If you have no special reason for using 64-bit Access, I would uninstall and install the 32-bit version from the same source (CE or online)

    Otherwise if you want to keep 64-bit, the code below should allow it to work in both 32-bit & 64-bit:

    Code:
    #If VBA7 Then
    Private Declare PtrSafe Function ChooseFont Lib "comdlg32.dll" Alias "ChooseFontA" _
    (pChoosefont As FONTSTRUC) As Long
    Private Declare PtrSafeFunction GlobalLock Lib "kernel32" (ByVal hMem As LongPtr) As LongPtr
    Private Declare PtrSafeFunction GlobalAlloc Lib "kernel32" _
    (ByVal wFlags As Long, ByVal dwBytes As LongPtr) As LongPtr
    Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" _
    (hpvDest As Any, hpvSource As Any, ByVal cbCopy As LongPtr)
    Private Declare PtrSafeFunction GetDeviceCaps Lib "gdi32" _
    (ByVal hdc As LongPtr, ByVal nIndex As Long) As Long
    Private Declare PtrSafe Function GetDC Lib "user32" (ByVal hWnd As LongPtr) As LongPtr
    #Else
    Private Declare Function ChooseFont Lib "comdlg32.dll" Alias "ChooseFontA" _
    (pChoosefont As FONTSTRUC) As Long
    Private Declare Function GlobalLock Lib "kernel32" (ByVal hMem As Long) As Long
    Private Declare Function GlobalAlloc Lib "kernel32" _
    (ByVal wFlags As Long, ByVal dwBytes As Long) As Long
    Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" _
    (hpvDest As Any, hpvSource As Any, ByVal cbCopy As Long)
    Private Declare Function GetDeviceCaps Lib "gdi32" _
    (ByVal hdc As Long, ByVal nIndex As Long) As Long
    Private Declare Function GetDC Lib "user32" (ByVal hWnd As Long) As Long
    #End If
    If you only have 64-bit Access available, hold the shift key down whilst the open it in order to bypass the startup code
    Last edited by Roby-chan82; 02-26-2019 at 05:02 AM. Reason: update solution

  15. #15
    isladogs's Avatar
    isladogs is offline MVP / VIP
    Windows 10 Access 2010 32bit
    Join Date
    Jan 2014
    Location
    Somerset, UK
    Posts
    5,954
    Its expected behaviour for the code in the #Else part to be in RED when run in 64-bit

    However having code in RED in the #If VBA7 part indicates errors
    a) CopyMemory - should start Private Declare PtrSafe Sub CopyMemory - you forgot PtrSafe
    b) GetDeviceCaps - should start Private Declare PtrSafe Function GetDeviceCaps - you forgot the space

    I'll leave you to check the rest of the code

    BTW - its easier for others to correct errors if you post the actual code rather than a screenshot
    Colin, Access MVP, Website, email
    The more I learn, the more I know I don't know. When I don't know, I keep quiet!
    If I don't know that I don't know, I don't know whether to answer

Page 1 of 2 12 LastLast
Please reply to this thread with any new information or opinions.

Similar Threads

  1. Difficult Query!
    By pastormcnabb in forum Queries
    Replies: 2
    Last Post: 04-09-2013, 09:40 PM
  2. Replies: 2
    Last Post: 04-09-2013, 07:42 PM
  3. difficult query
    By methis in forum Queries
    Replies: 2
    Last Post: 03-18-2013, 02:36 PM
  4. A Difficult One...(I Think)
    By NickyThorne1 in forum Access
    Replies: 0
    Last Post: 01-31-2009, 07:56 AM
  5. Difficult problem
    By francisca_carv in forum Access
    Replies: 0
    Last Post: 11-19-2008, 05:50 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Other Forums: Microsoft Office Forums