exec sql mit dynamischen Tabellennamen
11 Beiträge
•
Seite 1 von 1
11 Beiträge
Seite 1 von 1
Hallo,
erst hatte ich das Problem, dass ich in open sql die Gross~/Kleinschreibung nicht ignorieren konnte.
Mittels dieses Posts ist es mir verzüglich gelungen dieses problem zu lösen
http://www.apentia-forum.com/viewtopic. ... t=exec+sql
(exec sql .... end exec. )
Mein aktuelles Programm sied demzufolge so aus:
Nun stehe ich aber vor dem weiteren Problem, dass ich gerne Tabellennamen, sowie Where-Klaueln dynamisch zur laufzeit, in einer Variabele, spezifizieren möchte.
In Open sql gäbe es ja die Möglichkeit wie z.B:
select from (tabellennamenvariabele) into struktur where .... .
Nun stellt sich mir ( und meinem cheff) das Problem wie sich das Problem mt der Gross/Kleinschreibung und den dynamischen Tabellennamen gemeinsam lösen lässt.
Ich würde mich sehr über eure Hilfe freuen
Gruss Sebastian
erst hatte ich das Problem, dass ich in open sql die Gross~/Kleinschreibung nicht ignorieren konnte.
Mittels dieses Posts ist es mir verzüglich gelungen dieses problem zu lösen
http://www.apentia-forum.com/viewtopic. ... t=exec+sql
(exec sql .... end exec. )
Mein aktuelles Programm sied demzufolge so aus:
Code: Alles auswählen.
EXEC SQL.
OPEN c2 FOR
SELECT * FROM ZADDRESSEN
WHERE upper( VORNAME ) like upper( :searchtmp )
OR upper( Nachname ) like upper( :searchtmp )
ENDEXEC.
DO.
EXEC SQL.
FETCH NEXT c2 INTO :line
ENDEXEC.
IF sy-subrc <> 0.
EXIT.
ELSE.
append line to me->tabelle .
ENDIF.
ENDDO.
EXEC SQL.
CLOSE c2
ENDEXEC.
In Open sql gäbe es ja die Möglichkeit wie z.B:
select from (tabellennamenvariabele) into struktur where .... .
Nun stellt sich mir ( und meinem cheff) das Problem wie sich das Problem mt der Gross/Kleinschreibung und den dynamischen Tabellennamen gemeinsam lösen lässt.
Ich würde mich sehr über eure Hilfe freuen
Gruss Sebastian
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Um wieviel Tabellen soll es den hier gehen???
10, 100 oder 1000????
Bei 2 oder 3 Tabellen lohnt sich der Aufwand nicht unbedingt.
Da es sich bei euren Tabellen um Kundeneigene Tabellen handelt ('Z....') verstehe ich nicht, warum ihr nicht die Tabellen entweder gleich in UPPER-CASE füllt oder pro UPPER-CASE-Feld ein zusätzliches FELD einfügt und beim füllen darauf achtet???
Siehe hierzu Tabelle MAKT, die Felder MAKTX und MAKTG.
Man kann sich auch Probleme machen, die vorher nicht da waren.
10, 100 oder 1000????
Bei 2 oder 3 Tabellen lohnt sich der Aufwand nicht unbedingt.
Da es sich bei euren Tabellen um Kundeneigene Tabellen handelt ('Z....') verstehe ich nicht, warum ihr nicht die Tabellen entweder gleich in UPPER-CASE füllt oder pro UPPER-CASE-Feld ein zusätzliches FELD einfügt und beim füllen darauf achtet???
Siehe hierzu Tabelle MAKT, die Felder MAKTX und MAKTG.
Man kann sich auch Probleme machen, die vorher nicht da waren.
Beitrag
von black_adept (Top Expert / 4080 / 125 /
934
)
»
Hi Sebastian,
es kommt leider keine Antwort zur Frage - aber evtl. eine Alternative.
Dasselbe Problem das du da beschreibst hat SAP selber ja auch im Materialstamm bzw. der Kurzbezeichnung eines Materials.
Dort hat man das Problem so gelöst ( und an einigen anderen Ecken hab ich das auch schon gesehen), dass außer der eigentlichen Bezeichnung des Materials in diesem Fall auch die Bezeichnung in Großbuchstaben konveriert abgespeichert wird. ( Siehe Tabelle MAKT ).
Was spricht denn dagegen, dass ihr an eure eigene Z-Tabelle auch zwei weitere Felder dranhängt, die den Vor- und Nachnamen in Großbuchstaben nochmal spiegeln. Und da es sich um eine Z-Tabelle handelt könnt ihr ja auch die Pflegebausteine für diese Tabelle leicht anpassen, indem eben auch die beiden Zusatzfelder versorgt werden.
Wenn ihr so vorgeht, könnt ihr danach völlig ohne EXEC-SQL auskommen und euer System ist auch gegen einen später evtl. mal vorkommenden DB-Wechsel resistent.
es kommt leider keine Antwort zur Frage - aber evtl. eine Alternative.
Dasselbe Problem das du da beschreibst hat SAP selber ja auch im Materialstamm bzw. der Kurzbezeichnung eines Materials.
Dort hat man das Problem so gelöst ( und an einigen anderen Ecken hab ich das auch schon gesehen), dass außer der eigentlichen Bezeichnung des Materials in diesem Fall auch die Bezeichnung in Großbuchstaben konveriert abgespeichert wird. ( Siehe Tabelle MAKT ).
Was spricht denn dagegen, dass ihr an eure eigene Z-Tabelle auch zwei weitere Felder dranhängt, die den Vor- und Nachnamen in Großbuchstaben nochmal spiegeln. Und da es sich um eine Z-Tabelle handelt könnt ihr ja auch die Pflegebausteine für diese Tabelle leicht anpassen, indem eben auch die beiden Zusatzfelder versorgt werden.
Wenn ihr so vorgeht, könnt ihr danach völlig ohne EXEC-SQL auskommen und euer System ist auch gegen einen später evtl. mal vorkommenden DB-Wechsel resistent.
Halo,
also die Anzahl der Tabellen wird sich so auf mehrere hundert bis tausend belaufen können. Und es ist nunmal der Wunsch, dass bei der Anzeige von Daten nicht alles gross/kleingeschrieben ist.
Das mit den Doppelten Feldern wäre schon eine Lösung, wobei hier allerdings leider der unschöne Effekt des doppelten Platzverbrauchs besteht, was bei größerer Menge an Daten sicher nicht förderlich für die Performance wäre
Mit der Vermeidung des exec sql's hast du schon Recht, vielleicht kennt ja noch jemand einen Weg die Gross~/Kleinschreibung anderweitig halbwegs performant zu umgehen?
Gruss und Danke trotzdem Sebastian
also die Anzahl der Tabellen wird sich so auf mehrere hundert bis tausend belaufen können. Und es ist nunmal der Wunsch, dass bei der Anzeige von Daten nicht alles gross/kleingeschrieben ist.
Das mit den Doppelten Feldern wäre schon eine Lösung, wobei hier allerdings leider der unschöne Effekt des doppelten Platzverbrauchs besteht, was bei größerer Menge an Daten sicher nicht förderlich für die Performance wäre
Mit der Vermeidung des exec sql's hast du schon Recht, vielleicht kennt ja noch jemand einen Weg die Gross~/Kleinschreibung anderweitig halbwegs performant zu umgehen?
Gruss und Danke trotzdem Sebastian
Hallo mailmal,
wenn Ihr wirklich mehrere hundert Tabellen habt, in denen immer wieder Vorname und Nachname (?!? : oder war das nur ein Beispiel? ) in Groß-/Kleinschreibung auftritt, erscheint es mir sinnvoll, sich mal Gedanken um einen relationen Aufbau mit einer Tabelle für Namen und einer Referenz auf die Namenstabelle in den anderen Tabellen zu machen.
Schreib doch bitte, soweit möglich, ein wenig mehr über Euer Szenario. Vielleicht gibt es ja Möglichleiten für einen anderen Ansatz.
wenn Ihr wirklich mehrere hundert Tabellen habt, in denen immer wieder Vorname und Nachname (?!? : oder war das nur ein Beispiel? ) in Groß-/Kleinschreibung auftritt, erscheint es mir sinnvoll, sich mal Gedanken um einen relationen Aufbau mit einer Tabelle für Namen und einer Referenz auf die Namenstabelle in den anderen Tabellen zu machen.
Schreib doch bitte, soweit möglich, ein wenig mehr über Euer Szenario. Vielleicht gibt es ja Möglichleiten für einen anderen Ansatz.
Gruß
Ereglam
May the Force be with your code
|| .| |.|| | .... . ..|. ||| .|. |.|. . |... . .|| .. | .... |.|| ||| ..| .|. |.|. ||| |.. .
Ereglam
May the Force be with your code
|| .| |.|| | .... . ..|. ||| .|. |.|. . |... . .|| .. | .... |.|| ||| ..| .|. |.|. ||| |.. .
HI,
ja es war mehr nur ein Beispiel.
In diesem Szenario geht es darum, eine Art Inventarisierung zu erstellen, bei denen jeder Typ des Inventars beliebige Werte, und Verkn�pfungen zu beliebigen anderen Inventar-Gegenst�nden haben soll.
Und um zu vermeiden, dass dann eine Riesige Tabelle mit allen Typen dabei ist soll F�r jeden typ eine eigene Tabelle angelegt werden. Da wir schon Erfahrungen mit einer sehr gro�en Tabelle gemacht haben und dass dann doch sehr zu lasten der Performance geht, denn es sollen auch suchfunktionen m�glich sein und so.
ja es war mehr nur ein Beispiel.
In diesem Szenario geht es darum, eine Art Inventarisierung zu erstellen, bei denen jeder Typ des Inventars beliebige Werte, und Verkn�pfungen zu beliebigen anderen Inventar-Gegenst�nden haben soll.
Und um zu vermeiden, dass dann eine Riesige Tabelle mit allen Typen dabei ist soll F�r jeden typ eine eigene Tabelle angelegt werden. Da wir schon Erfahrungen mit einer sehr gro�en Tabelle gemacht haben und dass dann doch sehr zu lasten der Performance geht, denn es sollen auch suchfunktionen m�glich sein und so.
Hallo,
es sieht doch ein wenig danach aus, daß man sich noch mal über das Gedanken machen sollte, was man wirklich will.
Sprich: Was soll am Ende auf irgendeiner Liste oder Auswertung stehen???
Vielleicht ist es auch Organisationsverwaltung, Raumplanung, Schulungsplanung, Overheadprojektorverwaltung, Kundenbeziehungen ...
Überall sind die Objekte und Typen in einigen wenigen großen Tabellen gespeichert mit den schon oben erwähnten Redundanzen und Zusatzfeatures (die sich auch SAP-Programmierer für ihre Spezialfälle ausgedacht haben).
Wenn Du Lust hast, schildere Deine Anforderungen noch einmal genauer. Vielleicht hat ja jemand eine Idee, das Ganze mit einem Standardmodul zu verwalten.
Man hat ja die Freiheit, Teilmodule oder Teilfunktionsn zu nutzen, egal wie die Module eigentlich heißen, Hauptsache sie machen das was man will.
(Die Lösung mit n+1 Z-Tabellen mit dynamischem Zugriff und dann noch exec sql hat nicht wirklich was prickelndes ...
)
Gruß
babap
es sieht doch ein wenig danach aus, daß man sich noch mal über das Gedanken machen sollte, was man wirklich will.
Sprich: Was soll am Ende auf irgendeiner Liste oder Auswertung stehen???
Irgendwie sieht das nach Anlagen, Kostenstellen, Technischen Plätzen, Equipments, Invest-Gütern oder sowas ähnlichem aus.In diesem Szenario geht es darum, eine Art Inventarisierung zu erstellen, bei denen jeder Typ des Inventars beliebige Werte, und Verkn�pfungen zu beliebigen anderen Inventar-Gegenst�nden haben soll.
Vielleicht ist es auch Organisationsverwaltung, Raumplanung, Schulungsplanung, Overheadprojektorverwaltung, Kundenbeziehungen ...
Überall sind die Objekte und Typen in einigen wenigen großen Tabellen gespeichert mit den schon oben erwähnten Redundanzen und Zusatzfeatures (die sich auch SAP-Programmierer für ihre Spezialfälle ausgedacht haben).
Wenn Du Lust hast, schildere Deine Anforderungen noch einmal genauer. Vielleicht hat ja jemand eine Idee, das Ganze mit einem Standardmodul zu verwalten.
Man hat ja die Freiheit, Teilmodule oder Teilfunktionsn zu nutzen, egal wie die Module eigentlich heißen, Hauptsache sie machen das was man will.
(Die Lösung mit n+1 Z-Tabellen mit dynamischem Zugriff und dann noch exec sql hat nicht wirklich was prickelndes ...
)Gruß
babap
Hi,
Also es geht um Server, Ip-Addressden, installierte anwendungen Netztechnix...
Das Datenmodell das bei raus kommen soll soll es Möglich machen Eben diese Typen direkt aus dem programm heraus ( ohne Entwickleriengriff ) anzulegen, ihnen Grundeigendschaften wie name kaufdatum... zu geben und sie zu beliegig vielen anderen Typen in verbindung zu setzen ( Server -> Ip-Addresse, Switch->Server , Server->Switch....) und es soll eben möglich sein Über alle Werte in allen Benötigten Tabellen suchen zu können, ala "alle serber bei denen 'der Peter' in der Notiz auftritt".
Der Notfalls muss es halt so gelöst werden, dass wirklich alle Felder doppelt angelegt werden in denen Text Vorkommt aber es kann doch einfach net sein dass es im "allmächtigen sap netweaver ( version 6.40) keineen weg gibt wie man dynamisch/performant Tabellennamen abgeben, sowie bei sql selects die Gross/kleinschreibung ignorieren kann.
Ps. auf die "Tipps" von diversen Gästen könnte man hier ruhig verzichten, es kann ja sein, dass ihr ein grosses mitteilungbedürfniss habt und nicht so die powerknolege in abap habe aber desshalb muss der thread doch nicht gleich zugeflamed werden mit beiträgen die eher wenig nützlch sind.
pps. Ich möchte aber allen Danken die Produktiv und hilfreich her betragen
Danke Sebastian
Also es geht um Server, Ip-Addressden, installierte anwendungen Netztechnix...
Das Datenmodell das bei raus kommen soll soll es Möglich machen Eben diese Typen direkt aus dem programm heraus ( ohne Entwickleriengriff
) anzulegen, ihnen Grundeigendschaften wie name kaufdatum... zu geben und sie zu beliegig vielen anderen Typen in verbindung zu setzen ( Server -> Ip-Addresse, Switch->Server , Server->Switch....) und es soll eben möglich sein Über alle Werte in allen Benötigten Tabellen suchen zu können, ala "alle serber bei denen 'der Peter' in der Notiz auftritt".Der Notfalls muss es halt so gelöst werden, dass wirklich alle Felder doppelt angelegt werden in denen Text Vorkommt aber es kann doch einfach net sein dass es im "allmächtigen sap netweaver ( version 6.40
) keineen weg gibt wie man dynamisch/performant Tabellennamen abgeben, sowie bei sql selects die Gross/kleinschreibung ignorieren kann.Ps. auf die "Tipps" von diversen Gästen könnte man hier ruhig verzichten, es kann ja sein, dass ihr ein grosses mitteilungbedürfniss habt und nicht so die powerknolege in abap habe aber desshalb muss der thread doch nicht gleich zugeflamed werden mit beiträgen die eher wenig nützlch sind.
pps. Ich möchte aber allen Danken die Produktiv und hilfreich her betragen
Danke Sebastian
Hallo,
ganz egal, wie nützlich oder eher nebensächlich die Tipps auch sind, sie kommen sicherlich von Herzen.
Die Struktur, die gerade eben beschrieben wurde, ist sehr komplex, und mit "Bordmitteln" wohl nicht so einfach zu lösen. (Also auf ans Werk).
Mir ist dabei aber noch was eingefallen.
Es ist nach meiner Erfahrung bisher immer problematisch gewesen, auf Felder zu selektieren, die Texte, Adressen, Namen, Anschriften oder etwas Ähnliches im "zusammengetippten Freiformat" enthalten.
Der eine schreibt mit SS, der andere ß, wieder einer zusammen und andere auseinader mit Abkürzungen, Umlauten oder ohne ...
Sprich, eigentlich kann die Selektion auf Texte nur schief gehen. Mein Tip: bestimmte Attribute "rausziehen" und in eigene Felder "packen", dann fällt auch das Problem mit der Groß- bzw. Klein-Selektiererei weg.
Gerade für Adressen oder Standorte findet man doch Abbildungen im SAP-Standart.
Gruß
babap
ganz egal, wie nützlich oder eher nebensächlich die Tipps auch sind, sie kommen sicherlich von Herzen.
Die Struktur, die gerade eben beschrieben wurde, ist sehr komplex, und mit "Bordmitteln" wohl nicht so einfach zu lösen. (Also auf ans Werk).
Mir ist dabei aber noch was eingefallen.
Es ist nach meiner Erfahrung bisher immer problematisch gewesen, auf Felder zu selektieren, die Texte, Adressen, Namen, Anschriften oder etwas Ähnliches im "zusammengetippten Freiformat" enthalten.
Der eine schreibt mit SS, der andere ß, wieder einer zusammen und andere auseinader mit Abkürzungen, Umlauten oder ohne ...
Sprich, eigentlich kann die Selektion auf Texte nur schief gehen. Mein Tip: bestimmte Attribute "rausziehen" und in eigene Felder "packen", dann fällt auch das Problem mit der Groß- bzw. Klein-Selektiererei weg.
Gerade für Adressen oder Standorte findet man doch Abbildungen im SAP-Standart.
Gruß
babap
Beitrag
von black_adept (Top Expert / 4080 / 125 /
934
)
»
Hi Sebastian,
wie wäre es, wenn ihr alle Textfelder, in denen sowohl Klein- als auch Großschreibung vorkommen kann in eine andere Tabelle auslagert, die den Text sowohl in Klein- als auch in Großschreibung beinhaltet.
Und in die Tabellen, die z.B. die Notiz "... der Peter..." enthalten wird eben nur noch eine Referenz auf diese eure neue Texttabelle erstellt.
Wenn dann die Texttabelle noch ein paar Verwaltungsfelder hat ( z.B. wo kommt der Text her ) damit man später sinnvoll indexieren kann wäre dies so mein erster Lösungsansatz ohne lange drüber nachzudenken.
wie wäre es, wenn ihr alle Textfelder, in denen sowohl Klein- als auch Großschreibung vorkommen kann in eine andere Tabelle auslagert, die den Text sowohl in Klein- als auch in Großschreibung beinhaltet.
Und in die Tabellen, die z.B. die Notiz "... der Peter..." enthalten wird eben nur noch eine Referenz auf diese eure neue Texttabelle erstellt.
Wenn dann die Texttabelle noch ein paar Verwaltungsfelder hat ( z.B. wo kommt der Text her ) damit man später sinnvoll indexieren kann wäre dies so mein erster Lösungsansatz ohne lange drüber nachzudenken.
Hallo lieber anonymer gast,
1. Nicht alle Postings wurden gelöscht. Die meisten Topics wurden verschoben, da sie in einem anderen Forum besser aufgehoben waren.
2. Die Postings die gelöscht wurden, habe ich gelöscht und kein Moderator.
3. Dulden wir hier keine kontraproduktiven Bemerkungen jeglicher Art.
Solltest damit ein Problem haben oder den Drang verspühren Feedback zu geben, so würde ich dich bitten dies direkt an mich zu senden: Webmaster@abapforum.com
Schönen Tag noch.
Jan
1. Nicht alle Postings wurden gelöscht. Die meisten Topics wurden verschoben, da sie in einem anderen Forum besser aufgehoben waren.
2. Die Postings die gelöscht wurden, habe ich gelöscht und kein Moderator.
3. Dulden wir hier keine kontraproduktiven Bemerkungen jeglicher Art.
Solltest damit ein Problem haben oder den Drang verspühren Feedback zu geben, so würde ich dich bitten dies direkt an mich zu senden: Webmaster@abapforum.com
Schönen Tag noch.
Jan
Seite 1 von 1
Vergleichbare Themen
7
Antw.
Antw.
2627
Views
Views
Probleme mit dynamischen Tabellennamen
von DerDom » 16.08.2005 08:20 • Verfasst in ABAP® für Anfänger
von DerDom » 16.08.2005 08:20 • Verfasst in ABAP® für Anfänger
2
Antw.
Antw.
2977
Views
Views
8
Antw.
Antw.
3904
Views
Views
3
Antw.
Antw.
2165
Views
Views
tabellennamen und Variablennamen ändern
von kaim77 » 26.02.2013 16:47 • Verfasst in ABAP® für Anfänger
von kaim77 » 26.02.2013 16:47 • Verfasst in ABAP® für Anfänger
6
Antw.
Antw.
2641
Views
Views
Internen Tabellennamen dynamisch im Loop setzen
von kaim77 » 31.10.2018 11:52 • Verfasst in ABAP® für Anfänger
von kaim77 » 31.10.2018 11:52 • 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
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 9 Stunden von DeathAndPain 2 / 180
vor 9 Stunden von DeathAndPain 2 / 180
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 9 Stunden von DeathAndPain 2 / 180
vor 9 Stunden von DeathAndPain 2 / 180