Hi @Paul McLeod Bespoke Analytics 

That is odd.

How is the environments set up?

Hi Thomas,

There are 3 environments DEV UAT PRD, 2 ODX’s one in DEV and one in PRD.

Originally I had the 2 ODXs not assigned to any Environment which created the same effect, I then assigned them to Environments and had the same result.

This Datawarehouse instance had just been migrated from V20, but I had mitigated any migration issues and had managed to deploy and execute the instance successfully.

There is only one ODX being used to source the load, but I did have two separate tables from the same ODX instance mapped originally to most of the tables (Prod and UAT source data), which worked fine in V20 and in the V21 execution. I am not sure if having 2 tables mapped caused some crossed wires in the migration or not.

I have tried removing the UAT table mappings (all still in the same ODX instance in V21) but it has not made a difference. My next step is to delete the V21 instance and try to convert it again but with only one set of tables mapped from the V20 ODX in the source V20 project.

Here is a screen grab from the V21 Portal’s environments view.

Hi @Paul McLeod Bespoke Analytics 

Wait a bit with deleting stuff and redoing the migration.

Try to create a new ODX instance with one data source. Create two environments and see if you can copy the ODX without getting doubles when excluding the migrated one.

Hey Thomas,

I do have another V20 project that has a DataWarehouse and does not have any double mappings from the V20 ODX to tables. When I try to transfer that migrated project to the QA instance I do not get a duplicate request to map the production ODX.

Its ok I am happy to delete the instance and move on. I am on a deadline for the client so I kind of want to find a solution and complete the migration.

I am going to test the transfer of the other Data Warehouse instance first to verify I have no other issues before I delete and reload the problem Data Warehouse.

Paul.

I might also just create a new Data Warehouse instance and migrate the V20 project to that one without the double mapping to verify the difference in the behavior.

I did also have an issue with the transfer of a semantic model where the migration tool mapped the wrong schema name for the source table. Everything looks ok in the desktop app, you can change fields, add them etc from the source table. but on execution it was giving errors because the schema was wrong. I had to fix that by deleting the source table from the cube, close and reopen the Data Warehouse and Semantic model instances and then remap the source table to the semantic model and it worked fine…

A few kinks still to work out. But still a great help in the transfer

How does it look in V20 when you have two mappings to an ODX? Just to see if can replicate it on my end.

Hey Thomas,

So removing the second table mapping in V20 removed the issue. Something funny going on with the migration tool I suspect.

What we have in V20 is 2 separate ODX sources from the same source system. One source is the UAT system, one source is the Prod system. Both are REST.

We are simply mapping all the TimeXtender DW Instance tables to both sets of tables from the 2 ODX sources and have an additional field “Environment” that allows us to switch back and forth between the UAT or Production data.

As an example, we have a “Companies” table in the V20 DW and its fields are mapped to the “Companies” table in the Production ODX source as well as the UAT ODX source. Nothing really complex going on regarding transformations, a few lookups is all. Very simple solution.

You can consider this closed for me; I don’t need any additional support to solve the issue.

Good, I set your latest reply as the answer.

I will attempt to replicate it and make it an internal case if necessary.