SPDD/SPAU

[former_member186741]

Guys,

we are applying some hotpacks after 2 years. SPAU is showing a lot more changes than is actually the case. A lot of objects are popping up on the list despite being no different from the version loaded by the upgrade. In some cases there are several versions of the code but they are infact identical, i.e. no changes have ever been done.

To solve this we can mark each one as 'reset to original' but we are a bit puzzled as to why so many are appearing on the list and would rather not work on objects which actually have not changed.

Is there any way we can reduce the workload to apply to 'actual' changes only?

Also, for the objects we really have changed from the standard, after choosing reset to original we need to reapply our code changes. We did one as a test of the procedure and found that sap asked us for object keys again. Is this normal?

[former_member186741]

Guys,

we are applying some hotpacks after 2 years. SPAU is showing a lot more changes than is actually the case. A lot of objects are popping up on the list despite being no different from the version loaded by the upgrade. In some cases there are several versions of the code but they are infact identical, i.e. no changes have ever been done.

To solve this we can mark each one as 'reset to original' but we are a bit puzzled as to why so many are appearing on the list and would rather not work on objects which actually have not changed.

Is there any way we can reduce the workload to apply to 'actual' changes only?

Also, for the objects we really have changed from the standard, after choosing reset to original we need to reapply our code changes. We did one as a test of the procedure and found that sap asked us for object keys again. Is this normal?

[Former Member]

I have seen developers get keys for an object, try something, have it not work, then back out the changes. The code still matches the original, but it was captured as a change. Not sure if this is the case or what you can do about it.

The object keys in table ADIRACCESS should be based on the release version, the installation number, and the object keys. Applying a hot pack should not require another key.... unless you are changing releases... or if the key in table ADIRACCESS was generated before an upgrade. Still, asking for a key does not sound right if the release is the same. You can check the key in ADIRACCESS and then go to the SAP Support Portal (OSS) and generate the key. See if they are the same.

[Former Member]

Neil ,

while doing the Adjustments , try to Import Standard Program then put ur code over there ? y bcos we dont know what are the new changes comes with new SP level . I havnt imported std.sap program and i maintained my programs itself due to that i am missing standard functionality which comes with new SP level.It may take lot of time but we have to Import Std.SAP.

Regards

Prabhu

[former_member186741]

there didn't seem to be a neat way to focus on 'real' changes.

[Former Member]

You should be able to see if things were changed using version management. I think that even if nothing was changed. If the versions are not the same as during the last upgrade or application of support packs, it'll probably be picked up in SPAU.

I think there may be some sort of time limit on how long you can edit an object after getting the developer key. I've made changes to an object and then later been asked to get it again. So I don't think this is unusual.

Rob