UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> Converting Access 07 To 2010, And 2013, Access 2007    
 
   
mmadani
post Nov 8 2018, 01:42 PM
Post#1



Posts: 355
Joined: 27-June 08



Friends;

I have written several access 2000 and 2007 Databases that I would like to convert to 2007 and 2013.

For an immediate task I need to convert my production 2007 database to 2013. when I attempted that by opening it with 2013 version. Several Code snippets and Form stopped working.

Several objects complained that functions (working) is unknown or not defined and will not work .


What is the best and fail proof way to convert my older database without any issues

I appreciate your time and help.


Please provide Screenshots and /or detailed explanation.

Sincerely;

Mike iconfused.gif
This post has been edited by mmadani: Nov 8 2018, 01:43 PM
Go to the top of the page
 
theDBguy
post Nov 8 2018, 01:55 PM
Post#2


Access Wiki and Forums Moderator
Posts: 73,751
Joined: 19-June 07
From: SunnySandyEggo


Hi Mike,

Just one person's humble opinion but the method you use to upgrade/convert an old database into a newer version is probably not a good indicator of whether it will succeed or fail. For example, if you gave me ten different databases and I convert them into 2013 by simply exporting all the objects into a blank database created using 2013, then it's quite possible all of them will work or none of them will work or some of them will work and some won't. So, although I used the same one technique to upgrade all ten, I cannot tell you it will work for all of them. I think it all depends on what you have to upgrade. There are basic methods you can start with, such as exporting the objects, but then the only way to make sure the upgraded version is flawless is to test it using the new version and fix any issues. It's also possible to fix an issue might mean using a different approach than what was used with the original database. For instance, if the old database was using an ActiveX Calendar control, then perhaps one way to fix it is to discard the ActiveX control and simply use the new built-in calendar control.

Hope it makes sense...

--------------------
Just my 2 cents... "And if I claim to be a wise man, it surely means that I don't know" - Kansas
Access Website | Access Blog | Email
Go to the top of the page
 
ranman256
post Nov 8 2018, 01:57 PM
Post#3



Posts: 883
Joined: 25-April 14



Ive never had a problem upgrading to a new db.
Tho you may have VB errors using 2007, 32 bit API calls in the modern 64bit OS.

use PtrSafe in all functions:
Declare PtrSafe Function MyMathFunc Lib "User32" (ByVal N As LongLong) As Long
This post has been edited by ranman256: Nov 8 2018, 01:58 PM
Go to the top of the page
 
BruceM
post Nov 8 2018, 02:52 PM
Post#4


UtterAccess VIP
Posts: 7,724
Joined: 24-May 10
From: Downeast Maine


I think that in Office 365 PtrSafe is required for all function declarations. Maybe this applies to other versions, but I don't know.

Along with that, LongPtr is needed for arguments that point to "handles", or memory locations (typically the variable name starts with h, as in hWnd, but best is to find the procedure documentation). This is because that location is 32 or 64 bit depending on whether Office is 32 or 64 bit. If you pass Long (32 bit) to a 64 bit handle (memory location), Access won't know what to do with it.

However, LongLong as shown in the brief example is for a 64 bit application only, I believe. It is a 64 bit value, so won't be usable in a 32 bit setup. I would want a very specific reason to use LongLong.
Go to the top of the page
 
mmadani
post Nov 8 2018, 11:07 PM
Post#5



Posts: 355
Joined: 27-June 08



Thank you All.

I am going to search for more info on that " PtrSafe " this is all new to me

I surely would like to experiment with some senarios.

Many thanks to you Friends

Mike uarulez2.gif
Go to the top of the page
 
isladogs
post Nov 9 2018, 03:33 AM
Post#6



Posts: 648
Joined: 4-June 18
From: Somerset, UK


PtrSafe and LongPtr are only needed for API declarations in 64-bit versions of Access whether you are using 2013, 2016 or 365.
You need to use conditional compilation if the database is needed in both 32-bit and 64-bit Access

Two of the best sources of information are https://codekabinett.com/page.php?Theme=5&a...tion-VBA-64-bit and https://docs.microsoft.com/en-gb/office/VBA...ations-overview
Go to the top of the page
 
JonSmith
post Nov 9 2018, 03:54 AM
Post#7



Posts: 3,956
Joined: 19-October 10



Its for reasons like this I always advocate not running ancient versions of software and dragging your heels to upgrade. Myself and others never really had much of an issue upgrading. Alot of that is likely due to making sure that we do small version upgrades more regularly.
I remember the calendar control active x issues, I remember mousehook scrolling issues. All are long dead and were manageable to solve at the time. Right now you could be dragging so much old deprecated stuff from 18 years ago it becomes a much bigger, harder task.

Obviously this isn't super useful right now because you can't go back in time, but more of a word of caution moving forwards.
I think at the very least stay within the versions that have official MS Support. At this point I would say 2010 should be the oldest version its safe or sensible to run.

JS
Go to the top of the page
 
BruceM
post Nov 9 2018, 07:54 AM
Post#8


UtterAccess VIP
Posts: 7,724
Joined: 24-May 10
From: Downeast Maine


QUOTE
Its for reasons like this I always advocate not running ancient versions of software and dragging your heels to upgrade

Agree, but unfortunately for many of us the decision is made at corporate IT, who often do not upgrade applications or OS on existing computers, but rather install the latest version for new computers. I am a little uneasy about Office 365, since updates can have unintended effects, but a big advantage is that everybody will have the same version. Until quite recently I had to maintain VBA7 conditional compilation because there were still some workstations running Office 2007.
QUOTE
PtrSafe and LongPtr are only needed for API declarations in 64-bit versions of Access whether you are using 2013, 2016 or 365.

I believe I was in error when I said LongPtr is needed for Office 365. As it happens, I have the 64 bit version (corporate's decision), so I received an error for API declarations that did not include PtrSafe and LongPtr. I incorrectly attributed this to the Office version rather than the fact that it is 64 bit. However, since 64-bit is being used more and more, I suppose on the theory that bigger is better, it is best to use PtrSafe and LongPtr.
QUOTE
You need to use conditional compilation if the database is needed in both 32-bit and 64-bit Access

This is not quite accurate. The linked article describes this, so I won't go into a lot of detail. Conditional compilation is needed if VBA 6 is being used (Office versions 2000 through 2007, I believe), in which case it is #If VBA 7 Then... and #Else for VBA 6. I am assuming no versions of Access prior to 2000. However, LongPtr is a clever thing in that it is a 32-bit integer (Long) in 32-bit applications, and a 64-bit integer in 64-bit applications. VBA 7 understands LongPtr, but VBA 6 does not. As long as there are no VBA 6 versions deployed, there is little need to declare separately for Win64. There are a very few functions where this is needed, though. Procedure documentation will provide the necessary information case by case.

As I understand, PtrSafe in the declaration means the pointer arguments such as hwnd, which indicate memory locations rather than literal values, will be handled correctly. I'm not sure I explained that quite right, but I got the general idea of the thing.

32-bit versions of newer Office releases will continue to work properly without PtrSafe and LongPtr, but since in most cases they will also work correctly with PtrSafe and LongPtr, routinely doing conditional Win64 compilation is not necessary. Rather, it needs to be done in the rare cases where it makes a difference. Again, the procedure documentation should be referenced.

It should be possible to use (for instance) hwnd As LongLong instead of hwnd as LongPtr, and do Win64 conditional compilation for all API declarations that use memory pointers (handles), but PtrSafe and LongPtr already solve that issue, so I will say again that routine Win64 conditional compilation is not needed.
Go to the top of the page
 
isladogs
post Nov 9 2018, 08:05 AM
Post#9



Posts: 648
Joined: 4-June 18
From: Somerset, UK


Hi Bruce

I 'll retract my previous comment & accept that its not always necessary to do conditional compilation.
I got into the habit of employing it when clients were using a mixture of versions from A2007 (32-bit only) through A2010 to A2016 (both 32-bit & 64-bit).
So I needed to check for VBA7 & Win64 separately

To handle all cases, I used the cumbersome but always reliable construct:
CODE
#If VB7 Then 'use PtrSafe
...
#ElseIf Win64 Then 'use PtrSafe & LongPtr
...
#Else '32-bit
...
#End If


Although very few clients still use A2007, I tend to just reuse API code that has worked well for years (until it goes wrong of course)
This post has been edited by isladogs: Nov 9 2018, 08:06 AM
Go to the top of the page
 
BruceM
post Nov 9 2018, 09:01 AM
Post#10


UtterAccess VIP
Posts: 7,724
Joined: 24-May 10
From: Downeast Maine


I just want to emphasize that LongPtr works properly with 32 and 64-bit versions of Office later than Office 2007. The Win64 condition is rarely needed.

#If VBA7 Then 'use PtrSafe & LongPtr
...
#ElseIf Win64 Then 'use if needed, but in most cases will be the same as for VBA7
...
#Else 'VBA6, assuming no versions of Office earlier than 2000
...
#End If

IMHO, the important thing is to know when the code is different for 32 and 64 bit, and when the argument or return value is a memory location (handle or pointer). A link within the link you posted describes it in good detail, with links to other sources.

Go to the top of the page
 
River59
post Nov 9 2018, 12:55 PM
Post#11



Posts: 1,410
Joined: 7-April 10
From: Detroit, MI


mmadani, the first thing that you should check are your references. Make sure you are using the correct ones.

--------------------
Remember ... Armstrong, Aldrin and Collins flew to the moon and back with a computer system less complex than a modern, programmable toaster ...
Go to the top of the page
 
BruceM
post Nov 9 2018, 01:20 PM
Post#12


UtterAccess VIP
Posts: 7,724
Joined: 24-May 10
From: Downeast Maine


I would just try converting a copy and see what happens. My experience is that references have been fine through various upgrades over the years, but sometimes code is incompatible. Of course, other people have had different experiences. There's no substitute for giving it a go.
Go to the top of the page
 
mmadani
post Nov 9 2018, 02:03 PM
Post#13



Posts: 355
Joined: 27-June 08



Thank you All for your time and wonderful information.

A stupid question here, I use the same version of the 2007 Database on several different computers (32 Bit and 64 Bit) . NO issues so far.

Going to 2013 32bit on a 64bit new laptop produced errors as : Undeclared, Undefined Etc.


Can anyone of you give me a Real full code on using the PTRsafe

Like here: what Should there be in the spaces under each case? :
___________________________________________________________________
#If VB7 Then 'use PtrSafe
...
#ElseIf Win64 Then 'use PtrSafe & LongPtr
...
#Else '32-bit
...
#End If
______________________________________________________________________
Go to the top of the page
 
theDBguy
post Nov 9 2018, 02:14 PM
Post#14


Access Wiki and Forums Moderator
Posts: 73,751
Joined: 19-June 07
From: SunnySandyEggo


Hi Mike,

You use PtrSafe on API calls. Take a look at the Wiki for some examples.

Cheers!

--------------------
Just my 2 cents... "And if I claim to be a wise man, it surely means that I don't know" - Kansas
Access Website | Access Blog | Email
Go to the top of the page
 
mmadani
post Nov 9 2018, 02:43 PM
Post#15



Posts: 355
Joined: 27-June 08



Thanks My Friend

Mike thanks.gif
Go to the top of the page
 
theDBguy
post Nov 9 2018, 03:12 PM
Post#16


Access Wiki and Forums Moderator
Posts: 73,751
Joined: 19-June 07
From: SunnySandyEggo


Hi Mike,

You're welcome. We're all happy to help. Good luck!

--------------------
Just my 2 cents... "And if I claim to be a wise man, it surely means that I don't know" - Kansas
Access Website | Access Blog | Email
Go to the top of the page
 
BruceM
post Nov 12 2018, 07:34 AM
Post#17


UtterAccess VIP
Posts: 7,724
Joined: 24-May 10
From: Downeast Maine


PtrSafe will cause an error in pre-VBA7 environments such as Office 2007 and earlier. PtrSafe should work properly in any VBA 7 environment. In rare cases, as described in documentation for the specific API, the Win64 conditonal constraint is needed.
Go to the top of the page
 
JonSmith
post Nov 12 2018, 09:58 AM
Post#18



Posts: 3,956
Joined: 19-October 10



QUOTE
A stupid question here, I use the same version of the 2007 Database on several different computers (32 Bit and 64 Bit) . NO issues so far.


Just to clarify, the bit of Windows is not relevant to the VBA code. The bit of Office is relevant, the machine might be running Windows 64 bit and Office 32 bit.

Only pay attention to what the Office Version is and disregard the Windows version.

JS
Go to the top of the page
 
mmadani
post Nov 15 2018, 10:20 PM
Post#19



Posts: 355
Joined: 27-June 08



Thank you Jon.

Great Answer notworthy.gif

Mike
Go to the top of the page
 


Custom Search


RSSSearch   Top   Lo-Fi    19th November 2018 - 12:18 AM