Logical difference ABAP InputScript

Hi,
What is the logical difference between a "Call transaction using..." in ABAP and an InputScript?
Thanks,
Govindappa.

Hi,
There are 2 main differences between ABAP call transaction and InputScript:
- The InputScript remains active while you process the transaction.
In particular, you can read all screen values and make decisions based on these values.
When you implement a Call Transaction in ABAP, you have to deliver all input data in advance.
- GuiXT offers a number of built-in features. For example, GuiXT will automatically display those popup screens that you do not handle in your InputScript, so that the user can continue, even in a situation that you did not anticipate.
Reward Points if found helpfull..
Cheers,
Chandra Sekhar.

Similar Messages

Logical Difference of defining Multiple Logical level keys

Hi All,
We add logical level keys in BMM layer by right cliking the logical level column of a dimesional hierarchy, doing so defines a new logical key, i already have another logical level column defined as logical level key.
When i double click on logical level hierarchy, it has keys tab where i have two keys now.
say the two keys are: "channel desc key" and "channel id key"
My question is in one key say "channel id key" if we click edit, i am getting all the columns including channel desc column, so if i click it as key, it forms a composite key of (channel id) + (channel desc) inside "channel id key". Then what is the use of maintaining another key = "channel desc key"
Is there any logical difference of ("maintaining two keys having single column defined as key in either of them") and ("maintaining one key having two logical columns defined as keys in a single logical level key")?
Thanks in Advance.
Regards,
Sreekanth.

Hey got the answer, there is a difference, if i add multiple columns as keys under a single logical level key, they both come under one key and its drill down on both the columns, i cannot select selectively out of which column of the two drill down is applicatble.
If i create two different logical keys for two columns i can selectively choose which column drill down is applicable to.
Drill Down is based on "Logical Level Key" not on Logical Level Column selected as key.
Thanks,
Sreekanth.

MD5sum Checksum Logic in ABAP interface

Hi All..
I am Pavan, ABAP Consultant from Bangalore, India....
How to incorporate MD5sum checksum logic in ABAP interface...???
FYI, MD5sum is a checksum tool available in the web. This tool will generate a unique No' for each flatfile downloaded from SAP via extracts..
When i send the same flat file to my client, they will validate the checksum again.. Once it is validated, then it will be confirmed that data is not tampered... Otherwise, client will reject the file..
This is a mandatory process for my client, since they are working as per SOXa standards... (Sarbanes - Oxley Controls & Process)
Please help me, if any one of you have the information regarding this ..
Thanks in Advance......
Regards
Pavan Sanganal
Bangalore, India
Email : [email protected]

Hi,
assuming you have the content in the well known table
sdokcntbins, the following snippet may became useful:
DATA:
    input_length        TYPE i,
    hash                TYPE hash160,
    data                TYPE xstring.
CALL FUNCTION 'SCMS_BINARY_TO_XSTRING'
    EXPORTING
      input_length = input_length
    IMPORTING
      buffer       = data
    TABLES
      binary_tab   = p_file_content_binary.
CALL FUNCTION 'CALCULATE_HASH_FOR_RAW'
    EXPORTING
      alg = 'MD5'
      data = data
    IMPORTING
      hash = hash.
Best regards,
Stefan

Convert logic in ABAP.

Hello,
I want to convert following logic in ABAP.
if i_out-belnr is between 90000000 and 99999999.
endif.

You can do this...
data: r_belnr type range of belnr,
wa_belnr like line of r_belnr.
data: belnr type belnr.
wa_belnr-low = '90000000'.
wa_belnr-high = '99999999'.
wa_belnr-sign = 'I'.
wa_belnr-option = 'BT'.
append wa_belnr to r_belnr.
if i_out-belnr in r_belnr.
endif.

Logic in ABAP HR

Hi folks,
         Actually my requirement is, i have some data in an internal table. I have to check the particular record in in that itab is there in infotype 9003 by checking some condtions. if the record is not found in the 9003 i need to display a error message. I am new to ABAP HR. Please help me regarding the logic of comparing ITAB and an infotype in my requirement here.
                Thanks,
                Ram.

Create a program
In program attributes
Put PNP for the Logical Database field
Save it
You will have PNP's standard selection screen
If you dont want selection screen from PNP,
In program attributes Choose HR REPORT CATEGORY
Create one with no fields for selection
tables: pernr
infotypes: 0000, 0001, 0002, 0006, 9003
start-of-selection.
get pernr.
loop at table p9003.
endloop.
all values of 9003 will be in internal table p9003
If you have Personnel number in your internal table itab then the easier code without PNP Logical database is
loop at itab.
CALL FUNCTION 'HR_READ_INFOTYPE'
    EXPORTING
*     TCLAS                 = 'A'
      pernr                 = itab-pernr
      infty                 = 9003
     BEGDA                 = '18000101'
     ENDDA                 = '99991231'
   IMPORTING
     SUBRC                 = subrc
    tables
      infty_tab             = it9003
   EXCEPTIONS
     INFTY_NOT_FOUND       = 1
     OTHERS                = 2
IF sy-subrc = 0.
** Do the processing you want to do
ENDIF.
endloop.
Reward points if helpful

Script logic: differences between MS and NW?

Hi to all,
at last SAP Tech Ed I've bought a book on SAP BPC 7, Netweaver version...I did it because I'm already working with the MS version, but I hoped to get a better vision on BPC over NW, and to understand some critical subjects.
One question that I've been wondering is this one: I've found that some script logic examples that I've been able to reuse even in the MS version of BPC, while other won't. For example, I've found the *RUN_ALLOCATION (which I couldn't find in the logic assistent helper installed), and used it happily , and at the same time, I've found the *RUN_PROGRAM, which I don't really get any help from the web. I've found some posts in the NW version, not in the MS.
So: is there any kind of document about the differences between scripting logic for MS and NW?
Thank you
Daniele

Between 7.0 M and 7.0 NW we have a document with differences.
But after that new SP or release was bringing new functionalities into NW.
So it is depending what versions you will compare.
Any way you will find key words into NW which are not into M version and oposite.
So my suggestion will be to check the help documentation for version of NW used and to use the key words existing into that version.
Principle of script logic is the same.
Regards
Sorin Radulescu

Small logic in ABAP

Hi,
     am very new to abap , i have the logic of Prime number in c language , i want to do it in ABAP ,
so kindly help me .
thanks,
Sudhakar

REPORT ztest1 .
PARAMETERS: p_from TYPE i,
            p_to   TYPE i.
DATA: v_from      TYPE i,
      v_to        TYPE i,
      v_remainder TYPE i,
      v_is_prime TYPE c,
      v_divisor   TYPE i.
START-OF-SELECTION.
v_from = p_from.
v_to   = p_to.
DO.
    IF v_from = v_to.
      EXIT.
    ENDIF.
    CLEAR v_is_prime.
    DO v_from TIMES.
      v_divisor = sy-index.
      v_remainder = v_from MOD v_divisor.
      IF v_divisor <> 1      AND
         v_divisor <> v_from AND
         v_remainder = 0.
*-- not a prime
        v_is_prime = 'N'.
        EXIT.
      ENDIF.
    ENDDO.
    IF v_is_prime IS INITIAL.
*-- the number is prime
      WRITE:/ v_from, 'is a prime number'.
    ENDIF.
    v_from = v_from + 1.
ENDDO.

Help in writing logic to abaper for printing contact details from partnr fn

Hi friends,
I have to give the logic to the abaper to print the contact details of one partner which is manually entered in the quotation at header level.
i have a partner z1 with partner type PE which is manually entered in the partner fn field at the header level. this z1 partner fn is an employee. The name and contact details of this employee needs to be printed in the header of the output.
What is the logic i need to give to abaper for this.
Regards,
Anand

Hi Anand,
In case you do not find an ADRNR for the respective partner funtion in VBPA table, then, it means that the employee number derived from customer master is correct. Then, I think you can take KUNNR number for the employee partner function thro' VBPA and put the same in KNA1 table to get the right ADRNR. (As explained by me in the first post).
My question now is, are you maintaining the employee in XD01 (customer) or in VPE1 (Sales Rep)?
You can try with tables PA0002 Personal Data and PA0006 Addresses only if you maintain employees thro' VPE1 Tcode. PA0006 has PERNR field. But, what you have to make sure is that the table is getting updated. Else, you may not find the data here as well.
Hope this helps...
Thanks
Mukund S

Combinatorial logic difference between Spartan 6 and Spartan 3

Hello,
I'm porting a project from the Spartan 3 series to the Spartan 6 and encountered a difference in implementation between the two families. I've added the part of the code that is responsible for the difference in attachment. It's written fully combinatorial which I know is usually a bad idea, but I'll have to rewrite a much larger part of the project if I want to change this module to synchronous logic.
The module itself is used in a motor H-bridge driver and checks if the desired current level in the motor is reached. If so, it starts a fixed freewheel (off) period which is implemented as a counter and decreased every time a pulse arives on the freewheelclk input. When this module is implemented on a Spartan 3, the counter correctly counts down every pulse. However it counts down only every 4 pulses on a Spartan 6.
In behavioural simulation the code works fine, but Chipscope verified the counter value decreasing only every 4 pulses when actually running on the Spartan 6.
I assume this is due to a difference in combinatorial logic (timing) in the slices, but find it difficult to pinpoint the exact problem. What is the best way to further analyse this problem and/or what could be a fix so this code behaves the same on both platforms?
Additional details which I don't know are relevant:
- The Spartan 3 project was in ISE 14.7, the Spartan 6 project is in Planahead 14.7
- The Spartan 3 is a XC3S200-4TQG114C
- The Spartan 6 is a XC6SLX9-2CSG225C

Thanks for adding this details:
I would like to focus on design functionality.
The major difference in the in ISE/PlanAhead 14.7, with respect to synthesis is the XST synthesis parser.
When Spartan-3 selected for a project in ISE/PA XST old parser is picked.
When Spartan-6 selected for a project in ISE/PA XST New parser is picked.
The important point to note is ISE and PlanaAhead default synthesis options are not same.
I would still try to work with ISE 14.7 for spartan-6 ported design which is easy to understand the root cause of the incorrect behavior.
In ISE 14.7, inorder to understand the difference is because of the parser, I would start verifying behavioral and Post-synthesis simulation.
Try comparing the synthesis reports to understand if there is any difference in analyzing the code or optimization.
You may share the project and the simulation test bench, if help needed in investigation.
Regards,
Achutha

HR - Supress Error messages at end of PNP Logical dB ABAP

It appears from the code for logical dB PNP that you can turn off the error messages that automatically print at the end of the program, but I don't see how to do it. Here's the SAP code in include DBPNPI01:
FORM end-processing.
CHECK sw_supress_write EQ no.
Can anyone tell me how to 'change' sw_supress_write?

Try this code:
DATA:
BEGIN OF t_empty OCCURS 50,
        pernr LIKE pernr-pernr,
END   OF t_empty.
DATA:
temp1 TYPE i,
temp2 TYPE i,
temp3 TYPE i.
NODES: pernr.
START-OF-SELECTION.
PERFORM pnp_skipped_pernr(sapdbpnp)
    TABLES t_empty
    USING 'Y'
    CHANGING temp1 temp2 temp3.
GET pernr.
* Do something here.
*FORM pnp_skipped_pernr
*         TABLES   locked_pernr_tab     LIKE locked[]        "out
*         USING    supress_reject_info LIKE sw_supress_write"in
*         CHANGING auth_skipped_count   LIKE auth-skip-count "out
*                  locked_skipped_count LIKE locked_pernr_count"out
*                  locked_occurs_param LIKE locked_ocp.     "out
* locked_pernr_tab[]   = locked[].
* sw_supress_write     = supress_reject_info.
* auth_skipped_count   = auth-skip-count.
* locked_skipped_count = locked_pernr_count.
* locked_occurs_param = locked_ocp.
*ENDFORM.                               "pnp_skipped_pern
Let us know how it goes.

Need logic in abap-hr

Hi
I have a requirement that employee can display,edit,view and confirm his personel data i.e first name,last name.dob etc.
Requirement is:
need 4 tabs :1 for display data,1 for edit, 1 for review and 1 for confirm.
here using bapis for getting data and to change data.
Need help that what's the infotypes,tables involved here and what's the exact logic.
Points are assured for correct answers.
Regards,
Sree

Hi Sreeram,
Employee personal data is held in infotype number 0002.
The database table @ the back end is PA0002.
However in HR you do not update infotypes via direct DB update, rather we have function modules for the same:
Display Data (extracting personal data from infotype 0002) use function module HR_READ_INFOTYPE
Update Data into infotype 0002 for a employee use function module HR_INFOTYPE_OPERATION.
Cheers,
Aditya

Please help me think about logic in abap program

Hello every one.
i have question.
my selection of program is
company code
brand from:    to:
fiscal year
period from:   to:
example.
company code 0145
brand from:AAA    to: ZZZ
fiscal year 2011
period from: 4 to: 6
and desired output report is
brand AAA        April   May June
sale              700     600 700
COG               300     250 350
Net sale          400     350 250
brand BBB        April   May   June
sale             1000    500   800
COG               500    250   400
Net sale          500    250   400
sum of all brand   April May June
sale              1700    1100 1500
COG               800     500   750
Net sale          900     600   650
pleae help me to think about logic.
now i just have idea that i have to
loop at internal_table_brand.
Moderator Message: Do not dump your spec in the forum.
Edited by: Suhas Saha on Jun 16, 2011 4:16 PM

Hi,
This works now. You just need to create your methods and link them in with your case statement as flounder showed you.
import java.util.Scanner;
public class CarConfiguration
     public static void main(String[] args)
     int choise = Menu();
     processSelector(choise);
     private static int Menu()
          System.out.println("\nWELCOME TO CAR CONFIGURATION APPLICATION PROGRAM");
          System.out.println("======================================");
          System.out.println(" Enter _1_ to Chasis Type");
          System.out.println(" Enter _2_ to Engine Type");
          System.out.println(" Enter _3_ to Transmission");
          System.out.println(" Enter _4_ to Options ");
          System.out.println(" Enter _5_ to Finish ");
          System.out.println("======================================");
          System.out.print("Select Your Choise: ");
     Scanner input=new Scanner(System.in);
     int choise=input.nextInt();
     return(choise);
     private static void processSelector(int choise)
          switch(choise)
               case 1: //enter mehtods here and for all other empty cases
               break;
               case 2:
               break;
               case 3:
               break;
               case 4:
               break;
               case 5:
               break;
               default:
               System.out.println("Invalid selection");
               break;
}

I have logical problemin ABAP

hi all
i hav internal table call it_itab1 so there has som several equal record. so i want to get yhe som of all equal item. i can shaw u to so example.
it_itab1 table
code    item value
001      4k     120
001      4k     100
001      4k      80
002      5h      200
002      5h      100
003      6y      500
003      6y      400
i ant to get som of each equl feild
code     item   value
001       4k      300
002       5h      300
003       6y      900
i think u can understand wot me want.. i want to sum of each equal feild value...(001 4k =(12010080) ... this is my requrement so how should i write the code. if u can please help me...
regard
nawa

Hi
U can do it using COLLECT
Basic form
COLLECT [wa INTO] itab.
Addition: ... SORTED BY f
In an ABAP Objects context, a more severe syntax check is performed that in other ABAP areas. See Short forms of line operations not allowed.
Effect
COLLECT allows you to create unique or summarized datasets. The system first tries to find a table entry corresponding to the table key (see Key definition for internal tables ). The key values are taken either from the header line of the internal table itab, or from the explicitly-specified work area wa. itab must have a flat structure, that is, it may not contain other internal tables. All components that are not part of the key must be have numeric types (see ABAP numeric types).
If the system finds an entry, the numeric fields that are not part of the table key (see ABAP number types) are added to the sum total of the existing entries. If it does not find an entry, the system creates a new entry instead.
The way in which the system finds the entries depends on the type of the internal table:
STANDARD TABLE:
The system creates a temporary hash administration for the table to find the entries. This means that the runtime required to find them does not depend on the number of table entries. The administration is temporary, since it is invalidated by operations like DELETE, INSERT, MODIFY, or SORT. A subsequent COLLECT is then no longer independent of the table size, because the system has to use a linear search to find entries. For this reason, you should only use COLLECT to fill standard tables.
SORTED TABLE:
The system uses a binary search to find the entries. There is a logarithmic relationship between the number of table entries and the search time.
HASHED TABLE:
The system uses the internal hash administration of the table to find records. Since (unlike standard tables), this remains intact even after table modification operations, the search time is always independent of the number of table entries.
For standard tables and SORTED TABLEs, the system field SY-TABIX contains the number of the existing or newly-added table entry after the APPEND. With HASHED TABLEs, SY-TABIX is set to 0.
Notes
COLLECT allows you to create a unique or summarized dataset, and you should only use it when this is necessary. If neither of these characteristics are required, or where the nature of the table in the application means that it is impossible for duplicate entries to occur, you should use INSERT [wa INTO] TABLE itab instead of COLLECT. If you do need the table to be unique or summarized, COLLECT is the most efficient way to achieve it.
If you use COLLECT with a work area, the work area must be compatible with the line type of the internal table.
If you edit a standard table using COLLECT, you should only use the COLLECT or MODIFY ... TRANSPORTING f1 f2 ... statements (where none of f1, f2, ... may be in the key) enthalten sein). Only then can you be sure that:
-The internal table actually is unique or summarized
-COLLECT runs efficiently. The check whether the dataset
already contains an entry with the same key has a constant
search time (hash procedure).
If you use any other table modification statements, the check for entries in the dataset with the same key can only run using a linear search (and will accordingly take longer). You can use the function module ABL_TABLE_HASH_STATE to test whether the COLLECT has a constant or linear search time for a given standard table.
Example
Summarized sales figures by company:
TYPES: BEGIN OF COMPANY,
        NAME(20) TYPE C,
        SALES    TYPE I,
      END OF COMPANY.
DATA: COMP    TYPE COMPANY,
      COMPTAB TYPE HASHED TABLE OF COMPANY
                                WITH UNIQUE KEY NAME.
COMP-NAME = 'Duck'. COMP-SALES = 10. COLLECT COMP INTO COMPTAB.
COMP-NAME = 'Tiger'. COMP-SALES = 20. COLLECT COMP INTO COMPTAB.
COMP-NAME = 'Duck'. COMP-SALES = 30. COLLECT COMP INTO COMPTAB.
Table COMPTAB now has the following contents:
          NAME    | SALES
          Duck    |   40
          Tiger   |   20
Addition
... SORTED BY f
Effect
COLLECT ... SORTED BY f is obsolete, and should no longer be used. It only applies to standard tables, and has the same function as APPEND ... SORTED BY f, which you should use instead. (See also obsolete statements.)
Note
Performance:
Avoid unnecessary assignments to the header line when using internal tables with a header line. Whenever possible, use statements that have an explicit work area.
For example, "APPEND wa TO itab." is approximately twice as fast as "itab = wa. APPEND itab.". The same applies to COLLECT and INSERT.
The runtime of a COLLECT increases with the width of the table key and the number of numeric fields whose contents are summated.
Note
Runtime errors:
COLLECT_OVERFLOW: Overflow in an integer field during addition
COLLECT_OVERFLOW_TYPE_P: Overflow in a type P field during addition.
TABLE_COLLECT_CHAR_IN_FUNCTION: COLLECT on a non-numeric field.
Regards,
Prasanth
Reward all helpful answers

ABAP AND DATABASES

Hi Experts..
I would like to know how to create a databases in SQL and have access from ABAP.. to Modify, Consult and do the basic operations like insert information, drop and modify in the respective tables.
I'm ussing MiniSap Minigui 6.2 on Windows XP and the BCUSER
Thank you very much for your help
REGARDS

HI Araceli,
Database Access using Advanced Business Application Programming (ABAP)
Basics :
Accessing the Database in the R/3 System is performed through the interface provided by the SAP System, which in the SAP System is referred to as the Database Interface. A user can access the database from his/her program through Open SQL and Native SQL depending upon the circumstances.
About SQL
The Structured Query Language (SQL) is a largely standardized language, which is used for accessing relational databases. It can be divided as follows:
Data Manipulation Language (DML)
These statements are for reading and changing data in database tables.
Data Definition Language (DDL)
These statements are for creating and administering database tables.
Data Control Language (DCL)
These statements are used for authorization and consistency checks.
So each database has a programming interface. This programming interface allows the user to access the database tables by using SQL statements. But, these SQL statements in the programming interfaces are not fully standardized. So, you must refer to the documentation of that system for a list of the SQL statements available and also their correct syntax in order to access a specific database system.
Interface thru data base
Each work process on an application server must have a database interface if you want to make the R/3 system independent of the database system, and also to use it correctly despite the differences in the SQL syntax between various databases. By means of this interface only, the R/3 system can communicate with the database. All of the database requests from the R/3 system are converted into the correct Standard SQL statements for the database system by the database interface. In order to perform this function, it has to use a database-specific component, which shields the differences between database systems from the rest of the database interface. You have to choose the appropriate layer when installing the R/3 system. A user can access a database from a program through Open SQL and Native SQL.
Open SQL
Open SQL are statements that make up a subset of Standard SQL which is fully integrated in ABAP. Open SQL consists of Data Manipulation Language (DML) which is a part of Standard SQL.
One of the ways to access the database from a program is Open SQL. These Open SQL statements are nothing but a subset of Standard SQL, which is fully integrated in ABAP. Irrespective of which database system the R/3 installation is using, they allow you to access data. When I said that, Open SQL consists of the Data Manipulation Language (DML). I meant that it allows you to read (i.e. to SELECT) and change (For example to INSERT, UPDATE, DELETE) data.
Moreover, Open SQL also goes beyond Standard SQL. This is to provide statements that can simplify or speed up database access in conjunction with other ABAP constructions. Apart from that, it also gives you the freedom to buffer certain tables on the application server, thereby enabling you to save excessive database access. In this case, the database interface is responsible for comparing the buffer with the database. As far as buffer storage is concerned, they may be stored in two parts: the working memory of the current work process, and the shared memory for all work processes on an application server. The data in the various buffers is synchronized at set intervals by buffer management where an R/3 system is distributed across more than one application server. It should be noted that data in the buffer is not always up to date when you are buffering the database. That is why you should only use the buffer for data which does not change often. You can specify whether a table can be buffered in its definition in the ABAP Dictionary.
Open SQL consists of a set of ABAP statements. These statements perform operations on the central database in the R/3 system. The results of the operations and any error messages which come out of it are independent of the current database system. Thus, uniform syntax and semantics for all of the database systems supported by SAP is provided by Open SQL. Regardless of the current database system, the ABAP programs, which use Open SQL statements only, will work in any R/3 system. Moreover, Open SQL statements work only with database tables that have been created in the ABAP Dictionary.
You have the freedom to combine columns belonging to different database tables to a database view (or view for short) in the ABAP Dictionary. Views are also handled in exactly the same way as database tables in Open SQL statements.
Some Open SQL keywords are as follows:
SELECT - It reads data from database tables.
INSERT - It adds rows to database tables.
UPDATE - It changes the contents of rows of database tables.
MODIFY - It inserts rows into database tables or changes the content of existing rows.
DELETE - It deletes rows from database tables.
OPEN CURSOR, FETCH, CLOSE CURSOR - It reads rows of database tables using the cursor.
Return Codes
The following two system fields are filled with return codes by all Open SQL statements:
SY-SUBRC: The system field SY -SUBRC contains the value 0 after every Open SQL statement if the operation was successful. When a value is other than 0, then it is unsuccessful.
SY-DBCNT: The system field SY-DBCNT contains the number of database lines processed after an open SQL statement.
Native SQL
The other possible way to access the database from a program is Native SQL. It is only loosely integrated into ABAP. It allows access to all of the functions contained in the programming interface of the respective database system. Native SQL statements are not checked and converted as compared to Open SQL statements. Unlike Open SQL, these are sent directly to the database system. The function of the database-dependent layer remains minimal when you use Native SQL. The Programs which use Native SQL are written specifically for a database system. You should avoid using Native SQL wherever possible when writing R/3 applications. However, you can use it in some parts of the R/3 Basis System, for instance, for creating or changing table definitions in the ABAP Dictionary.
Regardless of the database platform that your R/3 system is using, Open SQL allows you to access database tables, which are declared in the ABAP Dictionary. Native SQL allows you to use database specific SQL statements in an ABAP program. This means that you can use database tables that are not administered by the ABAP Dictionary. Aside from that, you can also integrate data that is not part of the R/3 system.
As a rule, an ABAP program that contains database-specific SQL statements will not run under different database systems. You have to use Open SQL statements only, if your program is used on more than one database platform.
You must proceed with the EXEC SQL statement, and follow the ENDEXEC statement to use a: Native SQL statement. For example
Listing 1
EXEC SQL [PERFORMING
ENDEXEC.There is no period after Native SQL statements. Also, using quotation marks (") or an asterisk (*) at the beginning of a native SQL statement's line does not introduce a comment as it would in normal ABAP syntax. You need to know if the table and field names are case-sensitive in your chosen database.
The data is transported between the database table and the ABAP program using host variables in Native SQL statements. These are preceded in a Native SQL statement by a colon ( and are declared in the ABAP program. The elementary structures can be used as host variables. The structures of an INTO clause are treated exceptionally, as though all of their fields are listed individually. If the selection in a Native SQL SELECT statement is a table, then you can pass it to ABAP line by line using the PERFORMING addition. For each line read, the program calls a subroutine
. Further, you can process the data within the subroutine.
After the ENDEXEC statement, SY-DBCNT contains the number of lines processed as it does in Open SQL. In almost all cases, SY-SUBRC contains the value a after the ENDEXEC statement. Cursor operations form an exception: after FETCH, SY-SUBRC is 4 if no more records could be read. This is also applied when you read a result set using EXEC SQL PERFORMING.
Native SQL Scope
Native SQL is very important as it allows you to execute nearly all available statements through the SQL programming interface (usually known as SQL Call Interface or similar) for directly executing SQL program code (using EXEC IMMEDIATE or a similar command). The statements that are not supported are listed in the following section:
·         Native SQL and the Database Interface,
·         Native SQL and Transactions
·         Native SQL and the Database Interface
Native SQL statements bypass the R/3 database interface. With the database buffer on the application server, there is no table logging, and no synchronization. Therefore, you should use Open SQL to change database tables declare in the ABAP dictionary wherever possible. Since the columns contain extra database specific length information for the column tables declared in the ABAP dictionary, containing long columns with the type LCHAR or LRAW should only be addressed using Open SQL. Native SQL may not produce the correct result, as it does not take this information into account. Native SQL does not support automatic client handling. Instead, you must treat a client field like any other field
Native SQL and Transactions
One should not use any transaction control statement such as COMMIT, ROLLBACK WORK, or any statements that set transaction parameters using Native SQL to ensure that transaction in the R/3 System are consistent.
ABAP Dictionary
The ABAP Dictionary is nothing but a part of the ABAP Workbench. It allows you to create and administer database tables. There are no statements from the DDL part of Standard SQL in Open SQL. It should be noted that normal application programs should not create or change their own database tables.
To create and change database tables, the ABAP Dictionary has to use the DDL part of Open SQL. Besides this, it also administers the ABAP Dictionary in the database. In addition, the ABAP Dictionary contains meta-descriptions of all database tables in the R/3 system. Here, only database tables appears in the Dictionary, which you have created using the ABAP Dictionary. Open SQL statements can only access tables, which exists in the ABAP Dictionary.
Authorization and Consistency Checks
With regard to authorization and consistency checks, the DCL part of Standard SQL is not used in R/3 programs. Whereas, the work processes which are within the R/3 system are logged into the database system as users with full rights. By using the R/3 authorization concept, the authorizations of programs or users to read or change database tables is administered within the R/3 system. In addition, transactions must equally ensure their own data consistency using the R/3 locking concept.
The R/3 lock concept allows you to monitor your system with regards to lock logics. The R/3 lock concept works closely together with the R/3 updates.
As an example, say that a travel agent wants to book a flight for a customer who wants to fly to a particular city with a certain airline on a certain day. If there are still available seats on the flight, then the booking will be possible, otherwise it will lead to overbooking. Hence, the database entry corresponding to the flight must be locked against access from other transactions to avoid the possibility of overbooking. This is because two agents might both be doing this same thing at the same time, and we need to make sure that we don't overbook.
Lock Mechanisms
When the database system receives change statements (INSERT, UPDATE, MODIFY, DELETE) from a program, it automatically sets database locks. Database locks are locks on the database entries affected by statements to prevent problems. Since the lock mechanism uses a, lock flag in the entry, you can only set a lock for an existing database entry. After each database commit, these flags are automatically deleted. This means that database locks can never be set for longer than a single database LUW, a single dialog step in an R/3 application program.
Therefore, physical locks in the database system are insufficient for the requirements of an R/3 transaction. Locks in the R/3 system must remain set for the duration of a whole SAP LUW, that is, over several dialog steps. They must also be capable of being handled by different work processes and application servers. As a result, each lock must apply on all servers in that R/3 system.
Database Accesses of the NetWeaver AS ABAP
The NetWeaver AS ABAP stores long-term data in a central relational database table. In a relational database model, the real world is represented by tables. A table is a two-dimensional matrix, consisting of lines and columns (fields). The smallest possible combination of fields that can uniquely identify each line of the table is called the key. Each table must have at least one key, and each table has one key that is defined as its primary key. Relationships between tables are represented by foreign keys.
Standard SQL
SQL (Structured Query Language) is a largely standardized language for accessing relational databases. It can be divided into three areas:
·        Data Manipulation Language (DML)
Statements for reading and changing data in database tables.
·        Data Definition Language (DDL)
Statements for creating and administering database tables.
·        Data Control Language (DCL)
Statements for authorization and consistency checks.
Each database has a programming interface that allows you to access the database tables using SQL statements. The SQL statements in these programming interfaces are not fully standardized. To access a specific database system, you must refer to the documentation of that system for a list of the SQL statements available and their correct syntax.
The Database Interface
To avoid incompatible situations between different database tables and to make the NetWeaver AS ABAP system independent of the database system in use, each work process on an ABAP application server contains a database interface. The NW AS communicates with the database solely through the database interface. The database interface converts all of the database requests from the NW AS into the correct Standard SQL statements for the database system in use. To do this, it uses a database-specific component that shields the differences between database systems from the rest of the database interface. You choose the this component when you install NetWeaver AS ABAP in accordance with the database in use.
ABAP programs have two options for accessing the database interface: Open SQL and Native SQL.
Open SQL
Open SQL statements are a fully integrated subset of Standard SQL within ABAP. They enable the ABAP programs to access data irrespective of the database system installed. Open SQL consists of the Data Manipulation Language (DML) part of Standard SQL; in other words, it allows you to read (SELECT) and change (INSERT, UPDATE, DELETE) data.
Open SQL also goes beyond Standard SQL to provide statements that, in conjunction with other ABAP constructions, can simplify or speed up database access. It also allows you to buffer certain tables on the application server, saving excessive database access. In this case, the database interface is responsible for comparing the buffer with the database. Buffers are partly stored in the working memory of the current work process, and partly in the shared memory for all work processes on an application server. In SAP systems that are distributed across more than one application server, the data in the various buffers is synchronized at set intervals by buffer management. When buffering the database, you must remember that data in the buffer is not always up to date. For this reason, you should only use the buffer for data which does not often change. You specify whether a table can be buffered in its definition in the ABAP Dictionary.
Native SQL
Native SQL is only loosely integrated into ABAP, and allows access to all of the functions contained in the programming interface of the respective database system. Unlike Open SQL statements, Native SQL statements are not checked and converted, but instead are sent directly to the database system. When you use Native SQL, the function of the database-dependent layer is minimal. Programs that use Native SQL are specific to the database system for which they were written. When developing generally valid ABAP applications, you should as far as possible avoid using Native SQL. In some components of the SAP System, Native SQL is used for example, in the ABAP Dictionary for creating or changing tables.
The ABAP Dictionary
The ABAP Dictionary, part of the ABAP Workbench, allows you to create and administer database tables. Open SQL contains no statements from the DDL part of Standard SQL. Normal application programs should not create or change their own database tables.
The ABAP Dictionary uses the DDL part of Open SQL to create and change database tables. It also administers the ABAP Dictionary in the database. The ABAP Dictionary contains meta descriptions of all database tables in the NetWeaver AS ABAP system. Only database tables that you create using the ABAP Dictionary appear in the Dictionary. Open SQL statements can only access tables that exist in the ABAP Dictionary.
Authorization and Consistency Checks
The DCL part of Standard SQL is not important in ABAP programs. The work processes within the ABAP application server are logged on to the database system as users with full authorization. The authorizations of programs or program users to read or change database tables is managed by the authorization concept. Equally, transactions must ensure their own data consistency in the database using the SAP locking concept. For more information, refer to the chapter Data Consistency.
Work Processes
Work processes execute the individual dialog steps of ABAP application programs. They are components of ABAP application servers. The next two sections describe firstly the structure of a work process, and secondly the different types of work process in NetWeaver AS ABAP.
Structure of a Work Process
The following diagram shows the components of a work process:
Screen Processor
In ABAP application programming, there is a difference between user interaction and processing logic. From a programming point of view, user interaction is controlled by screens. As well as the actual input mask, a screen also consists of flow logic, which controls a large part of the user interaction. NetWeaver AS ABAP contains a special language for programming screen flow logic. The screen processor executes the screen flow logic. Via the dispatcher, it takes over the responsibility for communication between the work process and the SAPgui, calls modules in the flow logic, and ensures that the field contents are transferred from the screen to the flow logic.
ABAP Processor
The actual processing logic of an application program is written in ABAP - SAPs own programming language. The ABAP processor executes the processing logic of the application program, and communicates with the database interface. The screen processor tells the ABAP processor which module of the screen flow logic should be processed next. The following screen illustrates the interaction between the screen and the ABAP processors when an application program is running.
Database Interface
The database interface provides the following services:
·        Establishing and terminating connections between the work process and the database.
·        Access to database tables
·        Access to Repository objects (ABAP programs, screens and so on)
·        Access to catalog information (ABAP Dictionary)
·        Controlling transactions (commit and rollback handling)
·        Table buffer administration on the ABAP application server.
The following diagram shows the individual components of the database interface:
The diagram shows that there are two different ways of accessing databases: Open SQL and Native SQL.
Open SQL statements are a subset of Standard SQL that is fully integrated in ABAP. They allow you to access data irrespective of the database system that your installation is using. Open SQL consists of the Data Manipulation Language (DML) part of Standard SQL; in other words, it allows you to read (SELECT) and change (INSERT, UPDATE, DELETE) data. The tasks of the Data Definition Language (DDL) and Data Control Language (DCL) parts of Standard SQL are performed in NetWeaver AS ABAP by the ABAP Dictionary and the authorization system. These provide a unified range of functions, irrespective of database, and also contain functions beyond those offered by the various database systems.
Open SQL also goes beyond Standard SQL to provide statements that, in conjunction with other ABAP constructions, can simplify or speed up database access. It also allows you to buffer certain tables on the ABAP application server, saving excessive database access. In this case, the database interface is responsible for comparing the buffer with the database. Buffers are partly stored in the working memory of the current work process, and partly in the shared memory for all work processes on an ABAP application server. Where NetWeaver AS ABAP is distributed across more than one ABAP application server, the data in the various buffers is synchronized at set intervals by the buffer management. When buffering the database, you must remember that data in the buffer is not always up to date. For this reason, you should only use the buffer for data which does not often change.
Native SQL is only loosely integrated into ABAP, and allows access to all of the functions contained in the programming interface of the respective database system. In Native SQL, you can primarily use database-specific SQL statements. The Native SQL interface sends them as is to the database system where they are executed. You can use the full SQL language scope of the respective database which makes all programs using Native SQL specific for the database system installed. In addition, there is a small set of SAP-specific Native SQL statements which are handled in a special way by the Native SQL interface. ABAP applications contain as little Native SQL as possible. In fact, it is only used in a few components (for example, to create or change table definitions in the ABAP Dictionary).
The database-dependent layer in the diagram serves to hide the differences between database systems from the rest of the database interface. You choose the appropriate layer when you install NetWeaver AS ABAP. Thanks to the standardization of SQL, the differences in the syntax of statements are very slight. However, the semantics and behavior of the statements have not been fully standardized, and the differences in these areas can be greater. When you use Native SQL, the function of the database-dependent layer is minimal.
Types of Work Process
Before you start NetWeaver AS ABAP, you determine how many work processes each ABAP application server will have, and what their types will be. Since all work processes have the same structure (see preceding section), the type of work process does not determine the technical attrributes of the ABAP application server but the type of tasks to be performed on it. The dispatcher starts the work processes and only assigns them tasks that correspond to their type. This means that you can distribute work process types to optimize the use of the resources on your ABAP application servers.
The following diagram shows again the structure of an ABAP application server, but this time, includes the various possible work process types:
Dialog Work Process
Dialog work processes deal with requests from an active user to execute dialog steps (see also Dialog Programming).
Update Work Process
Update work processes execute database update requests. Update requests are part of an SAP LUW that bundle the database operations resulting from the dialog in a database LUW for processing in the background.
Background Work Process
Background work processes process programs that can be executed without user interaction (background jobs).
Enqueue Work Process
The enqueue work process administers a lock table in the shared memory area. The lock table contains the logical database locks for NetWeaver AS ABAP and is an important part of the SAP LUW concept. In NW AS, you may only have one lock table. You may therefore also only have one ABAP application server with enqueue work processes. Normally, a single enqueue work process is sufficient to perform the required tasks.
Spool Work Process
The spool work process passes sequential datasets to a printer or to optical archiving. Each ABAP application server may contain only one spool work process.
Role of Work Processes
The types of its work processes determine the services that an ABAP application server offers. The application server may, of course, have more than one function. For example, it may be both a dialog server and the enqueue server, if it has several dialog work processes and an enqueue work process.
You can use the system administration functions to switch a work process between dialog and background modes while the system is still running. This allows you, for example, to switch an SAP System between day and night operation, where you have more dialog than background work processes during the day, and the other way around during the night.
thanks
karthik
reward me points if usefull

Steps to create LOGICAL DATABASE in sap

hi guys,
i have gone through many documents about LDB. But, i didnt get the steps to create a LDB.
plz provide me with the steps to be followed to create a LDB.
thnx,
shivaa.

Hi Shiva,
This might help you!
Logical database structures
There are three defining entities in an SAP logical database. You must be clear on all three in order to create and use one.
Table structure: Your logical database includes data from specified tables in SAP. There is a hierarchy among these tables defined by their foreign keys (all known to SAP), and you are going to define a customized relationship between select tables. This structure is unique and must be defined and saved.
Data selection: You may not want or need every item in the referenced tables that contributes to your customized database. There is a selection screen that permits you to pick and choose.
Database access programming: Once youu2019ve defined your logical database, SAP will generate the access subroutines needed to pull the data in the way you want it pulled.
Creating your own logical database
ABAP/4 (Advanced Business Application Programming language, version 4) is the language created by SAP for implementation and customization of its R/3 system. ABAP/4 comes loaded with many predefined logical databases that can construct and table just about any conventional business objects you might need in any canned SAP application. However, you can also create your own logical databases to construct any custom objects you care to define, as your application requires in ABAP/4. Hereu2019s a step-by-step guide:
1. Call up transaction SLDB (or transaction SE36). The path you want is Tools | ABAP Workbench | Development | Programming Environment | Logical Databases. This screen is called Logical Database Builder.
2. Enter an appropriate name in the logical database name field. You have three options on this screen: Create, Display, and Change. Choose Create.
3. Youu2019ll be prompted for a short text description of your new logical database. Enter one. Youu2019ll then be prompted to specify a development class.
4. Now comes the fun part! You must specify a root node, or a parent table, as the basis of your logical database structure. You can now place subsequent tables under the root table as needed to assemble the data object you want. You can access this tree from this point forward, to add additional tables, by selecting that root node and following the path Edit | Node | Create. Once youu2019ve saved the structure you define in this step, the system will generate the programming necessary to access your logical database. The best part is you donu2019t have to write a single line of code.
Watch out!
The use of very large tables will degrade the performance of a logical database, so be aware of that trade-off. Remember that some tables in SAP are very complex, so they will be problematic in any user-defined logical database.
Declaring a logical database
Hereu2019s another surprising feature of logical databases: You do not assign them in your ABAP/4 Code. Instead, the system requires that you specify logical databases as attributes. So when you are creating a report, have your logical database identifier (the name you gave it) on hand when you are defining its attributes on the Program Attributes screen. The Attributes section of the screen (the lower half) will include a Logical database field, where you can declare your logical database.
Logical databases for increasing efficiency
Why else would you want to create a logical database? Consider that the logical databases already available to you begin with a root node and proceed downward from there. If the data object you wish to construct consists of items that are all below the root node, you can use an existing logical database program to extract the data, then trim away what you donu2019t want using SELECT statementsu2014or you can increase the speed of the logical database program considerably by redefining the logical database for your object and starting with a table down in the chain. Either way, youu2019ll eliminate a great deal of overhead.
Reward if useful.
Thankyou,
Regards.

Logical difference ABAP InputScript

Similar Messages

Maybe you are looking for