02-09-2005 5:11 PM
Hello,
I have always wondered what the "best practice" is in this case, so I am looking for input. When writing custom reports etc. in SAP, is it generally regarded as better practice to write a SELECT statement to get a line from say a Txxx configuration table, or is it best to use an associated BAPI or call to function module? I know in some cases perfomance must obvioulsy be considered, but in terms of SAP's recommendations or upgrade considerations, which is typically better?
Assume for example something as simple as getting company code data... Is it best to do <b>SELECT * FROM T001...</b> or to call a BAPI like <b>BAPI_COMPANYCODE_GETDETAIL</b>?
Any feedback would be greatly appreciated.
02-10-2005 10:17 AM
I use table,
- When I want to fetch a table array, not only one entry.
- When I'm sure that the data is coming from that table/tables
-When I'm sure about that this is the best from performance point of view.
I use FM,
- when it's released for customers (eg BAPI)
- when I need only one entry
- when I need RFC
- when the data is fetched in a complicated way, and I can see that this FM used in standard transaction.
FM is a higher level approach, if it's released for customers, then probable you can use in the next release also. It's very unlike (however sometimes happens eg Ibase tables), that SAP change the way of data storing in db. FM should work after it also.
Peter
02-09-2005 5:23 PM
02-09-2005 6:55 PM
> I would say that 95% of the time, if I need to hit a
> "T" table, I just write a select statement, I don't
> bother to look for a FM/BAPI which essential will do
> the same thing.
>
> Regards,
> Rich Heilman
True but in some cases those function modules come with a internal buffering technique which avoid multiple reads - when called several time - this can become quite handy if you are in a user-exit and use the same function module to "reread" the data which has been read in the program before.
Christian
02-09-2005 11:41 PM
Hi
Never accusing people of regarding performance, however I emphasize safety while developing. Even if it is a T* table, I try to use a standard function or call a subroutine of a standard program doing the work. I feel safer this way. Nevertheless, when I can't find any suitable (as of its interface), I use direct SELECT statements.
If it is a simple report program then doing direct selects may be tolerable. However, if it is a more sophisticated one, especially if it deals with database updates, I highly recommend to use standards.
As another way, I am aware you mean simple tables, but by the way, if it has a functional relation with a business entity (e.g. pa0001 for employee), I regard it as mandatory using standard FMs where applicable (I feel myself obliged to call "HR_READ_INFOTYPE" instead of using "SELECT* FROM PA0001...").
*--Serdar
02-10-2005 8:33 AM
> True but in some cases those function modules come
> with a internal buffering technique which avoid
> multiple reads - when called several time - this can
> become quite handy if you are in a user-exit and use
> the same function module to "reread" the data which
> has been read in the program before.
> Christian
You're right Christian, but if you're working with Customizing tables, most of the times they're buffered in the application server, so I understand that the time you earn use FM with buffering techniques is not too much.
But I agree with you when you have to deal with transactional data. Then it pays the price to search an FM with built-in buffer.
cheers,
David
02-10-2005 10:17 AM
I use table,
- When I want to fetch a table array, not only one entry.
- When I'm sure that the data is coming from that table/tables
-When I'm sure about that this is the best from performance point of view.
I use FM,
- when it's released for customers (eg BAPI)
- when I need only one entry
- when I need RFC
- when the data is fetched in a complicated way, and I can see that this FM used in standard transaction.
FM is a higher level approach, if it's released for customers, then probable you can use in the next release also. It's very unlike (however sometimes happens eg Ibase tables), that SAP change the way of data storing in db. FM should work after it also.
Peter