Maintenance of View V_DFKKCJM requires workbench request

[Former Member]

Hi everybody,

I have the following problem with maintenance of view V_DFKKCJM (tcd FPCJM): Changes are recorded in a workbench request and thus, the view can only be maintained in clients which are opened for repository changes. The view is client-specific, so from my point of view, a customizing request should be sufficient to transport the changes. I assumed that changes are recorded in a workbench request because the view has delivery class 'A' and the table maintenance dialog uses standard recording routine for changes. (transport of data from an application table usually leads to workbench request).

I changed the delivery class of the view V_DFKKCJM to 'C' and expected that now, changes should be recorded in a customizing request, but it doesn't work out - i'm still getting a workbench request. I've debugged the whole thing and noticed that in function module TR_CHECK_TYPE, before detemining the request type depending on delivery class, table OBJH is read and if an entry in this table is found for the current object, then the required request is type 'R' (workbench).

Does anybody know, what table OBJH is for and how I could solve this problem?

Thank you for any suggestions, Kathrin!

[christian_wohlfahrt]

Hi Kathrin!

I always thought, views are dictionary and cross client objects. I neither have the view nor the transaction in our (standard?) system, so I can't follow you.

Is your view accessible via SE11/views? Which objects are combined in this view? Doesn't sound like database tables (otherwise view would be cross client like the tables). Or is just the result, which is given by the view client dependent? Then maybe the view definition itself would be cross client.

Regards,

Christian

[Former Member]

Hi Christian.

Sorry for not being precise. The standard view V_DFKKCJM (IS-U CCS) is used for changing data in tables DFKKCJM and DFKKCJMT. I'm having troubles with the type of transport request that is required when changing data in this view (Using SM30). Standard is 'workbench'. I need it to be 'customizing' because we have multiple customizing clients for different companies, whereas repository changes / development is admitted only in one seperate development client. With the standard settings, I would have to open all the customizing clients for repository changes.

Any suggestions? Thank you and kind regards, Kathrin!

[christian_wohlfahrt]

Hi Kathrin!

Views are dictionary objects and they are cross client. You don't need to make changes in every client, just once in development client.

Changes will be immediately active in every client of same system, just give it a try.

Regards,

Christian

[Former Member]

Hi Christian.

I'm sorry, there's a misunderstanding: My problem is not connected to changing the definition of the view in data dictionary, but to entering values into the view. The view has a key field 'mandt', so values in the view are client specific. When saving the client specific value into the view, I have to specify a workbench request to save the entry. My problem is: How do I achieve that saving entries into the view will require a customizing request instead of a workbench request?

Thank you for any suggestions, regards, Kathrin!

[christian_wohlfahrt]

Hi Kathrin!

Sorry, I don't know how I could be so mislead all the time.

You checked the delivery class of the view, but what is the delivery class of the tables?

Regards,

Christian

[Former Member]

Hi Christian,

thanks for keeping at it g.

Originally, the delivery class was 'A'. I understand that for transport of application data, you would need a workbench request. That's why I changed the delivery class to 'C'. I assumed that with this change, I would only need a customizing request. Unfortunately I still get prompted for a workbench request. As I described before: When debugging the whole thing it appears to me that prior to taking into account the delivery class, table objh is checked to specify the type of needed transport request.

Any ideas?

Thanks for your help, regards, Kathrin!

[christian_wohlfahrt]

Hi Kathrin,

you might have noticed - I haven't had a look into a system up to now.

Now I searched a table with generated table maintenance. We just have one open client, but in our sandbox (without transports ) I made a small test: I'm asked for a customizing request. Our database table has the data class (technical settings) APPL2 - that's probably the only data class which leads to customizing requests. User(1) seems not to be classified and APPL0(1) seems to lead to workbench requests.

If you tell me the place of the request type determination, I will do a debugging, too. But currently I'm too far away of the interesting parts.

Regards,

Christian

[Former Member]

Hi,

I suppose that entries in table OBJH are created when table maintaince view is created and they are not updated when table settings are changed. If this is the case, you have two options: 1) recreate the view; 2) update OBJH with update sql.

Svetlin

[Former Member]

Hi Christian,

your answer has been very helpful, it brought me to think of the data category also instead of only delivery class. Thought it might interest you how it works in detail: In tcd SE54 (generate maintenance dialog) there's menu item 'environment -> Maintenance objects -> change' which will lead you to the 'object header data' of the view - which acutally is table OBJH that I encountered during debugging. (Views have no technical settings, but in OBJH a category can be specified also for views) Afer changing the category into 'CUST' it works perfectly well. Thank you so much for your help, regards, Kathrin!