topic Re: Why use data elements for ztables? in Application Development and Automation Discussions

Why use data elements for ztables?

Former Member — Sun, 19 Jul 2009 09:12:26 GMT

Hi friends,

I have created a ztable in that i have created some fields without refering to data element ie : i have used pre defined types for that...

But i have come to know that there are some disadvantages when we create teh fields without refereing to data element..

now after searching in the form i got the below dis advantages......

1. Table to table relation is not possible

( what exactly does this mean )

2. This table data created under the client, this can be accessed by any other client, table can't client dependent table.

( I dont think so this is correct ie : if i give a MANDT field with data types manually in the prdefined type which are same in the data element then i hope it can be a client dependent table..... AM I CORRECT...? )

3. Table data can be accessed by apps using search helps.

( what exactly does it mean )

4. table data can't transfer from current R/3 to remote R/3. using Idocs.

( I dont think so this is correct ie : if similar table in there remote system to which i am sending the data then i can write a custom idoc to send the data using idocs ..... AM I CORRECT....? )

Can any expert tell this... ( Rich expecting your view this )

Regards

Satish Kumar Boguda

Edited by: Julius Bussche on Jul 20, 2009 1:10 AM

Please use meaningfull subject titles

Re: Why use data elements for ztables?

MarcinPciak — Sun, 19 Jul 2009 12:40:34 GMT

Hi,

1) tables are related using FOREIGN KEY relationship. This meas that for table2 (foreign table) only existing entries from table1 (primary tabe) are allowed for certain field. This, hoewever, requires that for that field in both tables, domain must stay the same. If you are not using data elements for typing this field, you also resign from domain which could describe this data element. As a result tables cannot be connected using this field (as domain equality is not fulfilled for both of them)

2) MANDT field must be explicitly named like that and probably typed because it is used internally by OPEN SQL when you access the table without CLIENT SPECIFIED addition. It simply must be recognized by ABAP that this field don't have to be listed as source,target and query field. The system takes care of that automaticaly. That's why, I think, it must be named this way and also typed via specific data element.

3) Search help (extended input help with its dialog behaviour etc) can be constructred based on data element . This means that you can later have input help for all the field refering that data element. Search help can also be attached to table field, screen field, table etc. The crucial is that parameters of such search help must be typed (and only like this) using data element.

4) Here this can be somehow connected to iDoc segments, where all fields are typed with data element. Using same typing might not be sufficient as domain introduce value range. I.e. you could be providing field value which is out of range (this is also applicable to above menthoned table relationship).

Generally try to type your fields using data element whenever possible and you suspect that this field can be somehow related or referenced via another field somewhere else. Also, it always provides consistency for all these fields once data element changes.

Regards

Marcin

Re: Why use data elements for ztables?

Former Member — Sun, 19 Jul 2009 23:09:49 GMT

Thanks for using the search...

In addition to Marcin's answer, you might want to consider using the same Package (formerly Development Class) for your ztables for an application development and type them and create APIs for them if they have relationships and use the same domains for the value ranges. That way there is less confusion...

When you access other tables via these APIs or other programs access yours, they will always experience the same behaviour if they respect your data and use the same typed parameters.

You can then also maintain your tables and the API coding, without necessarily having to change any external program facing interfaces when the business logic changes.

Consider the maintenance of your programs. After all it is not just a ping-pong table => it is an extension of a program's runtime.

Cheers,

Julius