native sql DBCO, CONNECT statement short dump

[Former Member]

Hi ALL ,

I am facing the problem here. please help me out in this.

i am trying to connce to the external database MSS, i made all the entries in the DBCO t-code and writing the follwoing native sql statement.

EXEC SQL.

CONNECT TO 'AAJ' AS 'V'

ENDEXEC.

EXEC SQL.

SET CONNECTION 'V'

ENDEXEC.

The above statement is not giving any error when i activate it but when i execute it is giving me shortdump error .

I already maintan entries in DBCON table or DBCO t-code

And also tel me once it is connect how can i access the data from MSS (Microsoft sql server)i mean what kind of statement.

helpfull answer will be rewarded.

Anees

9886358645

Message was edited by:

anees jawad

[Former Member]

Native SQL

Open SQL allows you to access database tables declared in the ABAP Dictionary regardless of the database platform that you R/3 System is using. 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, and therefore integrate data that is not part of the R/3 System.

As a rule, an ABAP program containing database-specific SQL statements will not run under different database systems. If your program will be used on more than one database platform, only use Open SQL statements.

Native SQL Statements in ABAP Programs

To use a Native SQL statement, you must precede it with the EXEC SQL statement, and follow it with the ENDEXEC statement as follows:

EXEC SQL [PERFORMING )

The parameters are separated by commas. You must also specify whether the parameter is for input (IN), output (OUT) or input and output (INOUT). For further information, refer to SAP Note 44977.

EXEC SQL

EXECUTE PROCEDURE proc1 ( IN , OUT :y )

ENDEXEC.

Cursor Processing

Cursor processing in Native SQL is similar to that in Open SQL:

OPEN

ENDIF.

ENDDO.

EXEC SQL.

CLOSE c1

ENDEXEC.

This example opens a cursor, reads data line by line, and closes the cursor again. As in Open SQL, SY-SUBRC indicates whether a line could be read.

Data Types and Conversions

Using Native SQL, you can

Transfer values from ABAP fields to the database

Read data from the database and process it in ABAP programs.

Native SQL works without the administrative data about database tables stored in the ABAP Dictionary. Consequently, it cannot perform all of the consistency checks used in Open SQL. This places a larger degree of responsibility on application developers to work with ABAP fields of the correct type. You should always ensure that the ABAP data type and the type of the database column are identical.

If the database table is not defined in the ABAP Dictionary, you cannot refer directly to its data type. In this case, you should create a uniform type description in the ABAP Dictionary, which can then be used by all application programs.

If the table is defined in the ABAP Dictionary, you should remember that the sequence of fields in the ABAP Dictionary definition may not be the same as the actual sequence of fields in the database. Using the asterisk (*) in the SELECT clause to read all columns into a corresponding work area would lead to meaningless results. In the worst case, it would cause an error.

The Native SQL module of the database interface passes a description of the type, size, and memory location of the ABAP fields used to the database system. The relevant database system operations are usually used to access and convert the data. You can find details of these operations in the manuals for the programming interface of the relevant database system. In some cases, Native SQL also performs other compatibility checks.

The documentation from the various database manufacturers provides detailed lists of combinations of ABAP data types and database column types, both for storing ABAP field values in database tables (INSERT, UPDATE) and for reading database contents into ABAP fields (SELECT). You can also apply these descriptions for the input and output parameters of database procedures. Any combinations not listed there are undefined, and should not be used.

The following sections provide details of the data types and conversions for individual databases. Although they are database-specific, there are also some common features.

Recommended type combinations are underlined. Only for these combinations is behavior guaranteed from release to release. For any other combinations, you should assume that the description only applies to the specified release.

The results of conversions are listed in a results column:

"OK": The conversion can be performed without loss of data.

Operations that fail are indicated by their SQL error code. Errors of this kind always lead to program termination and an ABAP short dump.

In some cases, data is transferred without an SQL error occurring. However, the data is truncated, rounded, or otherwise unusable:

Right truncation.

"Left" or "right" applies to the normal way of writing a value. So, for example, if a number is truncated, its decimal places are affected.

: Left truncation

: Number is rounded up or down during conversion

: A number that was "too small" is rounded to 0 (underflow)

: The conversion result is undefined.

There are several possible results. The concrete result is either not known at all, or can only be described using a set of rules that is too complicated for practical use.

: The conversion returns the SQL value NULL.

: The conversion is performed without fields and unchecked.

The original data is converted, but without its format being checked. The result may therefore be a value invalid for the result type, which cannot be processed further. An example of this is a date field containing the value "99999999" or "abcdefgh" after conversion.

Combinations of ABAP data type and database column type can be divided into finer subcategories. Here, for example, using the transfer direction ABAP ® database (INSERT, UPDATE):

If the width of the ABAP field is greater than that of the database column, the ABAP field may contain values for which there is not enough space in the database column. This can produce other cases: The concrete data value in ABAP finds space in the database column, or not.

If the ABAP field is at most as long as the database column, there is always space for the ABAP value in the database column.

Some types, such as numeric columns, expect values in a particular format. This is particularly important in connection with character types, for example, when you want to write an ABAP character field (type C) into an integer column.

Native SQL for Oracle

Native SQL for Informix

Native SQL for DB2 Common Server

http://help.sap.com/saphelp_nw04/helpdata/en/fc/eb3b8b358411d1829f0000e829fbfe/content.htm

[Former Member]

Thanks Gyus..

Atlast I got the Solution..

If any one have the same problem please feel free to contact me.

Regard.

Anees

+91 9886358645

[Former Member]

Hi Annee,

I got the same issue.

could you please tell me how the yours has been resolved?

Thanks a lot

Jeannie

[Former Member]

i gave sample pro of native SQL

REPORT zmpq_sap_to_oracle.

TABLES: zmpq_cc_all_job,dbcon.

DATA: BEGIN OF i_job OCCURS 0.

INCLUDE STRUCTURE zmpq_cc_all_job.

DATA: END OF i_job.

DATA sap_web LIKE dbcon-con_name VALUE 'WEBOS'.

START-OF-SELECTION.

SELECT * FROM zmpq_cc_all_job INTO TABLE i_job.

EXEC SQL.

SET CONNECTION :sap_web

ENDEXEC.

EXEC SQL.

CONNECT TO :sap_web

ENDEXEC.

IF sy-subrc <> 0.

MESSAGE 'NOT Connected..!!' TYPE 'S'.

LEAVE PROGRAM.

ENDIF.

EXEC SQL.

INSERT INTO noti_details (QMNUM) VALUES ('8888888')

ENDEXEC.