We’re trying to determine the best upgrade path from TDP 3.8 32-bit, to TSP 4.2 64-bit, while keeping the user’s settings as they were.
I personally do not have control over the installer, it is done via MSI, and executed by our packaging group guy, for rollout to many machines in enterprise. I am testing it now, and hitting some issues.
- If he installs 4.2 64-bit, it is not recognized as an upgrade, and so none of my prior settings are migrated (connections, UI settings , etc.) We’ve tried manually forcing it, but still nothing is migrated.
- If he installs 4.2 32-bit, then I get the migration popups and warnings, as expected,and my customizations are brought over.
Is going from 3.8 32-bit to 4.2 64-bit a valid migration path?
If not, is there any recommended best practice for how to end up at 4.2 64-bit while keeping my 3.8 settings? That’s what we need to do, but can’t see how yet.
Thanks!
Page 23 of the Install Guide explains the upgrade process. You may need to backup the old Application Data folder and then restore is after you install the new version. You can have both versions running side-by-side it that helps.
Install the 64-bit, make sure it works, then uninstall the 32-bit version.
We tried the app data folder approach, but it never gives us the option to migrate settings.
It seems the ONLY thing we get is side-by-side install, which is not what we want. We just want 4.2 to install on top of 3.8, preserving the 3.8 user customizations.
The 4.2 version works fine, but just doesn’t carry the settings - that is our stumbling point,and the doc is not clear on that.
This should not be the case. I just tested the upgrade path of TDP 4.2 64-bit and in the list of settings to migrate I get all past TDP versions and most of these are 32-bit. See pic.
That has been my experience as well but since they are pushing the upgrade out I am wondering if they have left something out of the process and may need to restore the apps directory.
Hmm… that is interesting. we have been trying many variations, i will try to summarize a few key results here
(these are all on a VM so we can revert snapshots back to starting point )
Step0: install 3.8, customize it & exercise some basic features. (snapshot) (this would be how a end user’s machine would appear)
-
Install 4.2 64bit, using MSI with a MST for license. It gets a side-by-side install, totally unaware of 3.8 settings. Launch 4.2 - it looks like a fresh install. No settings were migrated.
-
revert to step0, then install 4.2 32-bit, using MSI with a MST for license. This time when I launch 4.2, it goes thru the migration as documented. It all seems fine. but I don’t want 32-bit 4.2 - this test only proves the migration works.
-
revert to step0, uninstall 3.8 manually, (however this keeps the app-data dirs), install 4.2 - it behaves like test1 above. We tried renaming the dir to OLD and so on, as described in docs, but still does not migrate settings.
Are we missing some obvious step? Or, is using the MSI installer the problem? He uses some MST thing ( I don’t know this part) so as to copy over the license transparently.
To me, I’d rather have to re-apply the license manually, than lose all my settings. If that the option we end up with.
Thanks for quick replies!!
I think the MST package might be the issue. I would try the scenario without bundling the license.
OK I can take that back to the packaging guy. Let me see what he says.
Is there some other mechanism to bring the license over afterwards?
I suspect that it can be written to the registry and picked up there. But I am not fully sure. You might want to open a support case to get more details on this possibility
Thanks, the packaging guy had this in email this morning, after I suggested trying without the MST as you mention above.
Tried the install without adding the license key – that work, it migrated the data.
no clue why- so I am looking into a different way to license it without having user do this – they don’t want 800 people calling help desk to do license
I’ll let you know if I come up with anything
Question- if we already have a licensed 3.8, does the license not just move over to 4.2 when upgraded? I don’t see why we have to fuss with the license at all during an upgrade.
I will get in touch with him and see what we can figure out. If we need to open a support ticket we can look into that.
Thanks!
You are correct. If you already had a license you will still have a license when you upgrade to 4.2,
HI - just to close this out… we found a way to get it to work
From our packaging guy - seems the way he was doing it so the license got migrated, was interfering with real migration. We’ve got it working now, and can proceed with upgrades.
"In testing it was determined that putting the settings.xml file into user roaming section at install time will not allow the data to be migrated. The previous version of Toad needs to remain on the system as well in order for the migration to happen. The settings.xml file was being installed to disable the check for updates, since the previous version of Toad also had this checked disabled, when it migrates the user data from Toad 3.8 to this version it will have that setting unchecked. In testing it was found that the migration will not migrate all of the user settings and is possible they will need to reset up some of their preferences, especially if they changed the look of the app on screen. The migration process was tested by using Toad 3.8 that was installed on system. "
thanks for the tips
Glad to hear this is working[8-|]