none
Inhalt einer Zeichkette in VARCHAR(MAX) laden

    Frage

  • Hallo an alle, ich bin heute über ein Phänomen gestoßen was ich mir überhaupt nicht erklären kann. Ich weiß das ich in VARCHAR(MAX) maximal 4000 Zeichen speichern kann. Nachfolgendes SQL Statement sollte meines erachten also locker reinpassen. Liege ich hiermit falsch oder was habe ich falsch gemacht? Wenn ich den "Print" nehme und ausführen lasse ist die Abfrage korrekt.

    DECLARE @Timestamp varchar(30)
    --SET @Timestamp = CONVERT (datetime,'2017-04-23 00:00:00.000', 121);
    SET @Timestamp = '2017-04-23 00:00:00.000';
    
    DECLARE @Timestamp_END varchar(30)
    --SET @Timestamp_END = CONVERT (datetime,'2017-05-30 00:00:00.000', 121);
    SET @Timestamp_END ='2017-05-30 23:59:00.000';
    
    DECLARE @Verwendung varchar(20)
    SET @Verwendung = 'Fällbehälter_5_5';
    DECLARE @Spaltenauswahl nvarchar(20)
    
    
    BEGIN
    if @Verwendung = 'Fällbehälter_6_1' 
    			Begin
    			 SET @Spaltenauswahl = 'Füllstand_FB6_1'
    			--	print '1'
    			END
    	ELSE if @Verwendung = 'Fällbehälter_5_1'
    			BEGIN
    			SET @Spaltenauswahl = 'Fuellstand_FB5_1';
    				--print '3'
    			END
    	ELSE if @Verwendung = 'Fällbehälter_5_2'
    			BEGIN
    			SET @Spaltenauswahl = 'Fuellstand_FB5_2';
    			END	
    	ELSE if @Verwendung = 'Fällbehälter_5_3'
    			BEGIN
    			SET @Spaltenauswahl = 'Fuellstand_FB5_3';
    			END		
    	ELSE if @Verwendung = 'Fällbehälter_5_4'
    			BEGIN
    			SET @Spaltenauswahl = 'Fuellstand_FB5_4'	;	
    			END
    	ELSE if @Verwendung = 'Fällbehälter_5_5'
    			BEGIN
    			SET @Spaltenauswahl = 'Fuellstand_FB5_5';
    			END
    END
    
    DECLARE @SQL VARCHAR(MAX);
    
    SET @SQL ='
    With Vorberechnung as (
    	SELECT [ID],[TimeStamp_Start],[TimeStamp_Stop],DATEADD(minute,-1,[TimeStamp_Start]) as [TimeStamp_Start_m1],DATEADD(minute,+1,[TimeStamp_Stop]) as [TimeStamp_Stop_p1],Verwendung
    	  FROM [SKEMS-HST].[dbo].[Produktionszeiten] WHERE (TimeStamp_Start Between CONVERT(datetime,'''+@Timestamp+''',121) and CONVERT(datetime,'''+@Timestamp_END+''',121))) 
    	SELECT V.ID, V.[TimeStamp_Start], V.[TimeStamp_Stop],T1.['+ @Spaltenauswahl +'] as [Fuellstand_Start], V.Verwendung FROM [SKEMS-HST].[dbo].[TREND009] AS T1
     INNER JOIN Vorberechnung as V on [Time_Stamp] = V.[TimeStamp_Start_m1] where Verwendung = '''+@Verwendung+''' group by V.ID, V.[TimeStamp_Start],V.[TimeStamp_Stop],T1.['+@Spaltenauswahl+'],V.Verwendung';
    
    print @SQL
    
    exec @SQL

    Mittwoch, 17. Mai 2017 06:21

Alle Antworten

  • Hi,

    VARCHAR( MAX ) nimmt erheblich mehr als 4.000 Zeichen auf, Du kannst dort bis zu 2 GB hinterlegen.

    Daher die Frage: Was genau funktioniert nicht? Welche Fehlermeldung erhältst Du? Warum verwendest Du dynamisches SQL? Soweit ich das sehe, ist das ziemlich unnötig.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Mittwoch, 17. Mai 2017 06:33
    Moderator
  • Hallo,
    bei varchar(max) sind es sogar 8000 Zeichen. Bei nvarchar(max) sind es 4000! Das ist nicht das Problem!

    Die Statements selbst sehen beim ersten, schnellen drüberschauen gut aus. Vielleicht kannst du mal eine Fehlermeldung posten?

    Danke!


    Viele Grüße Holger M. Rößler

    Mittwoch, 17. Mai 2017 06:35
  • Hallo Holger,

    varchar( MAX ) kann bis zu 2 GB aufnehmen. varchar( <Zahl> ) ist auf 8.000  (bei nvarchar 4.000) beschränkt. Siehe dazu bspw.:

      char und varchar (Transact-SQL)


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Mittwoch, 17. Mai 2017 06:43
    Moderator
  • Hallo Stefan,
    vielen Dank für die Korrektur!


    Viele Grüße Holger M. Rößler

    Mittwoch, 17. Mai 2017 06:48
  • Hallo Toot,

    schau Dir bitte mal die Antworten auf deine vorherigen Fragen an. Derzeit spinnt die Forensoftware häufiger, deswegen weiß ich nicht, ob Du sie gesehen hast.

    Mit den Antworten kannst Du den Masochismus eines dynamischen SQLs vermeiden. Ganz roh (Tippfehler vorbehalten):

    DECLARE @Timestamp_Start @date = '2017-04-23';
    DECLARE @Timestamp_End @date = '2017-05-30'; 23:59:00.000';
    DECLARE @Verwendung varchar(20) = 'Fällbehälter_5_5';
    
    WITH Vorberechnung AS 
    (
    	SELECT P.[ID]
    		, P.[TimeStamp_Start]
    		, P.[TimeStamp_Stop]
    --		, DATEADD(minute, -1, P.[TimeStamp_Start]) as [TimeStamp_Start_m1]
    --		, DATEADD(minute, +1, P.[TimeStamp_Stop]) as [TimeStamp_Stop_p1]
    		, P.Verwendung
    		, CASE P.Verwendung
    			WHEN 'Fällbehälter_6_1' THEN T1.Füllstand_FB6_1
    			WHEN 'Fällbehälter_5_1' THEN T1.Fuellstand_FB5_1
    			WHEN 'Fällbehälter_5_2' THEN T1.Fuellstand_FB5_2
    			WHEN 'Fällbehälter_5_3' THEN T1.Fuellstand_FB5_3
    			WHEN 'Fällbehälter_5_4' THEN T1.Fuellstand_FB5_4
    			WHEN 'Fällbehälter_5_5' THEN T1.Fuellstand_FB5_5
    			ELSE 0.0 END	-- CAST auf Datentyp von Füllstand...
    			AS Fuellstand_Start
    	FROM [dbo].[Produktionszeiten] AS P
    	INNER JOIN [dbo].[TREND009] AS T1
    	ON T1.[Time_Stamp] = DATEADD(MINUTE, -1, P.[TimeStamp_Start])
    	WHERE TimeStamp_Start >= @Timestamp_Start 
    		AND TimeStamp_Start < DATEADD(DAY, 1, @Timestamp_End)
    ) 
    SELECT V.ID
    	, V.[TimeStamp_Start]
    	, V.[TimeStamp_Stop]
    	, V.Verwendung 
    	, V.Fuellstand_Start
    WHERE V.Verwendung = @Verwendung
    FROM Vorberechnung AS V 
    GROUP BY V.ID
    	, V.[TimeStamp_Start]
    	, V.[TimeStamp_Stop]
    	, V.Verwendung
    	, V.Fuellstand_Start;
    

    Sieht freundlicher aus, oder nicht? Abseits von Wartbarkeit und vielen anderen Dingen mehr...

    Zum Betreff: Anweisungen werden vom SQL Server als Unicode (NVARCHAR(MAX)) behandelt und man sollte dynamisches SQL damit formulieren, spätestens wenn mehr als ASCII (wie Umlaute) verwendet werden. Das gilt dann für alle Beteiligten (@Spaltenauswahl).

    Gruß Elmar

    Mittwoch, 17. Mai 2017 07:32
  • erst mal allen ein dickes Dankeschön!

    @Elmar ja dein SQL sieht schöner aus als meins aber der Wert in Fuellstand_Start ist gleichzeitig der Spaltenname für das zweite SELECT. Deswegen bin ich auch den Umweg über EXEC gegangen. Hast du eine Idee wie man diesen Umweg vermeiden kann?

    SELECT V.ID
    	, V.[TimeStamp_Start]
    	, V.[TimeStamp_Stop]
    	, V.Verwendung 
    	, V.Fuellstand_Start --- <<< muss den Wert aus Fuellstand_Start als Spaltenname nutzen
    WHERE V.Verwendung = @Verwendung
    FROM Vorberechnung AS V 
    GROUP BY V.ID
    	, V.[TimeStamp_Start]
    	, V.[TimeStamp_Stop]
    	, V.Verwendung
    	, V.Fuellstand_Start;Select 

    Mittwoch, 17. Mai 2017 11:28
  • @ all die Fehlermeldung lautet:

    Meldung 203, Ebene 16, Status 2, Zeile 55

    Der Name '

    With Vorberechnung as (

    SELECT [ID],[TimeStamp_Start],[TimeStamp_Stop],DATEADD(minute,-1,[TimeStamp_Start]) as [TimeStamp_Start_m1],DATEADD(minute,+1,[TimeStamp_Stop]) as [TimeStamp_Stop_p1],Verwendung

    FROM [SKEMS-HST].[dbo].[Produktionszeiten] WHERE (TimeStamp_Start Between CONVERT(datetime,'2017-04-23 00:00:00.000',121) and CONVERT(datetime,'2017-05-30 23:59:00.000',121)))

    SELECT V.ID, V.[TimeStamp_Start], V.[TimeStamp_Stop],T1.[Fuellstand_FB5_5] as [Fuellstand_Start], V.Verwendung FROM [SKEMS-HST].[dbo].[TREND009] AS T1

    INNER JOIN Vorberechnung as V on [Time_Stamp] = V.[TimeStamp_Start_m1] where Verwendung = 'Fällbehälte' ist kein gültiger Bezeichner.

    Man sieht schön das nicht das ganze SELECT ausgeführt werden kann, da der Rest der eigentlichen SELECT Abfrage ihm nicht bekannt sind.

    Um so mehr Leerzeichen ich aus der SELECT Abfrage die in @SQL steht entfernt habe um so vollständiger wurde die eigentliche SELECT Abfrage.
    Mittwoch, 17. Mai 2017 11:30
  • Hi,

    schreib bitte entweder:

    EXEC( @SQL )

    (also mit Klammern um den Variablennamen) oder

    EXEC sp_executesql @SQL

    Sinnvoller wäre es aber, auf den dynamischen SQL Kram zu verzichten und mit einem richtigen SQL Statement zu arbeiten. Das wäre hier problemlos möglich, siehe Elmars Antwort.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Mittwoch, 17. Mai 2017 11:39
    Moderator
  • Hallo Toot,

    entschuldige, beim "Reformatieren" ist so manches auf der Strecke geblieben.

    Hier dürfte aber gelten, was in einem Falle geht, geht auch in einem weiteren Falle...

    DECLARE @Timestamp_Start date = '2017-04-23';
    DECLARE @Timestamp_End date = '2017-05-30';
    DECLARE @Verwendung sysname = N'Fällbehälter_5_5';
    
    WITH Vorberechnung AS 
    (
        SELECT P.[ID]
            , P.[TimeStamp_Start]
            , P.[TimeStamp_Stop]
    --      , DATEADD(minute, -1, P.[TimeStamp_Start]) as [TimeStamp_Start_m1]
    --      , DATEADD(minute, +1, P.[TimeStamp_Stop]) as [TimeStamp_Stop_p1]
            , P.Verwendung
    
            , CASE WHEN @Verwendung
                WHEN N'Fällbehälter_6_1' THEN T1.Fällbehälter_6_1
                WHEN N'Fällbehälter_5_1' THEN T1.Fällbehälter_5_1
                WHEN N'Fällbehälter_5_2' THEN T1.Fällbehälter_5_2
                WHEN N'Fällbehälter_5_3' THEN T1.Fällbehälter_5_3
                WHEN N'Fällbehälter_5_4' THEN T1.Fällbehälter_5_4
                WHEN N'Fällbehälter_5_5' THEN T1.Fällbehälter_5_5
                ELSE 0.0 END    -- CAST auf Datentyp von Fällbehälter...
              AS Fällbehälter
    
            , CASE @Verwendung
                WHEN N'Fällbehälter_6_1' THEN T1.Füllstand_FB6_1
                WHEN N'Fällbehälter_5_1' THEN T1.Fuellstand_FB5_1
                WHEN N'Fällbehälter_5_2' THEN T1.Fuellstand_FB5_2
                WHEN N'Fällbehälter_5_3' THEN T1.Fuellstand_FB5_3
                WHEN N'Fällbehälter_5_4' THEN T1.Fuellstand_FB5_4
                WHEN N'Fällbehälter_5_5' THEN T1.Fuellstand_FB5_5
                ELSE 0.0 END    -- CAST auf Datentyp von Füllstand...
                AS Fuellstand_Start
        FROM [dbo].[Produktionszeiten] AS P
        INNER JOIN [dbo].[TREND009] AS T1
        ON T1.[Time_Stamp] = DATEADD(MINUTE, -1, P.[TimeStamp_Start])
        WHERE TimeStamp_Start >= @Timestamp_Start 
            AND TimeStamp_Start < DATEADD(DAY, 1, @Timestamp_End)
    ) 
    SELECT DISTINCT -- anstatt GROUP BY über alles
          V.ID
        , V.[TimeStamp_Start]
        , V.[TimeStamp_Stop]
        , V.Verwendung
        , V.Fällbehälter
        , V.Fuellstand_Start
    WHERE V.Verwendung = V.Fällbehälter
    FROM Vorberechnung AS V;
    /* DISTINCT
    GROUP BY V.ID
        , V.[TimeStamp_Start]
        , V.[TimeStamp_Stop]
        , V.Verwendung
        , V.Fuellstand_Start;
    */

    Wobei ich nicht ganz schlüssig war, wie die "Verwendung" verwendet werden soll ;) Als ob es der mit dem Wert Fällbehälters verglichen werden soll oder mit dem Inhalt der Verwendung (so liest es sich).

    Wie dem auch sei, mit umstellen der Spaltenauswahl im CASE  und/oder Vergleiche sollte man es hinbekommen können. Nebenbei: Ich habe GROUP BY durch DISTINCT ersetzt (macht es klarer und kürzer).

    Sollte es nicht ohne dynamisches SQL abgehen: Verwende durchweg Unicode. Auch für Tabellen- Spaltennamen - sysname ist ein vordefinierte Unicode-Typ für Objektnamen -. Zeichenketten sollte mit N' - Präfix geschrieben werden, um sie als Unicode Zeichenkette zu kennzeichnen. Was insgesamt unnötige (implizite) Konvertierungen vermeidet... 

    Dann darf man auch Zeilenumbrüche un dLeerzeichen einbauen, denn Gewusel wie oben kann man erfahrungsgemäß nach einigen Tagen selbst nicht mehr entschlüsseln - von anderen (wie hier mich) ganz zu schweigen.

    Gruß Elmar

    Mittwoch, 17. Mai 2017 18:15
  • Hallo Elmar danke für deine Antwort. Ich kann es zwar leider jetzt nicht testen aber ich denke wir zwei sind noch nicht ganz auf den gleichen Nenner ;)

    Das erste SELECT prüft den Parameter @Verwendung und setzt den Parameter @Spaltenauswahl (jetzt dank dir mit SWITCH CASE).

    Anschließend wird in einer anderen Tabelle nach der Spalte, mit dem Namen der den Wert in dem Parameter @Spaltenauswahl befindet, gesucht. Hier fand ich für mich keine andere Lösung als dynamisch in ein String zu generieren und in eine Variable zu laden. Diese dann im Anschluss "auszuführen". Ich bin aber gern bereit neue Wege zu gehen. Da das dynamische SQL so schwer zu schreiben ist.

    Mittwoch, 17. Mai 2017 18:33
  • Hallo Toot,

    alles was Dein eingehendes IF ... ELSE Konstrukt macht, kann man direkt in die Abfrage einbauen. Die obigen CASE... liefern die Daten der angegebenen Spalte - einzige Voraussetzung ist, das die Datentypen der Spalten kompatibel sein müssen (implizit oder explizit konvertierbar).

    Ein wirklich neuer Weg wäre, die Daten richtig zu normalisieren, denn _1..._6 entspricht nicht der Normalform. Und führt in diesem Falle zu den umständlichen Konstrukten, es hätte also praktischen Nutzen.

    (Wobei das bei bestehenden Datenbanken nicht immer einfach umzustellen ist. Da kann aber durch aus eine Sicht helfen, die das gleiche wie oben macht)

    Nebenbei war mein Problem: Nicht alle Spalten werden mit Tabellenpräfix angesprochen, so dass ich die Herkunft nicht immer eindeutig zuordnen kann => Hier: Welche "Verwendung" enthält was und wo kommt sie her (Produktion, Trend)?

    Gruß Elmar

    Mittwoch, 17. Mai 2017 18:46
  • Hallo Elmar,

    das ganze zu normalisieren wäre auch mein Wunsch. Jedoch lässt sich genau das nicht machen. So bald ein neuer Messwert in die Datenbank aufgenommen werden soll wird einfach eine neue Spalte angehangen. Leider ist dieser Vorgehen ja schon fast Standard wenn mit Datenbanken gearbeitet wird.

    Also leider keine Möglichkeit dies zu ändern.

    Mittwoch, 17. Mai 2017 20:25
  • Hi,
    So bald ein neuer Messwert in die Datenbank aufgenommen werden soll wird einfach eine neue Spalte angehangen. Leider ist dieser Vorgehen ja schon fast Standard wenn mit Datenbanken gearbeitet wird.

    Du meinst die Vorgehensweise, die Anwendung beim Eintreffen irgendwelcher Werte die Struktur einer relationalen Datenbank durch die Anwendung automatisch zu verändern indem irgendwo irgendwelche Spalten in Tabellen eingefügt werden?

    Wenn das irgendwo Standard ist, dann IMHO eigentlich nur in Anwendungen, die fürn Hintern sind und/oder solchen, bei denen der Entwickler keine Ahnung von Datenbanken hat. Es mag ganz ganz wenige Ausnahmen geben, bei denen sowas gewollt und notwendig ist, mir persönlich fällt allerdings keine solche Ausnahme ein.

    Abgesehen davon, dass man sich damit jede Möglichkeit verschließt, mit modernen Zugriffsmethoden wie bspw. dem Entity Framework auf die Datenbankobjekte zuzugreifen, schießt man sich auch sonst mit einem solchen Vorgehen selbst ins Knie.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Donnerstag, 18. Mai 2017 06:31
    Moderator
  • @Stefan leider erlebe ich das sehr oft. Das macht es mir ja auch so schwer.

    Aber noch einmal zurück zum Thema. Ich habe die Abfrage noch etwas aufgeräumt.

    DECLARE @Timestamp_Start varchar(30)
    SET @Timestamp_Start = CONVERT (datetime,'2016-01-27 00:00:00.000', 121);
    DECLARE @Timestamp_End varchar(30)
    SET @Timestamp_End = CONVERT (datetime,'2016-01-30 00:00:00.000', 121);
    DECLARE @Verwendung varchar(30)
    SET @Verwendung = 'Fällbehälter_6_1';
    DECLARE @Verwendung_XP varchar(30)
    SET @Verwendung_XP = 'P.[Füllstand_FB6_1]';
    DECLARE @Spaltenauswahl nvarchar(30);
    
          SELECT     
    				--top 10
    				   T.[ID]
                      ,T.[TimeStamp_Start]
                      ,T.[TimeStamp_Stop]
                      ,T.Verwendung
                      ,P.[Füllstand_FB6_1] as Anfang
                      ,O.[Füllstand_FB6_1] as Ende
            FROM [SKEMS-HST].[dbo].[Produktionszeiten] as T
            
            INNER JOIN [SKEMS-HST].[dbo].TREND009 AS P
            ON P.Time_Stamp = DATEADD(minute,-1,[TimeStamp_Start])   --or P.Time_Stamp = DATEADD(minute,+1,[TimeStamp_Stop])
            
            INNER JOIN [SKEMS-HST].[dbo].TREND009 as O
            ON O.Time_Stamp = DATEADD(minute,+1,[TimeStamp_Stop]) 
            WHERE (TimeStamp_Start Between @Timestamp_Start and @Timestamp_End) 
    

    Ich denke nun ist auch mein Problem sehr gut zu erkennen.  Ich müsste den Spaltenname P.[Füllbestand_FB6_1] und O.[Füllbestand_FB6_1] dynamisieren. Denn es könnte auch die Spalte P.[Füllbestand_FB5_1] und O.[Füllbestand_FB5_1] sein oder weitere Arten.

    Was mir noch aufgefallen ist das ich nicht einfach eine Abfrage mit einen Parameter machen kann. zb. Select @spaltenname from Tabelle.

    Kann mir jemand helfen?

    Freitag, 19. Mai 2017 14:17
  • Hi,

    wenn Du Objektnamen (Tabellen, Spalten, ...) dynamisch einbauen musst, geht es nicht ohne dynamisches SQL. Ich würde zwar dennoch, wenn irgendwie möglich, eher auf die CASE Variante von Elmar zurückgreifen aber falls das bei dir nicht geht, muss es halt so sein.

    Warum der Fehler bei der Ausführung deines dynamischen SQL Statements kam, hab ich dir ja weiter oben geschrieben. Lösung wäre:

    EXEC( @SQL )

    (also mit Klammern um den Variablennamen) oder eben:

    EXEC sp_executesql @SQL


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Freitag, 19. Mai 2017 14:50
    Moderator
  • Hallo Toot,

    was ich mit CASE und ein, zwei Spalten gemacht habe, kann man auch mit vielen Spalten machen. Das SQL wird länglich ja, aber vermeidet die Dynamik.

    Was das Design angeht, ein (mehr oder minder) passendes Beispiel:

    Niemand würde sein Besteck durchnummerieren und jedes Messer, Gabel, Löffel in einzelne Schubladen packen. Was in etwa beschreibt, wenn man für jeden Zustand eine eigene Spalte erstellt. Man würde eher jeweils eine Schublade (Tabelle) für Zusammengehöriges verwenden und das Ganze stapeln (Tabellen => Zeilen).

    Dass man Konstrukte wie @Spalte FROM @Tabelle nicht schreiben kann, liegt daran, dass der SQL Server daraus einen Abfrageplan kompiliert und dazu die Informationen (Metadaten wie Statistiken) vorliegen haben möchte, damit was Vernünftiges (Schnelles) herauskommt. (Und man sollte nicht unterschätzen, wie viel  Arbeit da rein gesteckt wird, um selbst seltsame Konstrukte gut umzusetzen).

    Deswegen ist dynamisches SQL dafür erforderlich, was als Pferdefuß dazu führt, dass u. U. sehr viele Pläne erstellt werden müssen, die eigentlich immer das gleiche bedeuten. Was einem Menschen wohl anhand der Bezeichner klar werden mag; soweit geht es aber beim Rechner mit der Analyse von Ausdrücken noch nicht.

    Wenn Du das Design nicht ändern kannst/willst, so gäbe es die Möglichkeit Inline Funktionen oder Sichten zu erstellen, die die (fast immer) gleiche Aufgabe des Umstellen / Auswählen von Spalten in der  Zeilendarstellung erledigen könnten.

    P. S.: Wenn Du aufräumst, räume bitte auch bei Deiner Datumsberechnerei auf. Das Konstrukt lohnt nicht, nur damit man BETWEEN verwenden kann.

    Gruß Elmar

    Freitag, 19. Mai 2017 16:06
  • Hallo und dickes Danke an alle die mir hier geholfen haben. Ich habe viel dazugelernt. Jedoch führt letztendlich kein Weg an dynamischen SQL vorbei. LEIDER!

    Nun habe ich dadurch aber auch gleich das nächste Problem.

    Das Ziel ist es nun alle entstandenen Prozeduren (Funktionen können ja leider nicht Werte zwischenspeichern) in einem Bericht zu nutzen.

    Ich würde also jetzt gerne in einem schon bestehenden Dataset meine Prozeduren mit hinzufügen und diese, mit Hilfe der grafischen Werkzeuge, joinen. Jedoch lassen sich Prozeduren nicht in ein Dataset hinzufügen.

    Was kann ich hier nun tuen?


    Donnerstag, 8. Juni 2017 13:19