cancel
Showing results for 
Search instead for 
Did you mean: 

Problem with SCC1

Former Member
0 Kudos

Hi All,

Its ECC 6.0 on HP-UNIX and oracle 10g

I have client 100,200 ,300 and 400

Now whn I import any request frm client 100 to 200 using SCC1 its gets imported in all the clients.

Any idea why it is hapenning ????

Regards

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Why you are assuming that request has imported into all the avaialble clients?

by watching request no in all the clients.......you can see the request no in any client in one system it doesn't mean that request has imported into all the clients.

If it is an actual situation just check the first screen of SCC1...there target client should be your optional(not * or not in disable mode).

Regards,

Nick Loy

volker_borowski2
Active Contributor
0 Kudos

Hi,

Nick is correct. The transportrequest itself is clientindependent

and therefore the request it is visible in all clients. In general there is a restriction,

that a request can only be modified in the client where it has been created,

but there are options inside the transport tools to change that.

But: SCC1 is NOT considered to be a transport, because it can

be used on OPEN requests. This means, whatever you do with

SCC1 does not ensure a consistent and reproducable status.

It will always do a select on the source tables at the time of

the SCC1 execution, no matter if the request is still open or

has been released three years ago (in this case, the result will

most likely have nothing to do with the content of the trasportdatafile

that has been exported three years ago).

A valid purpose to use SCC1 is to pre-test customizing transports

that are to be released soon. I.E in a scenario like

DEV-100 : customizing master

DEV-200 : customizing pre-test

QAS-100 : QA master

You can SCC1 your open transport again and again from

DEV-100 to DEV-200 until the result satisfies. Then you release it

and import it to DEV-200 AND QAS-100 and never use SCC1

with this request again.

Volker

Former Member
0 Kudos

Hi Volker,

Yes, Nick has made right pt that Request no. will be visible is all the clients on same H/W.

Infact my client was in assumption that its being copied is all the clients whereas its just the presence(as said by Nike)

I was aware of this fact but it didnt strike me when my client explained the problem and later I realised it after going thru Nike's statement.

Anyway many thansk to all involved-in.

Regards

Answers (3)

Answers (3)

Former Member
0 Kudos

No need to import cross-client/workbench request into other clients in same system---This is fine

but for better understanding paste the logs of SCC1 and also recheck the same from your side too.

Regards

Nick Loy

Former Member
0 Kudos

Do you have a scheduled import at the STMS level? Have you checked the logs within SCC1?

Like Eric mentioned, if you are transporting workbench requests then objects are already in 200.

J. Haynes

Former Member
0 Kudos

This is customizing object and tht is the worry. Had it been cross client or workbench we dnt hav to use SCC1 for same system

Regards

former_member204746
Active Contributor
0 Kudos

customizing objects are not transported in a client copy (or SCC1).

Why? They do not contain the MANDT field

So, no problems here.

Former Member
0 Kudos

Nick : SCC1 log just says copied succesully.

Eric : I think SCC1 is actually meant for copying customizing request on same server in different client.

And in my case I think when we run SCC1, it replects req. no. in all the available clients but the effect only takes place in the target client. ( Im not sure but I think so)

Wht you say Eric ????

former_member204746
Active Contributor
0 Kudos

you are right, I made a brain ****!

you can transport customizing across client. This is expected.

What I really meant: you should not transport workbench across clients.

sorry for that.

former_member204746
Active Contributor
0 Kudos

if your transport contains client INdependant objects, this is completely normal...