Durchlaufen einer Ergebnismenge (T-SQL) und anhand dieser ein parametrisierter Aufruf einer Query

[T_Pettbörg]

zwei Tabellen:

Anlagen
Anl_ID
Nord_A2
Nord_A3
Nord_A4
Süd_A1
Süd_A2
Süd_A3
West_A1
West_A2

Werte
Anl_ID Zeit Art
Nord_A2 1 Fehler_1
Nord_A2 1 Fehler_1
Nord_A2 1 Fehler_1
Nord_A2 2 Fehler_1
Nord_A3 1 Fehler_1
Nord_A3 1 Fehler_1
Nord_A3 2 Fehler_2
Nord_A4 2 Fehler_3
Nord_A4 1 Fehler_4
Nord_A4 1 Fehler_5


Gewünscht ist eine StoredProcedure SP:
rs.OpenRecordset="Select Anl_ID From Anlagen"

rs.MoveFirst

While not rs.EOF Do
SQL="Select * From Werte Where Anl_ID =" & rs!Anl_ID & "

"Insert into andere Tabelle

rs2.execute sql

rs.MoveNext

Wend



Die eine Tabelle Anlage durchlaufe.

Anhand der gefundenen Einträge Anl_ID die andere Abfrage ausführen

Welche dort gefundene Daten (aggregiert) in eine andere Tabelle hineinschaufelt
Der Code ist leider zu VB-Lastig und wird in der MS-SQL-Server-SP nicht laufen.
Kann mir jmd. bei der Syntax helfen?

 

[ukulele]

Ich kann dir nicht folgen, vermutlich auch weil du keine richtigen Sätze schreibst die erklären, was du tun willst.

Die eine Tabelle Anlage durchlaufe.

Warum gibt es eine Tabelle die nur eine Spalte Anl_ID hat? Oder sind das da drunter keine Werte sondern weitere Spalten?

Anhand der gefundenen Einträge Anl_ID die andere Abfrage ausführen

Du müsstest ja sinnvoller Weise etwas anderes als die Anl_ID haben damit du diese Tabelle sinnvoll abfragen kannst. Sonst kannst du auch direkt mit der Anl_ID die Werte Tabelle abfragen.

Warum soll eine SP etwas "durchlaufen" wenn ein Select alle Daten liefert?

Warum soll das in eine andere Tabelle geschrieben werden wenn eine View alles ausgeben kann?

 

[dabadepdu]

Also die Formulierung ist schon okay, aber die Bedenken von ukulele teile ich.

1. Du könntest ein einziges Statement für den Vorgang nutzen (das wahrscheinlich sorgar schneller wäre, als eine SP)
Prinzip: Insert into <zieltabelle> (<feldliste>) Select <Feldliste> from Anlagen where <Bedingung>

2. Eine SP macht an der Stelle nur Sinn, wenn (teilweise) aufwändige/fallweise Berechnungen/Subselects zur Vervollständigung der Insert Daten benötigt werden. (eine Abwägungssache)

3. Andernfalls kein ein View oder Select jederzeit die benötigten Daten "life" darstellen und es wird weder die Zieltabelle, noch die SP, noch (2.) benötigt.

 

[T_Pettbörg]

Hallo Zusammen,

vielen Dank für Eure Beiträge.
Das ist nur eine stark vereinfachte Darstellung von einer komplexen Massendatensituation im MES-SCADA Umfeld... Export im SQL-Server für QlikView.
Anhand der Tabelle 'Anlagen' sollen (konfigurierbar) mehr oder weniger Anlagen-Daten (Delta-täglich) geschaufelt werden.
Pro Anlage/Werk habe ich die mehrere komplexe aber gleichartige Abfragen blockweise angelegt.

Die vielen gleichartigen Abfrageblöcke sollen durch einen Abfrageblock mit Schleife ersetzt werden.
Quasi über die Anlagen-Tabelle konfigurierbar gemacht werden.

 

[T_Pettbörg]

ich weiss, dass das nicht ganz sauber und gesamtoptimal ist. Aber so braucht man das ,-)

Macht man das am besten mit Fetch und Cursor? So wie hier gelöst:
Zeilenweises Durchlaufen einer SELECT-Anweisung

 

[T_Pettbörg]

Die SP inkl. der gleichartigen Abfrageblöcke besteht schon. Jetzt muss nur noch die Schleife drum, um den parametrisierten (nach Werk und Anlage) Abfragenblock, damit Kunde selbständig weitere Anlagen anbinden kann

 

[ukulele]

Also MSSQL Cursor ist mit hoher Wahrscheinlichkeit besser und schneller als MSSQL mit WHILE-Schleife, die ich ja auch in dem verlinkten Thread gezeigt habe. Ich lerne ja auch dazu ;-) Am besten wäre natürlich ein Insert/Select der alles abfrühstückt, aber ich sehe ein das es manchmal Gründe gibt. Du könntest noch mit MERGE arbeiten aber das hat manchmal seine Tücken, ich kann weiß leider nicht mehr aus dem Kopf welche Konstellation mir da mal massiv Probleme gemacht hat.

Um bei Cursorn zu bleiben,: Vorteil des Cursors ist auf jeden Fall auch die Möglichkeit mit BEGIN TRY END TRY BEGIN CATCH insert into tbl_errors values 'bla' END CATCH Fehler sinnvoll in einer Tabelle zu sammeln. Scheitert der Code aus dem TRY-Block schmiert dir auch nicht die ganze Prozedur ab.

Auch SPs haben ihre Tücken, du weißt im Prinzip nichts über den Status außerhalb deiner Prozedur.

 

[dabadepdu]

Auch SPs haben ihre Tücken, du weißt im Prinzip nichts über den Status außerhalb deiner Prozedur.

Was meinst Du damit?

Die SP inkl. der gleichartigen Abfrageblöcke besteht schon. Jetzt muss nur noch die Schleife drum, um den parametrisierten (nach Werk und Anlage) Abfragenblock, damit Kunde selbständig weitere Anlagen anbinden kann

Klingt wie eine Erklärung, sagt aber nichts aus. Kann man dann auch durch "ich möchte das so" ersetzen.

 

[T_Pettbörg]

Vielen lieben Dank Euch.
@ukele:
Zum Zitat 1: Man müßte sich ein gescheites Error-Handling einfallen lassen. Ist aber hier sehr eingeschränkt glaube ich. Es gibt aber "Bei Fehler" einer Rückmeldeparameter, dann man abgreifen kann, .. für Nagios oder so
Zum Zitat 2. "Ich möchte das so" ist richtig. Eher gesagt: Der Umstand (die Beteiligten) können es so besser verstehen


Die Lösung ungefähr:

----------------------------------------------------------
DECLARE @Anlage as nvarchar(256)

DECLARE @Anl_ID as int


DECLARE anl_cursor CURSOR FOR

SELECT Anl_ID, Anlage

FROM dbo.anlagen;




OPEN anl_cursor;

FETCH NEXT FROM anl_cursor INTO @Anl_ID, @Anlage;

WHILE @@FETCH_STATUS = 0

BEGIN

—- Nachfolgende Zeile dient anfangs nur zur Kontrolle, kann später gelöscht werden.

Print ' ' + @Anl_ID + ' '+ @Anlage



INSERT INTO dbo.newtab (Anl_ID, Anlage)

SELECT Anl_ID, Anlage FROM werte WHERE Anlage = @Anlage


FETCH NEXT FROM anl_cursor INTO @Anl_ID, @Anlage




END;


CLOSE anl_cursor;

DEALLOCATE anl_cursor;


GO
------------------------------------

Wahrscheinlich wäre die bessere Lösung über CTE ... WITH

 

[ukulele]

Was meinst Du damit?

Wenn du eine Schleife oder einen Cursor direkt laufen läßt kannst du dir mit SELECT oder PRINT oder so zwischendurch mal einen Status holen oder du siehst halt X Datensätze erfolgreich upgedated oder so dann weißt du das der Server nicht hängt sondern das er wirklich was tut. Läuft das ganze in der SP würden auch diese Meldungen in der SP bleiben, du siehst nichts davon.

 

[dabadepdu]

Okay, so ist es oft. "Besser verstehen" ist ja auch nicht verkehrt.

Wegen Status und Meldung: Es gibt ja die Möglichkeit Logs zu schreiben. Und sogar MS hat offenbar so eine Art autonome Transaktionen, allerdings braucht man dafür einen 2. Server, wenn ich das richtig gelesen habe. Gut für den Lizenzverkauf..