Cross Server Conflict

[Former Member]

we make a change to a Z-table, let's say increase the lenght of a field from 10 to 20.we tranposrt that object (ztable) to QA.then we create a program where we will use this table, and the field that is now 20 CHAR long.we test it in D, it works.ten we tranport it in QA.works fine.then we transport it in P (don't forget our ZTABLE modification from 10 to 20 is still in QA, so in P our ZTABLE-field is 10).and our program tries to populate that field with a value that's 20 long.dump.....now we want to prevent this, but SPRO_ADMIN does not take data declarations in account.

CAN WE COPE WITH THIS SITUATION.

If so how

[Former Member]

we make a change to a Z-table, let's say increase the lenght of a field from 10 to 20.we tranposrt that object (ztable) to QA.then we create a program where we will use this table, and the field that is now 20 CHAR long.we test it in D, it works.ten we tranport it in QA.works fine.then we transport it in P (don't forget our ZTABLE modification from 10 to 20 is still in QA, so in P our ZTABLE-field is 10).and our program tries to populate that field with a value that's 20 long.dump.....now we want to prevent this, but SPRO_ADMIN does not take data declarations in account.

CAN WE COPE WITH THIS SITUATION.

If so how

[Former Member]

Why don't you move your transport with the changes to the Z table into production?! Or add logic to your program to check the length of the value for the field in question and stop the update if it is over 10?

Doesn't sound too complicated...

Gareth.

[Former Member]

see the client is having a serious quality problem right now and we are trying to cope with it.so is there a concrete way to stop that

[Former Member]

Do you mean the client is having lots and lots of problems in production because of the difference in field lengths with your Z table and program?

In that case, someone has to take responsibilty for mixing up the Z table and program and put in a fix. Probably the best thing is to add extra logic to teh program and transport that through as that will likely be quicker to manage from a code and transport perspective compared to changing the table.

Is there any reason why you can't move the Z table changes through to Prod?

Gareth.

[Former Member]

Thanx for your answer.That is a way.But when we do that through the SPRO_ADMIN it doesnt give any error as it doesnt look for the data dependency.....whats the reason behind that

[Former Member]

Hi,

I'm not 100% sure what you mean. Have you tried to transport the changed Z table into production so the program can work?

Gareth.