+7
At one of our customers we have a separate cloud for testing software / infrastructure changes. We are running 20.10.35 and want to evaluate 20.10.40. I would like to be able to upgrade the ODX Cloud repository for only one of the projects/environments instead of upgrading both to 20.10.40 and needing to risk production issues. Is this possble / can this be requested?
Best answer by Christian Hauggaard
View originalHi Rory,
Internal testing by my colleagues shows this combination (partial upgrade) may work OK.
However, for some other combinations of TX and ODX versions, there may be issues when there are changes in client API version.
+7
Hi Syed,
so just to reiterate I should be able to:
I have experienced that the other way around: TimeXtender 20.10.40 connecting to ODX Server 20.10.35 does not work due to an API version mismatch.
+5
Also, if you wanted to test not only the ODX but also the TimeXtender projects in 20.10.40, then please take into account that upgrading the TX repository is irreversible, so we recommend using a copy/backup of the TX repository in this case
+7
Hi
thanks - as we have a completely mirrored infrastructure with its own repository database this is/should not be a problem.
+5
+1
Hi
Would the corresponding scenario be possible with version 6xxx. Two sets of ODX, MDW and SSL on two separate application servers, as long as we don’t try to open an instance on the “wrong” server or copy between the versions?
BR
Anders
+7
I have tested this in our environment: ODX Server 20.10.40 , a TimeXtender 20.10.35 cannot connect due to client API mismatch:
Is there any workaround for this? As a worst-case a new license number and manual copy of the cloud repository database on your end might work, but I would prefer some more friendly solution as reverting in case of breakage would also require you to (quickly) restore a backup of the cloud repository.
+5
+7
and that is exactly our problem. On Prod we are running ODX Server and TX 20.10.35 - I am evaluating 20.10.40 in a separate infrastructure to ensure there are no surprises. Having to snapshot everything and wait for you to restore a cloud repository to 20.10.35 would make it difficult to upgrade given that we do not want to risk a disturbance to the business.
+5
OK to clarify you want to keep everything the same in production (ODX 20.10.35 and TX 20.10.35), while testing on a separate infrastructure - installing ODX 20.10.40 and TX 20.10.40 for a different ODX project/environment and a separate TX repository than the one in production. Then once you are done testing and ready to upgrade, you upgrade to ODX 20.10.40 and TX 20.10.40 in production. Is this correctly understood?
I do not believe there is a workaround to get ODX 20.10.40 to work with the 20.10.35 Desktop app. Also, we do not currently support reverting to a prior ODX version once you have upgraded. Please feel free to submit this in the ideas section.
+7
alright - so the current upgrade path for 20.10.x with ODX Server has no fallback for surprises? Given that I am using Theobald DeltaQ over SSIS here, I do not really want to break things. Can I then request a separate “license” and a copy of the remote repository database to the new database for the new “license”?
+5
Correct, there are currently no fallback/revert possibilities. Since there is currently no copy feature for ODX projects/environments in 20.10.x, I suggest setting up and testing the DeltaQ data source in a separate separate ODX project before upgrading the production ODX project
+7
+5
Based on our testing upgrading one ODX project in an ODX environment, while not upgrading the other ODX projects in the same ODX environment, may work OK. Again, I strongly recommend that you test this your own Sandbox environment with the specific versions that you are planning to upgrade from/to (20.10.35 and 20.10.40)
+7
Hi all,
upgrading the sandbox ODX environment to 20.10.40 has not affected the production ODX environment running on 2.10.35.
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
