Skip to main content
To homepage To homepage
Solved

Renaming a table breaks related tables

  • February 14, 2025
  • 8 replies
  • 88 views
R
Contributor
  • RLB
  • Contributor
  • 75 replies

I have a table (table A) with a lookup field from table B (using the default relation between A and B). This works fine.

Table B is then renamed because of a spelling error, deployed and executed. Good.

Table A still seems to be OK: the relationship between A and B looks fine and the data cleansing procedure (Advanced -> Customize Code -> Data Cleansing Procedure) contains table B with its newly updated name.

However, table A won't execute because the deployed version of the data cleansing procedure still references table B's old name.

The simple fix is to force a deployment of table A, but I think TimeXtender should have noticed that a deployment was needed (red table name). Seems like a bug to me.

Legacy version 20.10.50.64

Details:
    
    SQL Server: 'my-mdw-database.example.com'
    SQL Procedure: 'MDW_TR.usp_table_A_Clean'
    SQL Line Number: 65
    SQL Error Number: 208
    
    Invalid object name 'MDW.table_B_old_name'.

Best answer by Christian Hauggaard

​@RLB thanks for this feedback. I have reproduced the issue you describe and have passed it onto the product team. I will go ahead and close this, please refer to the product updates for a future fix

https://support.timextender.com/product-updates

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

    8 replies

    Thomas Lind
    Community Manager
    Forum|alt.badge.img+5
    • Thomas Lind
    • Community Manager
    • 1017 replies
    • February 14, 2025

    Hi ​@RLB 

    What settings were you using for this deployment?

     

    R
    Contributor
    • RLB
    • Author
    • Contributor
    • 75 replies
    • February 18, 2025

    Hi Thomas,

    I think I deployed the project (Tools > Deploy and Execute Project) using these settings:

     

     

    Table A had not been marked as modified so it was not deployed automatically. 

    Thomas Lind
    Community Manager
    Forum|alt.badge.img+5
    • Thomas Lind
    • Community Manager
    • 1017 replies
    • February 18, 2025

    Hi ​@RLB 

    I made a gif.

    As you see, when I change the name both table gets marked as red. That it doesn’t deploy or suggest to deploy the other table is a deliberate choice, so you can deploy it when you want. The other table is still shown as “dirty” you can see that when you execute it it can have issues.

    What you should always do when changing lookup field values is to use the deploy Only modified tables and views option. Then it will use the relations to pull in all the necessary tables and only execute those.

     

    R
    Contributor
    • RLB
    • Author
    • Contributor
    • 75 replies
    • February 20, 2025

    Interesting, thanks. What your gif shows is exactly what I expected to see. I am 100% sure my table was not marked as dirty. Perhaps this was fixed in TimeXtender Data Integration? I'm using the legacy version.

    I'll try to reproduce the issue.

    Only modified tables an views was in fact selected.

    Thomas Lind
    Community Manager
    Forum|alt.badge.img+5
    • Thomas Lind
    • Community Manager
    • 1017 replies
    • February 21, 2025

    Hi ​@RLB 

    If you do this in 20.10.50 you can make a similar gif. I use a program called screenpresso as you may see in the lower corner.

    I did it in 20.10.57 and it seems to have the same behavior there.

     

    R
    Contributor
    • RLB
    • Author
    • Contributor
    • 75 replies
    • February 24, 2025

     

    Hi Thomas,

    Sorry, no GIF but a few screenshots :)

    1) Table A (RLB_Categories) is working fine. Table B is called RLB_Category_names:

     

     

    2) Table B is now renamed RLB_Category_names_RENAMED. Yes, it's been marked dirty as expected. Table A shows the updated table name under Relations. However, table A is NOT marked dirty!

     

     

    The project is then deployed (modified tables, as shown earlier).

    3) Table A's data cleansing procedure does show the updated table name:

     

     

    4) But obviously it doesn't work:

     

     

    5) Forcing a deploy of table A fixes this:

     

     

    Perhaps it's been fixed between 20.10.50 and 20.10.57 but it's not included in the release notes.

    R
    Contributor
    • RLB
    • Author
    • Contributor
    • 75 replies
    • February 25, 2025

    Ah, you renamed the field, I renamed the table.

    Renaming the field that is referenced in the lookup does indeed mark both tables dirty. Renaming the table does not.

    Christian Hauggaard
    Community Manager
    Forum|alt.badge.img+5

    ​@RLB thanks for this feedback. I have reproduced the issue you describe and have passed it onto the product team. I will go ahead and close this, please refer to the product updates for a future fix

    https://support.timextender.com/product-updates

    R
    1 person likes this

    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