[388] in sapr3-soft
Re: Passing data to R/3 through Oracle SQL*Net
daemon@ATHENA.MIT.EDU (cbbrowne@news.brownes.org (Christo)
Tue Sep 2 11:57:27 1997
To: sapr3-soft@MIT.EDU
Date: 2 Sep 1997 10:24:42 -0400
From: cbbrowne@news.brownes.org (Christopher B. Browne) (by way of SAP Moderator <cbbrowne@news.brownes.org>)
On 31 Aug 1997 20:24:58 -0400, Juhani Jaakola
<juhani.jaakola@pp.kolumbus.fi> posted:
>We are building an interface to R/3 in which another system writes data
>to an Oracle table, which an ABAP/4 program reads.
>Any experiences/issues using that technique?
A little...
>We design and create the table in R/3. Fields of type DATE are created
>as Oracle VARCHAR2(8) fields. Is there any way to use the Oracle DATE
>field type instead?
No.
R/3 uses data types that are universally available across all of the
available SQL implementations (e.g. - Oracle, Informix, Adabas, and
Microsoft's version of Sybase SQL server), and unfortunately, the
types available for dates have not always been uniformly implemented.
>R/3 creates most fields as NOT NULL fields. What is the best way to
>represent NULL values?
Some surrogate "Null" value; perhaps the string "NULL"?
>In what tablespace the table should be created? How do you specify that
>in R/3?
I'd suggest creating the tables from the R/3 side; this allows that
to be controlled from that side.
There seems to be some choice as to which table space transparent
tables go into; I've not been involved with DB admin work with
version 3, so I can't provide any wisdom as to the latest
recommendations.
>We are using R/3 3.0F on Oracle7 database.
The thing to keep in mind is that the underlying DBMS is *not*
being used as a database "manager," but rather as a simple
"repository" of information.
Controls are kept within R/3, including most sorts of validation.
No doubt much of this *could* be done using triggers or stored
procedures; unfortunately this can't be implemented the same way
across the supported platforms, so they choose *not* to use such
features.
Interpretation of dates would be a good example; if there are *any*
differences in the way the DBMSes handle their sundry native date
formats, this causes a problem in that it means SAP has to work
around these differences. Hence the use of the lowest common
denominator...
--
Christopher B. Browne, cbbrowne@hex.net, chris_browne@sdt.com
PGP Fingerprint: 10 5A 20 3C 39 5A D3 12 D9 54 26 22 FF 1F E9 16
URL: <http://www.hex.net/~cbbrowne/>
Bill Gates to his broker: "You idiot, I said $150 million on **SNAPPLE**!!!"
----------------------------------------------------
comp.soft-sys.business.sap is a moderated newsgroup.
Postings are archived and available from the
Realtime USA web site at http://www.realtimeusa.com
----------------------------------------------------
