SQL-Statement zu lang für String
6 Beiträge
•
Seite 1 von 1
6 Beiträge
Seite 1 von 1
Beitrag
von mareikemei92 (ForumUser / 49 / 19 /
0
)
»
Hallo,
Ich bin aktuell dabei, einen INSERT in eine MS SQL Datenbank aus dem SAP heraus zu entwickeln. Vorher wurde auf eine Oracle-DB exportiert, also besteht die Schnittstelle an sich schon.
In der Vergangenheit wurde mit Native SQL der INSERT-Befehl im SAP gemacht. Nun haben wir das Problem, dass wir auch Datumsfelder mit exportieren, die auch leer sein können. Standardmäßig wird in der MS SQL das Datumsfeld auf den 01-01-1900 gesetzt, wenn die Variable im SAP leer ist. Das Datumsfeld lässt sich nur auf null setzen, wenn im Native SQL explizit 'NULL' in den Ausdruck geschrieben wird. Wenn man die Variable mit dem Wert 'NULL' oder '00000000' füllt, geht es leider nicht.
Nun hatten wir die Idee, das SQL-Statement dynamisch zu gestalten und dafür die Klasse cl_sql_statement und die Methode execute_update zu nutzen. Problem ist hierbei, dass der SQL-Befehl zu lang ist, da der String nur 255 Zeichen fassen kann.
Also wollte ich mit Parametern arbeiten.
Mein Testbeispiel sieht so aus:
Leider liefert mir die Exception den internen Fehler 12.
Hat jemand Erfahrung damit und eine Idee, wie dieses Problem lösbar ist? Vielleicht denke ich auch viel zu kompliziert und es gibt eine ganz einfache Lösung für das Problem mit dem Datum..
Ich hoffe auf eure Hilfe! 😊
Viele Grüße,
Mareike
Ich bin aktuell dabei, einen INSERT in eine MS SQL Datenbank aus dem SAP heraus zu entwickeln. Vorher wurde auf eine Oracle-DB exportiert, also besteht die Schnittstelle an sich schon.
In der Vergangenheit wurde mit Native SQL der INSERT-Befehl im SAP gemacht. Nun haben wir das Problem, dass wir auch Datumsfelder mit exportieren, die auch leer sein können. Standardmäßig wird in der MS SQL das Datumsfeld auf den 01-01-1900 gesetzt, wenn die Variable im SAP leer ist. Das Datumsfeld lässt sich nur auf null setzen, wenn im Native SQL explizit 'NULL' in den Ausdruck geschrieben wird. Wenn man die Variable mit dem Wert 'NULL' oder '00000000' füllt, geht es leider nicht.
Nun hatten wir die Idee, das SQL-Statement dynamisch zu gestalten und dafür die Klasse cl_sql_statement und die Methode execute_update zu nutzen. Problem ist hierbei, dass der SQL-Befehl zu lang ist, da der String nur 255 Zeichen fassen kann.
Also wollte ich mit Parametern arbeiten.
Mein Testbeispiel sieht so aus:
Code: Alles auswählen.
DATA(lo_sql_statement) = NEW cl_sql_statement( ).
LOOP AT gt_kdauf INTO DATA(ls_kdauf).
lv_sql_statement = |INSERT INTO ASP_KDAUF (SYSID, KDAUF, KDPOS, ETENR, MATNR) VALUES (?, ?, ?, ?, ?)|.
lo_sql_statement->set_param( REF #( gv_sysid ) ).
lo_sql_statement->set_param( REF #( ls_kdauf-kdauf ) ).
lo_sql_statement->set_param( REF #( ls_kdauf-kdpos ) ).
lo_sql_statement->set_param( REF #( ls_kdauf-etenr ) ).
lo_sql_statement->set_param( REF #( ls_kdauf-matnr ) ).
TRY.
lo_sql_statement->execute_update( lv_sql_statement ).
CATCH cx_sql_exception INTO lr_sql_exception.
ENDTRY.
ENDLOOP.
Hat jemand Erfahrung damit und eine Idee, wie dieses Problem lösbar ist? Vielleicht denke ich auch viel zu kompliziert und es gibt eine ganz einfache Lösung für das Problem mit dem Datum..
Ich hoffe auf eure Hilfe! 😊
Viele Grüße,
Mareike
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Mit Parametern bei Native SQL zu arbeiten, ist immer empfehlenswert. Ohne Parameter ist das SQL-Statement eine große Sicherheitslücke (SQL-Injection).Also wollte ich mit Parametern arbeiten.
Eine möglich Lösung für das Problem mit dem NULL-Wert wäre das SQL-Statement aufzuteilen. Wenn der Datumswert den ABAP-Initialwert hat ('00000000'), die Datumsspalte nicht in das INSERT-Statement mit aufzunehmen. Dann ist dieses NULL. Wenn der Datumswert keinen Initialwert besitzt, wird dieses in das INSERT-Statement mit aufgenommen.
Publikationen:
Qualitätsmanagement in der ABAP-Entwicklung,
Why we should take care about clean code
ABAP, Java, JavaScript
GitHub
Qualitätsmanagement in der ABAP-Entwicklung,
Why we should take care about clean code
ABAP, Java, JavaScript
GitHub
Beitrag
von mareikemei92 (ForumUser / 49 / 19 /
0
)
»
Hallo jocoder,
Danke für die Antwort. Auf die Idee, das SQL-Statement bei leerem Datum einfach wegzulassen, bin ich noch nicht gekommen.. werde ich so probieren :)
Bei der Methode mit den Parametern funktioniert mein Statement nur leider gar nicht.. Die Exception enthält immer den internen Fehlercode 12..
Danke für die Antwort. Auf die Idee, das SQL-Statement bei leerem Datum einfach wegzulassen, bin ich noch nicht gekommen.. werde ich so probieren :)
Bei der Methode mit den Parametern funktioniert mein Statement nur leider gar nicht.. Die Exception enthält immer den internen Fehlercode 12..
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
Ich bin auch schon auf dieses Problem gestoßen.
Meine Lösung sah so aus, dass ich eine "Blockverarbeitung" drumherum gebaut habe. Das SQL-Statement selbst umfasst zum Beispiel die Variablen für 10 - 20 Datensätze und wird dann halt mehrfach aufgerufen, je nachdem wieviele Datensätze insgesamt übertragen werden sollen. Für den "restlichen Überhang" am Ende gibt es noch ein Einzelsatz-Statement und das wars.
EDIT:
Obwohl, 255 Zeichen klingt für mich jetzt etwas wenig. Mein Problem war eher, dass die gesamt zu übertragende Datenmenge zu groß war und der MSSQL-Server ein Redo-Log von mehreren GB erzeugt hatte. Durch die Blockverarbeitung konnte ich "zwischendrin" immer wieder mal ein COMMT TRANSACTION streuen, damit das Ganze nicht zu sehr ausgeartet ist.
Meine Lösung sah so aus, dass ich eine "Blockverarbeitung" drumherum gebaut habe. Das SQL-Statement selbst umfasst zum Beispiel die Variablen für 10 - 20 Datensätze und wird dann halt mehrfach aufgerufen, je nachdem wieviele Datensätze insgesamt übertragen werden sollen. Für den "restlichen Überhang" am Ende gibt es noch ein Einzelsatz-Statement und das wars.
EDIT:
Obwohl, 255 Zeichen klingt für mich jetzt etwas wenig. Mein Problem war eher, dass die gesamt zu übertragende Datenmenge zu groß war und der MSSQL-Server ein Redo-Log von mehreren GB erzeugt hatte. Durch die Blockverarbeitung konnte ich "zwischendrin" immer wieder mal ein COMMT TRANSACTION streuen, damit das Ganze nicht zu sehr ausgeartet ist.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von mareikemei92 (ForumUser / 49 / 19 /
0
)
»
Aktuell wird es bei uns so gemacht, dass über eine interne Tabelle geloopt wird und jede Zeile einzeln weg geschrieben wird. In meinem Code-Beispiel oben habe ich jedes Feld in der wegzuschreibenden Struktur einzeln als Parameter gesetzt.a-dead-trousers hat geschrieben: ↑10.02.2020 11:23Ich bin auch schon auf dieses Problem gestoßen.
Meine Lösung sah so aus, dass ich eine "Blockverarbeitung" drumherum gebaut habe. Das SQL-Statement selbst umfasst zum Beispiel die Variablen für 10 - 20 Datensätze und wird dann halt mehrfach aufgerufen, je nachdem wieviele Datensätze insgesamt übertragen werden sollen. Für den "restlichen Überhang" am Ende gibt es noch ein Einzelsatz-Statement und das wars.
EDIT:
Obwohl, 255 Zeichen klingt für mich jetzt etwas wenig. Mein Problem war eher, dass die gesamt zu übertragende Datenmenge zu groß war und der MSSQL-Server ein Redo-Log von mehreren GB erzeugt hatte. Durch die Blockverarbeitung konnte ich "zwischendrin" immer wieder mal ein COMMT TRANSACTION streuen, damit das Ganze nicht zu sehr ausgeartet ist.
Wie schreibt man ganze Tabellen in einem Statement auf die Datenbank? Ich habe mit SQL aus ABAP heraus kaum Erfahrung und ergoogel mir gerade alles selbst zusammen..
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
Ich verwende dafür sog. "prepared Statements" die man mehrmals aufrufen kann. Erzeugt werden diese durch die "Überklasse" zu CL_SQL_STATEMENT, die CL_SQL_CONNECTION mit PREPARE_STATEMENT.
Wenn du eine Tabelle (oder Struktur) an das Statement-Objekt zur mehrfach-Verarbeitung übergeben möchtest, musst du sicherstellen, dass die Anzahl der Spalten der Anzahl der Variablen in deinem Statement entspricht. In der tabellarischen Verarbeitung wird das Statement dann je Zeile in deiner Datentabelle einmal mit den zugehörigen Werten übertragen.
Das Ganze kann je nach Datenmenge mitunter sehr inperformant werden, weil jeder Datensatz am Ende einzeln übertragen wird und auf Seiten der Datenbank verarbeitet werden muss. Daher hab ich mir eine eigene "Blockverarbeitung" gebaut wo das Statement so ausgestaltet ist, dass mehr als ein Datensatz darin vorkommt. Natürlich muss man dann beim Befüllen der Variablen darauf achten, dass man die korrekte Anzahl an SET_PARAM-Aufrufen pro Statement und Tabellenzeile durchführt.
Beim CL_SQL_PREPARED_STATEMENT gibts es noch zusätzlich die Methode
CLEAR_PARAMETERS mit der man die zuvor eingetragenen Werte entfernen und wieder von vorne mit dem Befüllen beginnen kann. Somit kann man das Statement mehrmals verwenden. Vom Prinzip her sollten "prepared Statements" auch Datenbankseitig etwas performanter sein, weil die Syntax-Prüfung nur einmal erfolgt. Ob das auch für die SAP-Implmentierung hin zu MSSQL der Fall ist, kann ich leider weder bestätigen noch widerlegen.
Wenn du eine Tabelle (oder Struktur) an das Statement-Objekt zur mehrfach-Verarbeitung übergeben möchtest, musst du sicherstellen, dass die Anzahl der Spalten der Anzahl der Variablen in deinem Statement entspricht. In der tabellarischen Verarbeitung wird das Statement dann je Zeile in deiner Datentabelle einmal mit den zugehörigen Werten übertragen.
Das Ganze kann je nach Datenmenge mitunter sehr inperformant werden, weil jeder Datensatz am Ende einzeln übertragen wird und auf Seiten der Datenbank verarbeitet werden muss. Daher hab ich mir eine eigene "Blockverarbeitung" gebaut wo das Statement so ausgestaltet ist, dass mehr als ein Datensatz darin vorkommt. Natürlich muss man dann beim Befüllen der Variablen darauf achten, dass man die korrekte Anzahl an SET_PARAM-Aufrufen pro Statement und Tabellenzeile durchführt.
Beim CL_SQL_PREPARED_STATEMENT gibts es noch zusätzlich die Methode
CLEAR_PARAMETERS mit der man die zuvor eingetragenen Werte entfernen und wieder von vorne mit dem Befüllen beginnen kann. Somit kann man das Statement mehrmals verwenden. Vom Prinzip her sollten "prepared Statements" auch Datenbankseitig etwas performanter sein, weil die Syntax-Prüfung nur einmal erfolgt. Ob das auch für die SAP-Implmentierung hin zu MSSQL der Fall ist, kann ich leider weder bestätigen noch widerlegen.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Seite 1 von 1
Vergleichbare Themen
2
Antw.
Antw.
341
Views
Views
3
Antw.
Antw.
3906
Views
Views
1
Antw.
Antw.
3869
Views
Views
Der Arbeitsbereich ist nicht lang genug
von SAP_ENTWICKLER » 02.07.2015 08:39 • Verfasst in ABAP® Core
von SAP_ENTWICKLER » 02.07.2015 08:39 • Verfasst in ABAP® Core
6
Antw.
Antw.
11105
Views
Views
1
Antw.
Antw.
2588
Views
Views
Arbeitsbereich nicht lang genug bei INNER JOIN
von RickBNK » 03.02.2012 12:00 • Verfasst in ABAP® für Anfänger
von RickBNK » 03.02.2012 12:00 • Verfasst in ABAP® für Anfänger
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.