In article <
ea5bbad3-e707-4ad4...@googlegroups.com>, Keith
Tizzard wrote...
>
> I am not able to provide a full answer although I have progressively updated databases from early versions of Access to Office 365 over a number of years.
>
> One feature that you should be aware of is the use of 32 bit library functions. You will need to add the keyword 'PtrSafe' e.g.
>
> Private Declare PtrSafe Function RegOpenKey Lib "advapi32" Alias "RegOpenKeyA" _
> (ByVal hKey As Long, ByVal lpValueName As String, phkResult As Long) As Long
>
> Look at the article:
>
>
https://docs.microsoft.com/en-us/office/vba/language/reference/user-interface-help/ptrsafe-keyword
>
> Good luck
>
>
> On Saturday, 2 July 2022 at 14:53:24 UTC+1, Philip Herlihy wrote:
> > I figure the time is right to move to 64-bit versions of most things, including
> > my new Office 365 installation.
> >
> > I have some (crucial!) databases built years ago in Access 2013, which use
> > linked tables, so it's the "application" part I'm wary of wrecking. I can find
> > guidance on updating the VBA, but what about forms and reports?
> >
...
> >
> >
> >
> > Phil, London
Thanks, Keith. I was just returning here to report on progress. I did find
references to the PtrSafe qualifier in three YouTube videos on the subject
(though the other aspects I was concerned about weren't mentioned).
On a machine with 32-bit Office I copied files to a "Test" folder, and re-
linked them. I installed Office 365 (64-bit) on a new machine, and shared
copies of the files via OneDrive**. Everything just worked on the new machine
(to my surprise). Now, I'm not using any external controls or add-ins, so
there are no "Declare" statements in my code. 64-bit Access seems to have
everything needed for my code out-of-the-box. I still have some testing to do
before I start using it for live data, but it looks good - and has been much
less trouble than expected!
It remains to be seen whether I can work with the same data on machines with
different 'bitness' versions of Access installed, given the database was
developed on a 32-bit machine.
**OneDrive has an annoying habit of creating the local (synchronised) folder
with different %USERNAME%s on each machine despite using an identical Microsoft
Account. On my desktop the %ONEDRIVE% path is C:\Users\xyz_000, giving a
OneDrive path of C:\Users\xyz_000\OneDrive, while on the new machine it's C:
\Users\xyz and c:\Users\xyz\OneDrive respectively. So the linking (via Linked
Table Manager)done on one machine isn't valid for the other. I solved this
with a Junction Point (mklink /J xyz xyz_000) which creates an equivalent path
to the files on the new machine. (Note that OneDrive synchronisation is WAY
too slow to use for sharing a database between users.)
--
Phil, London