Skip to main content
To homepage To homepage
Solved

Prod execution fails after changing names in a table in Dev

rbrandsma
Contributor
Forum|alt.badge.img

Hi!

Recently I have helped a customer upgrade their TX environment to version 20.10.66.64. With this upgrade it was advised to switch from an ODX setup to Business Units. So we recreated all datasources in the BUs and chose to set up just 1 BU for a datasource to service both Dev & Prod. 

Now the customer had to rename 2 column names in a table in the datawarehouse DSA on Dev. The next morning the execution package for Prod had halted with an error message stating there were 2 invalid column names. It could not find the 2 new columns. 

Performed a deploy on Prod and it ran normally. The next morning the Dev environment had not finished because of an error. There were 2 invalid column names, but this time the error message mentioned the old/original column names. 

We think the cause for this is in using only 1 BU for both Dev and Prod. And see 2 kinds of solutions

  1.  Use 2 BUs, which would result in
    1. Using 2x as much data storage
    2. Retrieving data from the original sources 2 times to retrieve the same dataset
  2. An extra layer between the Business Units and the DSA datawarehouse that is equal to the Business Units
    1. In that you would keep all the names the same as in the Business Unit which would prevent this issue, but you would have all data 3 times (once in the BU, once in the extra layer Dev, and once in Prod

Both of which aren't desirable because of the additional storage. The customer also refers to the ODX being a correct solution for this issue, where they did not have this. 

Can someone advise on this?

Best answer by rory.smith

Hi,

just use a separate Business Unit for each environment. External Business Units or a separate project for extraction should only be used in extreme circumstances. If you reuse one BU database for different TimeXtender environments, this will of course break things. A reason for having separate BU (or Ingest) for each environment is that this allows you to test changes to what you extract without affecting the other environment.

Storage is cheap, and you only need to refresh your development environment to reflect or test changes.

View original
Did this topic help you find an answer to your question?

4 replies

Thomas Lind
Community Manager
Forum|alt.badge.img+5
  • Thomas Lind
  • Community Manager
  • 1091 replies
  • May 27, 2025

Hi ​@rbrandsma 

Is the plan for the customer to eventually migrate to TDI (TimeXtender Data Integration) then there is no need to change to use a Business Unit for all your projects, it will be migrated to a Ingest (ODX) instance in there anyway.

A business unit is where the data sources used in a project is stored. Each project needs data sources set up, hence why you use global databases for your environments, so you don’t have to set them up many times.

If you have the same data sources in your projects, why would you have the same data then.

For a multiple environments development setup you should work on as close to real data as possible, so you know it will work once it runs on the real data, but you can make environment specific rules that limit the amount of data you have in each one.

rbrandsma
Contributor
Forum|alt.badge.img
  • rbrandsma
  • Author
  • Contributor
  • 13 replies
  • May 27, 2025

Hi ​@Thomas Lind, 

No, this customer wants to keep TX on-premises and eventually upgrade to the V25 version of Tx. 

Could it be we made a thinking error by having the dev and prod link to the same business unit in their respective environment? 

At this moment the global databases are configurated as below. 

dev: tx_bu_tableA

prod: tx_bu_tableA

Thomas Lind
Community Manager
Forum|alt.badge.img+5
  • Thomas Lind
  • Community Manager
  • 1091 replies
  • May 27, 2025

Hi ​@rbrandsma 

Yeah, I guess when you are used to the ODX this is what you would set up, but it should be one BU per project.

In some instances people would use the external business unit feature to add more data to an existing project, but I don’t see this as a good way to do this.

You need to set up environments with global databases and then do the full setup in dev and transfer it to prod. You generally do not schedule executions in the dev environment, so this is how it can be made to be smaller, but it will be hard to not have mostly the same data in both business units.

rbrandsma
1 person likes this
  • rbrandsma
    rbrandsma
rory.smith
TimeXtender Xpert
Forum|alt.badge.img+7
  • rory.smith
  • TimeXtender Xpert
  • 698 replies
  • Answer
  • May 27, 2025

Hi,

just use a separate Business Unit for each environment. External Business Units or a separate project for extraction should only be used in extreme circumstances. If you reuse one BU database for different TimeXtender environments, this will of course break things. A reason for having separate BU (or Ingest) for each environment is that this allows you to test changes to what you extract without affecting the other environment.

Storage is cheap, and you only need to refresh your development environment to reflect or test changes.

rbrandsma
1 person likes this
  • rbrandsma
    rbrandsma

Reply


Most helpful members this week

Terms and ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings