Neu SQL prozeduren mit #temp Tabellen

[mvh]

Moin.
Erstens - in deinem Code brauchst Du keine Temp-Table, MAXIMAL Tabellen-Variable, aber auch hier meine Frage - wozu, da ist nur ein SELECT.
Zweitens - eine SP soll in Custom View NICHT benutzt werden, nur Funktionen sind erlaubt (und auch dort kannst Du eine Tabellen-Variable definieren)
Drittens - ein Forum ist nicht nur zum Schreiben da, sondern auch zum Lesen, Lernen, Verstehen und ggf. Akzeptieren.

 

[chx_de]

Uff! Hast du die vorherigen Antworten, die du hier erhalten hast überhaupt gelesen?

Das kannst du deshalb nicht speichern, weil zu dem Zeitpunkt, wenn du auf <Speichern> klickst kein #temp1 existiert.
Es gibt jetzt mehrere Möglichkeiten, wie du das umgehen kannst.
Das was ICH machen würde, habe ich in #13 beschrieben:
in der Wawi würde ich die eigene Übersicht als SELECT 'execute eazybusiness.dbo.spToci_JTL_Test @key' eingeben und nach dem dann erfolgreichen speichern: update dbo.tCustomerQuery set cQueryText='execute eazybusiness.dbo.spToci_JTL_Test @key' where convert(varchar(max), cQueryText ) = 'SELECT ''execute eazybusiness.dbo.spToci_JTL_Test @key'''

Jo habe ich. Und mir ist bewusst, dass es zum Zeitpunkt des Speicherns keine #temp gibt. Mir ist auch klar, dass dies der Fehler ist. Das ist aber für das abspeichern eigentlich total irrelevant --- also ob eine #temp existiert oder nicht. Hat ja bis zu Version XXX auch immer funktioniert.

- Umgehen könnte man das mit einer festen Tabelle ==> Nachteil bei mehreren gleichzeitigen Zugriffen auf die Tabelle, da die ja immer geleert werden müsste.
- Andere Alternative wäre @temp Tabellen Variablen ==> Nachteil ist, dass die nicht in weiteren Prozeduren zur Verfügung stehen und Probleme mit aggregierten Abfragen machen
- Meine Lösung ist auch die von dir beschriebene, dass ich dann einfach den Code direkt in die Datenbank schreibe.

Trotzdem Danke für die Antworten und die Mühe.

LG
Christian

 

[mh1]

- Umgehen könnte man das mit einer festen Tabelle ==> Nachteil bei mehreren gleichzeitigen Zugriffen auf die Tabelle, da die ja immer geleert werden müsste.

um Probleme, die beim gleichzeitigen Zugriff entstehen könnten bzw. das Locking kümmert sich doch der SQL-Server 🤔
Wenn der Zugriff also das Auslesen einer Tabelle zu Problemen führt (z.b. eine Art von Race Condition), dann ist dies meist ein guter Hinweis darauf, dass die Abfrage überdacht bzw. umgebaut werden muss (bitte nicht als Abwertung deiner SQL Kenntnisse verstehen, sondern nur als gut gemeinten Hinweis).

- Andere Alternative wäre @temp Tabellen Variablen ==> Nachteil ist, dass die nicht in weiteren Prozeduren zur Verfügung stehen und Probleme mit aggregierten Abfragen machen

Aha! Da du anscheinend Daten speichern willst wo verschiedene Stored Procedures drauf zugreifen können, kommst du ja mit der #temp aus der ersten Stored Procedure eh nicht weiter.
Denn die innerhalb der SP erstellte #Temp wird doch beim Verlassen der SP sowieso entfernt

Ich würde jedoch behaupten, dass, wenn Du ständig eine Relation löschen und neu erstellen musst, wahrscheinlich etwas grundsätzlich falsch angegangen wird. Wieder bitte nicht als Abwertung sehen!
Ich würde "einen Schritt zurück machen" (oder auch mehrere?) und anstatt auf das Eigene-Übersichten-speichern Problem eher auf die Abfrage konzentrieren und diese neu denken.

 

[chx_de]

Hi,

da muss ich dir leider wiedersprechen

Aha! Da du anscheinend Daten speichern willst wo verschiedene Stored Procedures drauf zugreifen können, kommst du ja mit der #temp aus der ersten Stored Procedure eh nicht weiter.
Denn die innerhalb der SP erstellte #Temp wird doch beim Verlassen der SP sowieso entfernt

Das ist so nicht korrekt. Die #temp Tabelle bleibt während der ganzen Sitzung erhalten und wird nur geschlossen, wenn entweder die Sitzung beendet oder aber die Tabelle mit DROP gelöscht wird. Deswegen kannst du dann auch selbstverständlich mit anderen SP auf die Daten in der #temp Tabelle zugreifen.

Damit es bei Create #temp nicht zu einem Fehler kommt, macht es Sinn immer das vorhanden sein der temporären Tabelle zu prüfen

drop table if exists #Temp

Ebenso ist es gut, am Ende des Codes die #temp mittels Drop zu löschen.

um Probleme, die beim gleichzeitigen Zugriff entstehen könnten bzw. das Locking kümmert sich doch der SQL-Server

Das ist mir schon klar. Aber ich möchte ja die Daten aus diversen Select Statements in einer temporären Tabelle speichern und auch nur genau diese Daten später weiter verarbeiten. Genau dafür sind temporäre Tabellen oder Tabellenvariablen ja da. Wenn ich mir anstatt einer #temp Tabelle jetzt eine permanente Tabelle anlege, dann kann es sein, dass mehrere Nutzer in unterschiedliche Sitzungen gleichzeitig Daten in diese Tabelle schreiben. Und genau dann gibt es ein Problem in dem nachfolgenden Code. Weil dieser dann Daten weiterverarbeitet, die eigentlich nicht nur USER1 zuzuordnen sind. Noch schlimmer wird es, wenn dann USER1 in seiner Session die Tabelle am Ende mittels DELETE ' leert. Dann wären die Daten für USER 2 auch weg. Kann man sicherlich durch Keys oder SessionIDs lösen.

Aber warum soll ich mir das antun, wenn es genau dafür in T-SQL das Objekt der temporären Tabelle gibt

Ich werde morgen mal den angepassten Code posten. Im Grunde geht es um die Auswertung der Amazon Settlement Daten. Ich habe für uns noch die PPC Kosten mit einbezogen. Wir lesen die Amazon ADS API aus, transformieren die Daten und speichern die auch im SQL Server ab. Dann haben wir noch weitere Tabellen mit erweiterten Artikeldaten und Kalkulation Daten, die wir für eine vernünftige Kalkulation bzw. Nachkalkulation benötigen. Diese Daten stehen ja nur uns zur Verfügung, deswegen muss ich den Code mal auf die Abfragen beschränken, die jeder JTL Nutzer von haus aus hat. Wenn jemand Interesse an der Auswertung inklusive PPC etc hat, genre melden .-)

 

[chx_de]

Moin.
Erstens - in deinem Code brauchst Du keine Temp-Table, MAXIMAL Tabellen-Variable, aber auch hier meine Frage - wozu, da ist nur ein SELECT.
Zweitens - eine SP soll in Custom View NICHT benutzt werden, nur Funktionen sind erlaubt (und auch dort kannst Du eine Tabellen-Variable definieren)
Drittens - ein Forum ist nicht nur zum Schreiben da, sondern auch zum Lesen, Lernen, Verstehen und ggf. Akzeptieren.

Hi, ich lese und verstehe das schon - mach dir da mal keine Sorgen Der Code, den ich zum testen gepostet hatte besteht tatsächlich nur aus einem Select. Das war ja auch nur zum Verständnis des Problems. Die eigentliche Prozedur ist ein wenig komplexer und in dem Code funktioniert dann auch keine @Tabellenvariable mehr. Wie ich weiter oben schon geschrieben habe, werde ich den morgen mal posten

Zweitens - eine SP soll in Custom View NICHT benutzt werden, nur Funktionen sind erlaubt (und auch dort kannst Du eine Tabellen-Variable definieren)

Wo genau steht das? War mit so nicht bekannt und wird von uns schon seit Einführung der Custom Views so praktiziert.

 

[chx_de]

So hier im Anhang die beiden SQL Prozeduren. Den Teil mit der PPC Abfrage habe ich auskommentiert, da er ja normalerweise in in JTL zur Verfügung steht.
Sämtlich Kosten für AFN sind in der Settlement Datei enthalten. Für das MFN Porto+ Karton habe ich bei uns fix 4.5 angesetzt. Für die MFN Retouren 5 Euro. Die exakten Daten liegen auch in einer Tabelle und müssen noch in die Abfrage eingebaut werden.

Nicht berücksichtig werden hier in diesem Beispiel: PPC Kosten, Amazon Lager Kosten, Kosten für Remissionen (die würde man aber über sie SP API bekommen), Erlöse durch Erstattung für verlorene Ware, etc.

 

[mh1]

da muss ich dir leider wiedersprechen

Das steht dir natürlich frei.

Das ist so nicht korrekt. Die #temp Tabelle bleibt während der ganzen Sitzung erhalten und wird nur geschlossen, wenn entweder die Sitzung beendet oder aber die Tabelle mit DROP gelöscht wird. Deswegen kannst du dann auch selbstverständlich mit anderen SP auf die Daten in der #temp Tabelle zugreifen.

Das Verhalten der Temp Tables ist hier dokumentiert:
https://learn.microsoft.com/en-us/s...ct-sql?view=sql-server-ver16#temporary-tables
(siehe auch erster Aufzählungspunkt)

Damit es bei Create #temp nicht zu einem Fehler kommt,

Es ist eher unüblich, einen Temp Table zuerst mit Create zu erstellen und dann mit inserts zu befüllen

macht es Sinn immer das vorhanden sein der temporären Tabelle zu prüfen

drop table if exists #Temp

Je nach Anwendungsfall kann evtl. schon nötig sein
Um verschiedene TempTables aber intern zu unterscheiden hängt der SQL-Server an den Namen einfach ein eindeutiges Suffix an.

 

[chx_de]

Das Verhalten der Temp Tables ist hier dokumentiert:
https://learn.microsoft.com/en-us/s...ct-sql?view=sql-server-ver16#temporary-tables
(siehe auch erster Aufzählungspunkt)

ja und da steht es ja auch genauso drin - "The table can be referenced by any nested stored procedures" => funktioniert ja auch ohne Probleme 👈

 

[mh1]

ja und da steht es ja auch genauso drin - "The table can be referenced by any nested stored procedures" => funktioniert ja auch ohne Probleme 👈

Achso du arbeitest mit nested SP's .... das wusste ich nicht .