Neu SQL prozeduren mit #temp Tabellen

[chx_de]

Hallo,

wir haben einige SQL Prozeduren in die eigenen Übersichten eingebunden, die im Code mit temporären Tabellen arbeiten. (zb. #temp1 etc)

Die funktionieren auch ganz gut. Jetzt wollte ich noch weitere Übersichten anlegen und kann das aber nicht speichern. Als Fehler kommt dann immer "ungültiger Objektname #temp1"
Auch wenn ich die Prozeduren einfügen möchte, die schon seit Jahren funktionieren (auf einem neuen Reiter), kommt diese Fehlermeldung.

Habt Ihr da was an der Prüfung des Codes für die eigenen Übersichten geändert und / oder wie kann ich das Problem lösen

Besten Dank
Christian Blaß

 

[mh1]

Hallo,

wir haben einige SQL Prozeduren in die eigenen Übersichten eingebunden, die im Code mit temporären Tabellen arbeiten. (zb. #temp1 etc)

Die funktionieren auch ganz gut. Jetzt wollte ich noch weitere Übersichten anlegen und kann das aber nicht speichern. Als Fehler kommt dann immer "ungültiger Objektname #temp1"
Auch wenn ich die Prozeduren einfügen möchte, die schon seit Jahren funktionieren (auf einem neuen Reiter), kommt diese Fehlermeldung.

Habt Ihr da was an der Prüfung des Codes für die eigenen Übersichten geändert und / oder wie kann ich das Problem lösen

Besten Dank
Christian Blaß

Vielleicht kommt das ja nur davon, dass der Temp Table zur Zeit des Speicherns gar nicht existiert?
Kannst ja mal auf dem Server den Temp Table anlegen und dann Speichern.

 

[chx_de]

Hi,

Vielleicht kommt das ja nur davon, dass der Temp Table zur Zeit des Speicherns gar nicht existiert?
Kannst ja mal auf dem Server den Temp Table anlegen und dann Speichern.

HI,
habe ich ausprobiert. Daran liegt es nicht. Die #temp Tabellen sind tatsächlich immer an die jeweilige Prozedur und Benutzer gebunden. Das liegt wahrscheinlich daran, dass in älteren JTL Versionen diese Prüfung nicht statt gefunden hat und er Code ggf. einfach übernommen wurde. Zur Not muss ich mir die Mühe machen und anstatt temporärer Tabellen halt normale Tabellen anzulegen. Würde ich gerne vermeiden, wenn es irgendwie geht

 

[mh1]

...oder du schreibst den Code für die eigene Übersicht direkt mit SQL in die Datenbank und umschiffst so die Prüfungsroutine (ist aber sicher eine Bastelei)

aber prüfe vorher auf jeden Fall erstmal, ob wirklich die Temp Table das Problem sind, bevor du weiter rumspielst

 

[chx_de]

...oder du schreibst den Code für die eigene Übersicht direkt mit SQL in die Datenbank und umschiffst so die Prüfungsroutine (ist aber sicher eine Bastelei)

aber prüfe vorher auf jeden Fall erstmal, ob wirklich die Temp Table das Problem sind, bevor du weiter rumspielst

Hi,
der Code liegt ja direkt in der Datenbank. Der ist dort als gespeicherte Prozedur hinterlegt. Wenn man dann in den eigenen Übersichten, diese Prozedur aufruft, dann wird neuerdings die ganze Prozedur geprüft und die #temporären Tabellen sind nicht vorhanden.

Und ja, die #temp Tabellen sind das Problem. Hier kommt die Fehlermeldung seitens JTL "ungültiger Objektname #temp1 ".

Ich könnte sicherlich mit normalen Tabellen arbeiten, hätte dann aber ein Konflikt Problem, wenn mal zufällig 2 oder mehr diese Prozedur aufrufen. Die #temp Tabellen sind nämlich an die Session gebunden und somit gibt es keinen Stress bei mehreren Nutzern.

In den #temp Tabellen werden nur diverse SQL Ergebnisse aus mehreren Abfragen zwischen gespeichert, so dass ich dann am Ende über die #temp Tabelle ein Select mit diversen Sum(), Count(), etc laufen lassen kann.

Wäre schon cool, wenn die Prüfung wieder weg fallen würde oder ich muss mir für die Zwischenspeicherung was anderes einfallen lassen

 

[mh1]

Ich verstehe nicht ganz was du meinst.
Du hast eine SP gebastelt und in dieser SP werden Temp Tables benutzt.
Wenn du jetzt eine eigene Übersicht anlegen willst mit einem Inhalt in der Art wie "EXEC meineSP", dann prüft die Wawi beim Klicken auf speichern diese SP? Meinst du das so?

 

[chx_de]

Ich verstehe nicht ganz was du meinst.
Du hast eine SP gebastelt und in dieser SP werden Temp Tables benutzt.
Wenn du jetzt eine eigene Übersicht anlegen willst mit einem Inhalt in der Art wie "EXEC meineSP", dann prüft die Wawi beim Klicken auf speichern diese SP? Meinst du das so?

Genauso. Es wird nur beim speichern geprüft. Wenn die einmal drin sind, dann laufen die auch. Also alle vorhandenen Übersichten nutzen temporäre Tabellen. Kein Problem. Will ich eine neue anlegen, gibt es Probleme.

 

[mh1]

Genauso. Es wird nur beim speichern geprüft. Wenn die einmal drin sind, dann laufen die auch. Also alle vorhandenen Übersichten nutzen temporäre Tabellen. Kein Problem. Will ich eine neue anlegen, gibt es Probleme.

Das ist das was ich oben gemeint habe: schreibe die Eigene Übersicht einfach per SQL in die Datenbank und gehe nicht den Weg durch die Wawi mit der Prüfung.

 

[chx_de]

Das ist das was ich oben gemeint habe: schreibe die Eigene Übersicht einfach per SQL in die Datenbank und gehe nicht den Weg durch die Wawi mit der Prüfung.

Hi,
was genau meinst du mit ".oder du schreibst den Code für die eigene Übersicht direkt mit SQL in die Datenbank" ?

Ich habe es jetzt erstmal so gelöst, dass ich die temporären Tabellen #temp durch Tabellen Variablen @temp TABLE (...) ersetzt habe. Ist ein wenig mehr Aufwand, funktioniert aber soweit.

 

[wawi-dl]

So wie du das vor hast, wird das wohl nicht funktionieren, habe es so verstanden, dass die Temp-Tabelle ja nur bei Aufruf erstellt und abgerufen wird, oder?

Baue doch dann lieber den SP um, dass die Tabelle dauerhaft existent ist und nur aktualisiert wird?
Ich vermute es gibt ein Laufzeitproblem mit JTL, da die Tabelle schon weg/gelöscht ist.

 

[chx_de]

So wie du das vor hast, wird das wohl nicht funktionieren, habe es so verstanden, dass die Temp-Tabelle ja nur bei Aufruf erstellt und abgerufen wird, oder?

Baue doch dann lieber den SP um, dass die Tabelle dauerhaft existent ist und nur aktualisiert wird?
Ich vermute es gibt ein Laufzeitproblem mit JTL, da die Tabelle schon weg/gelöscht ist.

Hi,
es funktioniert ja bzw. es hat funktioniert. Bis zu einer bestimmten JTL Version wurde der Code nicht auf #temp Tabellen geprüft. Man konnte das einfach anlegen bzw die gespeicherte Prozedur aufrufen. Alle Übersichten, die so angelegt wurden, funktionieren ja auch wunderbar. Nur neue lassen sich nicht mehr anlegen, weil jetzt das vorhanden sein der Tabellen geprüft wird. Und ja, die #temp Tabellen existieren nicht.

Diese Prüfung muss halt einfach wieder weg

Die Tabellen fix anzulegen, wie du vorgeschlagen hast, ist auch nicht zielführend, weil es zu Problemen kommen kann, wenn mehrere Mitarbeiter mal zufällig dieselbe Übersicht aufrufen. Der Inhalt der Tabellen muss ja jedes mal gelöscht werden. #temp Tabellen sind hier schon besser, da an Session gebunden.

Aktuell habe ich es auf Tabellenvariablen umgestellt.

 

[wawi-dl]

Hi,
es funktioniert ja bzw. es hat funktioniert. Bis zu einer bestimmten JTL Version wurde der Code nicht auf #temp Tabellen geprüft. Man konnte das einfach anlegen bzw die gespeicherte Prozedur aufrufen. Alle Übersichten, die so angelegt wurden, funktionieren ja auch wunderbar. Nur neue lassen sich nicht mehr anlegen, weil jetzt das vorhanden sein der Tabellen geprüft wird. Und ja, die #temp Tabellen existieren nicht.

Diese Prüfung muss halt einfach wieder weg

Die Tabellen fix anzulegen, wie du vorgeschlagen hast, ist auch nicht zielführend, weil es zu Problemen kommen kann, wenn mehrere Mitarbeiter mal zufällig dieselbe Übersicht aufrufen. Der Inhalt der Tabellen muss ja jedes mal gelöscht werden. #temp Tabellen sind hier schon besser, da an Session gebunden.

Aktuell habe ich es auf Tabellenvariablen umgestellt.

Wir kennen die Anforderungen nicht und was ausgegeben wird.

Wenn es versionsabhängig ist, hast du dir die Frage doch selbst beantwortet, Ticket bei JTL aufmachen, wenn du die Versionen belegen kannst.

 

[mh1]

Diese Prüfung muss halt einfach wieder weg

Prinzipiell ist es ja kein Fehler, dass das Eingegebene beim Klick auf Speichern auf formale Richtigkeit geprüft wird.
Es wird ja auch geprüft, dass nur lesend auf die Datenbank zugegriffen wird. Dass an der Stelle, also beim Speichern, eine Stored Procedure ausgeführt wird kann ich mir nicht vorstellen (da ja EXEC in den eigenen Übersichten eigentlich nicht erlaubt ist). Das wäre dann ein Fehler in der von dir benutzen Wawi Version.

was genau meinst du mit ".oder du schreibst den Code für die eigene Übersicht direkt mit SQL in die Datenbank" ?

So habe ich es gemeint:
Du legst die eigene Übersicht an mit z.B. folgendem Inhalt SELECT 'blafasel', dann überschreibst du das in der Datenbank mit dem Aufruf für deine Stored Procedure: update dbo.tCustomerQuery set cQueryText='EXEC deineSP' where converrt(vachar(max), cQueryText ) = 'select ''blafasel'''
Da man aber bei direkten Schreibzugriffen auf die Datenbank und insbesondere beim Umgehen der Prüfungen durch die Wawi echt auch viel kaputt machen kann, sollte das beschriebene Vorgehen nur ausgeführt werden, wenn man weiß was man tut und vorallem den SQL zu 100% versteht. Ist also keinesfalls eine Copy & Paste Anleitung

 

[mvh]

Moin. Nur zur Info.
Es gibt 4 Temptable-Arten:
Tabelle als Variable - DECLARE @t TABLE - wird meistens in Abfragen oder SP benutzt und wird nach der Ausführung gelöscht.
Lokale Temptable - CREATE TABLE #t - wird in einer SQL Server Verbindung definiert und ist sichtbar und verwendbar nur für diese SQL Server Verbindung.
Wird die Verbindung geschlossen - wird die Tabelle gelöscht.
Globale Temptable - CREATE TABLE ##t - wird zwar auch in einer SQL Server Verbindung definiert, ist aber für ALLE Verbindungen sichtbar und verwendbar.
Wenn ALLE Verbindungen, die diese Temptable nutzen, geschlossen werden - erst dann wird die Tabelle gelöscht.
Echte Temptable - USE tempdb; CREATE TABLE t - ist unabhängig von Verbindung und wird mit DROP TABLE t oder nach SQL Server Neustart gelöscht.

 

[chx_de]

Prinzipiell ist es ja kein Fehler, dass das Eingegebene beim Klick auf Speichern auf formale Richtigkeit geprüft wird.
Es wird ja auch geprüft, dass nur lesend auf die Datenbank zugegriffen wird. Dass an der Stelle, also beim Speichern, eine Stored Procedure ausgeführt wird kann ich mir nicht vorstellen (da ja EXEC in den eigenen Übersichten eigentlich nicht erlaubt ist). Das wäre dann ein Fehler in der von dir benutzen Wawi Version.


So habe ich es gemeint:
Du legst die eigene Übersicht an mit z.B. folgendem Inhalt SELECT 'blafasel', dann überschreibst du das in der Datenbank mit dem Aufruf für deine Stored Procedure: update dbo.tCustomerQuery set cQueryText='EXEC deineSP' where converrt(vachar(max), cQueryText ) = 'select ''blafasel'''
Da man aber bei direkten Schreibzugriffen auf die Datenbank und insbesondere beim Umgehen der Prüfungen durch die Wawi echt auch viel kaputt machen kann, sollte das beschriebene Vorgehen nur ausgeführt werden, wenn man weiß was man tut und vorallem den SQL zu 100% versteht. Ist also keinesfalls eine Copy & Paste Anleitung

Hi,
SPs funktionieren eigentlich schon immer in den Übersichten. Aktuell halt nur nicht, wenn eine #temp Tabelle genutzt wird, Hast du eine SP ohne #temp oder ##temp Tabellen und nutzt dort nur Code oder eine Tabelle als Variable mit @temp, dann klappt das ohne Probleme.

Zu deinem Tipp, dass direkt in die DB zu scheiben: Genauso hatte ich es dann am Ende auch gelöst Hatten wir denselben Gedanken.

Wenn ich den Code morgen fertig habe, werde ich den mal zur Verfügung stellen.

Besten Dank an alle

 

[mh1]

Hi,
SPs funktionieren eigentlich schon immer in den Übersichten. Aktuell halt nur nicht, wenn eine #temp Tabelle genutzt wird, Hast du eine SP ohne #temp oder ##temp Tabellen und nutzt dort nur Code oder eine Tabelle als Variable mit @temp, dann klappt das ohne Probleme.

Ich hab das grad getestet. Jedenfalls in der 1.9.6 geht das wunderbar mit einer SP in den eigenen Übersichten, die lokale Temptable benutzt (also #Temp)

 

[chx_de]

Ich hab das grad getestet. Jedenfalls in der 1.9.6 geht das wunderbar mit einer SP in den eigenen Übersichten, die lokale Temptable benutzt (also #Temp)

Ok. ich bin aktuell noch auf 1.9.4.6 --> da klappt es nicht. Aber vielleicht hat JTL das nach meinem Ticket geändert?

 

[mh1]

Ok. ich bin aktuell noch auf 1.9.4.6 --> da klappt es nicht. Aber vielleicht hat JTL das nach meinem Ticket geändert?

Sorry, ich hab mich vertippt, ich meinte natürlich die 1.9.4.6, es gibt ja gar keine 1.9.6
Jedenfalls funktionierts hier einwandfrei mit der #tempTable in der SP.
Vielleicht bei dir ein Problem, dass doch überhaupt nichts mit den Temp Tables zu tun hat???
Ich denke, wir sind hier an einer Stelle, wo wir ohne näheres über dein Vorhaben zu wissen oder den Code zu sehen nicht mehr viel sagen können.

Ist ja aber eh hinfällig, da du ja mit den Tablevariablen bereits eine für dich funktionierende Lösung gefunden hast

 

[chx_de]

Sorry, ich hab mich vertippt, ich meinte natürlich die 1.9.4.6, es gibt ja gar keine 1.9.6
Jedenfalls funktionierts hier einwandfrei mit der #tempTable in der SP.
Vielleicht bei dir ein Problem, dass doch überhaupt nichts mit den Temp Tables zu tun hat???
Ich denke, wir sind hier an einer Stelle, wo wir ohne näheres über dein Vorhaben zu wissen oder den Code zu sehen nicht mehr viel sagen können.

Ist ja aber eh hinfällig, da du ja mit den Tablevariablen bereits eine für dich funktionierende Lösung gefunden hast

Hi,
der Code ist für hier jetzt etwas oversized Ich habe aber mal ein ganz einfaches Beispiel angelegt.

1. Prozedur auf unserem Server in der Datenbank "Toci". Alle Prozeduren speichere ich normalerweise in unserer eigenen Datenbank und nicht in der eazybusiness. Aber auch wenn ich die SP in der eazybusiness ablege, funzt das nicht. hier mal eine kleine Prozedur, die in der eazybusiness liegt.

USE [eazybusiness]
GO
/****** Object:  StoredProcedure [dbo].[spToci_JTL_Test]    Script Date: 28.08.2024 10:43:52 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO




-- =============================================
-- Author:        <Christian Blaß>
-- Create date: <2024-08-27>
-- Description:    <TEST für #temp Tabellen in den JTL Übersichten>
-- =============================================

ALTER PROCEDURE [dbo].[spToci_JTL_Test]
    -- Add the parameters for the stored procedure here
    @Artikel as int


AS

BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
    SET NOCOUNT ON;

--- TOCI CODE
--wenn temporäre Tabelle vorhanden, dann löschen
    drop table if exists #temp1


-- temporäre Tabelle erstellen, die dann gefüllt wird
    create table #temp1
            (
            nMenge int -- Summe aller Verkauften Artikel über die Plattformen Ebay und Amazon mit Lieferland DE

            )

          
-- Verkaufte Gesamtstückzahl über Plattformen Amazon.de und Ebay.de
-- Lieferung nur nach DE

    insert into #temp1
        (    nMenge

        )
        select
            sum(fAnzahl) --verkaufte Stückzahl

                                  
         from eazybusiness.Verkauf.tAuftragPosition as PO
        join
            eazybusiness.Verkauf.tAuftrag as AU
        on
            PO.kAuftrag = AU.kAuftrag

        where
                PO.kArtikel = @Artikel
            and
                PO.fVKNetto <> 0
            and
                AU.nType = 1
            and
                AU.kPlattform in ('51')



--Ausgabe
    select nMenge as 'Absatz Total'

    from #temp1             
-- temp Tabelle löschen 
    drop table #temp1
END

2. In den JTL Übersichten eine Test Übersicht angelegt mit folgendem Code:

execute eazybusiness.dbo.spToci_JTL_Test @key

==> das kann ich nicht speichern.



Beste Grüße
Christian

 

[mh1]

...
==> das kann ich nicht speichern.

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'''