Change Table Name In IDT

[former_member385171]

Hi All,

     I have a IDT Project consist of a Connection, a Data Foundation, a Business Layer builded on a schema (Schema 1). I want to use same structure(IDT Project) for my another schema(Schema 2) which includes tables which names are slightly changed from names in Schema 1.

      In IDT 4.0  when I have changed connection and pointed it to new Schema 2. When I am renaming table in Data Foundation that change is reflecting in Business Layer but not in Joins.

     When I am Replacing Existing table With table in Database (Schema 2) It is reflecting in Joins but not in Business Layer.

     I have tried this thing in UDT so when I change my Table name it is reflecting both in Join as Well as Object definition.   

     How can I do this in IDT 4.0???

Thanks In Advanced.

[Former Member]

Hi

The new table maintains the joins if the same keys/columns are available.

You change the Schema (say DEV to PRD) and the schema wont change in the Joins...or the Objects...

http://scn.sap.com/thread/3346718

When you use a derived table those tables don’t really have owner names since they exist only in the universe. But they do reference tables in the database, and as discussed above, they will include the schema or owner name. In order to migrate derived tables correctly, I had to open each one and update the SQL manually. This was a problem.

The main issue is that I was changing the code during a migration. That means that a bug could be introduced. And introducing bugs during a migration (after system testing has been completed) is not a popular result.

So what I did to solve this issue at first was to create an Excel spreadsheet that contained the SQL code required for each derived table. I created formulas where the schema name was a reference to a single cell in the sheet. To migrate a universe I would open this XLS, update the schema name in one place, and see that schema name updated in each different SQL statement. It becomes a simple copy / paste operation during the migration rather than an “edit” operation. This was certainly safer, because the code itself was verified and the only thing that was being updated was the schema name. But there were still problems.

For example, at one point we had someone new join our team, and their video resolution was smaller than mine. What does the video setting have to do with this? Smart question. The issue was on my screen I would see seven derived table definitions. On their screen, because it was smaller, they only sawfive. That meant when they processed the instructions in the spreadsheet they only updated five of the seven derived tables, with the net result being we got code in production that was not working.

Message was edited by: Naveen Kumar