Abap und Native SQL

Abap und Native SQL

Hallo,

Wie ist eure Erfahrung mit ABAP und Native SQL bei fremden Server/Datenbank?
Ich habe mich neu damit befasst und doch einiges anderes feststellen müssen, gegenüber der Syntax der Datenbank-Hersteller.

Als Beispiel für connect bei MSSQL:
DATA: gc_dbs TYPE string,
database TYPE string.
MOVE 'LOHN' TO database.
MOVE 'Driver=SQL Server;server=192.168.13.46;database=lohn;uid:adm;pwd=adm;' TO gc_dbs.
CONNECT using :gc_dbs as :database

Funktionniert in ABAP nicht, hier muss über DBCO eine Verbindung angelegt werden und dann erst darauf verweisen.

Anders Beispiel, prüfen ob eine Tabelle schon angelegt ist:
IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id =
OBJECT_ID(N'[dbo].[zt_bland]') AND type in (N'U'))
EXEC SQL.
CREATE TABLE [dbo].[zt_bland].......
ENDEXEC.

geht leider nicht

Anders Beispiel, prüfen ob eine Tabelle vorhanden ist, damit Sie gedroppt werden kann:

IF EXISTS (SELECT * FROM sys.objects WHERE object_id =
OBJECT_ID(N'[dbo].[zt_bland]') AND type in (N'U'))
EXEC SQL.
DROP TABLE [dbo].[zt_bland]
ENDEXEC.

geht leider nicht

Ich habe zwar alle wesentliche Funktionen abgebildet bekommen, musste sehr viel recherchieren.
Dieses Verhalten ist bei MSSQL, MYSQL und ORACLE, wahrscheinlich auch DB2 und andere.

Macht dies Sinn?
Wie habt Ihr die Prüfung ob Tabelle vorhanden ist oder nicht elegant gelöst.

Gerne stelle ich auch das ganze Programm zur Ansicht zur Verfügung!

Ich freue mich auf eine rege Diskussion und dadurch interkulturelles Lernen

Re: Abap und Native SQL

Was auch immer der Grund dafür sein...
Auf jeden Fall ADBC verwenden:
https://help.sap.com/doc/abapdocu_751_i ... enadbc.htm

Re: Abap und Native SQL

DeathAndPain hat geschrieben:Warum in aller Welt willst Du in ABAP Tabellen droppen?!? Native SQL ist die absolute Notlösung; in aller Regel braucht man das überhaupt nicht. Insofern denke ich, dass Deine Energie in eine völlig falsche Richtung geht.

Wenn es nur darum geht festzustellen, ob eine Tabelle existiert: https://www.abapforum.com/forum/viewtop ... =1&t=16537

Ich will doch keine SAP-Tabelle droppen!
Es geht darum die Erfahrung mit SQL und anderen Programmiersprachen auch in ABAP umzusetzen und die bisherige Codierung
und sinnvolle Befehle zur Verfügung zu haben, falls benötigt.
Deshalb wird eine andere MSSQL-Umgebung angesteuert!
Übung macht den Meister!

Re: Abap und Native SQL

Tron hat geschrieben:Moin.
etwas einfacher läßt sich die Existenz einer Tabelle so bestimmen:

Code: Alles auswählen.

data L_TABNAME type TABNAME.
Select single tabname from DD02L into L_TABNAME where Tabname = 'XXX' and TABCLASS NE 'INTTAB'.

SAP führt doppelt Buch über Tabellen.

Danke für die Info, derzeit spiele/experimentiere ich auf einen nicht-SAP-MSSQL-Server!
Erfahrungsaustausch ist immer gut, jeder kann dadurch lernen!

Re: Abap und Native SQL

Hallo *,

ich glaube cgreiner möchte schlicht auf eine andere Datenbank bzw. ein anderes Datenbank-Management-System zugreifen und nicht auf die Datenbank des SAP-System, in dem er sich bewegt. Die Anforderung begegnet mir auch immer wieder, wenn Daten aus einer externen Quelle angezapft werden sollen. Und in diesen Fällen kommt man halt nur mit NativeSQL weiter oder aber eben den bereits erwähnten Klassen aus dem Umfeld der ADBC.

In der heutigen Zeit würde man sicherlich vor diese externe Datenbanken einen Application Server stellen, der wiederum per Web-Service/OData-Service oder sonstigem einen Zugriff ermöglicht. Aber man kann ja auch mal schlanke, pragmatische Lösungen ins Auge fassen

Einzige Voraussetzung dafür dürfte sein, dass dem SAP-Kernel die entsprechende DBSL für das externe DBMS zur Verfügung steht, sonst wird das wohl schwierig.

Viele Grüße
Lars

Re: Abap und Native SQL

Ja, aber das ist doch reines Theorycrafting ohne Praxisbezug. ABAP ist die Programmiersprache für SAP-Anwendungen im SAP-Universum. Für externe Anwendungen ist es die falsche Wahl, da machste besser Java oder Python oder was auch immer. Nun kannste Dir aus akademischen Gründen erschließen, wie man es auch in ABAP hinbekommt, nur kannste mit dem derart erlangten Wissen hinterher nichts anfangen, weil sinnvolle produktive Anwendungen in ABAP eben nicht mit fremden Datenbanken herumspielen, so dass es Dir nichts nützt, Dir erarbeitet zu haben,wie es theoretisch gehen würde.

black_adept hat geschrieben:Das wirklich Einzige, wo ich das jemals sinnvoll! gebraucht habe war um ein Select ohne Berücksichtigung von Groß- oder Kleinschreibung hinzubekommen, weil das halt mit OPEN_SQL nicht geht.

In früheren Zeiten habe ich auch gerne mal einen Datenbank-Hint an meine SELECTs rangehängt, um dem Optimierer einen Tipp zu geben, mit welcher der gejointen Tabellen er anfangen soll. Das verbaut auch nichts, da der Hint bei einem Datenbankwechsel einfach nur unwirksam werden würde, ohne aber zu stören. Mache ich aber auch schon seit Jahren nicht mehr wegen unnötig.