cancel
Showing results for 
Search instead for 
Did you mean: 

TDMS for refresh DEV system

Former Member
0 Kudos

Hi,

Does anybody have experience with refreshing a DEV system using TDMS?

Our DEV system consists of 2 clients, One used by programmers with no data in it, and a second client with some transactional data for performing the first tests before something is transported to QAS.

The repository of a DEV system will never be the same as on a production system (people are programming simultaneously), so the scenario I had in mind was to create the DEV system as a shell from the production system, create 2 clients and use a TIM for the second client.

But then all the program specific data which is stored in DEV gets lost (e.g. program versioning).

Does anyone know how to keep this data?

Kind regards,

Nicolas

Accepted Solutions (0)

Answers (1)

Answers (1)

former_member182566
Active Contributor
0 Kudos

Hi Nicolas,

I think that you are worrying too much that the repository is not exactly the same between DEV and PRD. The program versions will not be the same in the two systems, but that will not be a problem for TDMS.

You sould try to minimize pending dictionary changes in Z tables (by transport them to the the sender system if possible). This will minimize problems when copying those Z tables. Apart from that I don't think you should worry; you should forget the shell creation if the receiver system is part of your landscape and not a completely separate environment.

Rui Dantas

Former Member
0 Kudos

Hey Rui,

Thanks for your reply!

The thing is that our DEV system has not been refreshed in the last 5 years, so chances really are that a couple of things will be different.

It's not just about importing the remaining transport requests, but I can imagine that some requests have been deleted in DEV, even though the changes still exist.

What happens when TDMS tries to update a table of which the version is different in the sender and receiver? e.g. the receiver has one extra field?

When this happens, it's probably already too late to roll back as the data in the receiver has already been deleted.

Kind regards,

Nicolas

Former Member
0 Kudos

Hello

Their are some main concerns before a TDMS TDTIM transfer can be done, these are -

1) The table whose data is to be transfered from sender system to receiver system should exist in both the system.

2) Key fields should be exactly identical.

3) Their may be some extra fields in the receiver, this will not pose any issue but if their is an extra field in sender then its data could not be transferred. So to solve this either mark this table as not use or change the table in receiver to add the missing field.

As a part of TDTIM both the system will be analyzed for consistent repository and any discrepancy will be notified to the user then user needs to decide whether he marks the inconsistent table for no transfer or corrects the inconsistency before proceeding further.

Best regards,