T-SQL Verschneiden von Stammdaten

Die ersten beiden durchläufe der schleife zerschiessen bisschen was an dem SQL Statement (Post #25).... find ich net heraus warum..... und dann noch der letzte schleifendurchgang mit sqlscript_2 schneidet was ab aber auch wieder keine Ahnung warum (Post #23)....
 
Werbung:
Die ersten beiden durchläufe der schleife
Meinst du damit Durchlauf aller Datensätze?

Ich würde das Debugging so angehen, das nur ein problematischer Datensatz in der Ausgangstabelle steht und von der Schleife verarbeitet wird. Wenn der dann richtig läuft und nur Probleme macht wenn alle Datensätze durchlaufen werden, dann liegt die Ursache in einer Variable die nicht bei jedem Durchlauf zurück gesetzt wird.
 
@listengroesse hatte da was am anfang rumprobiert und vergessen wieder zurück zu wechseln ^^... Danke :)
Mit durchlauf meine ich schleifendurchlauf....
Zu den nicht geleerten variablen das probier ich jetzte mal als nächstes aus... werde nun alle variablen am ende des "selects" zurücksetzen
Edit: Mir ist grad aufgefallane das von 3793 auf 3799 ein Sprung gemacht wird...
 
Zuletzt bearbeitet:
Ehrlich gesagt mir kraust es gerade ein bisschen vor der geballten Macht deiner goto's... einer der vielen Gründe warum man sie nicht einsetzen sollte.
Ein einfaches if hätte es auch getan.
 
Ich hab mir das mal in Ruhe angeguckt aber so nicht wirklich eine problematische Stelle gefunden. Natürlich kann man das ein oder Andere umforulieren, an der Funktion sollte sich dabei aber nichts ändern.

PS: Stimmt mit goto arbeite ich normalerweise auch nicht, da fehlt mir die Erfahrung.
 
Ehrlich gesagt mir kraust es gerade ein bisschen vor der geballten Macht deiner goto's... einer der vielen Gründe warum man sie nicht einsetzen sollte.
Ein einfaches if hätte es auch getan.
Hab das nur so gemacht, weil ichs von VBA gewohnt bin.... hab einfach nicht an ein if gedacht :D ....
Edit: Aber wie hätte ich das mit einem If lösen sollen wenn im selben schleifendurchgang das "case" ein zweites mal genutz werden muss weil mit dem zwischen Ergebnis weiter gearbeitet wird?

Ukulele kannst du mir mal die erste und letzte Ausgabe die du erhältst posten? Will die nämlich mit meiner vergleichen ob nicht ggf. SQL Server Managment Studio etwas bei mir falsch anzeigt....
 
Anfang:
Code:
INSERT INTO BOADMIN.IDSDATEN( PDV_WERT_ST, PDV_DATUM, pdv_startzeit) SELECT trunc(KA2012_ZW.ZW37_WERT,5), KA2012_ZW.DATE_TIME , NULL FROM PDVDATEN.KA2012_ZW where KA2012_ZW.ZW37_WERT is not NULL and ARCHIV is NULL ;  Update BOADMIN.IDSDATEN SET BOADMIN.IDSDATEN.PDV_KENNZEICHEN = 'SUM' Where (((BOADMIN.IDSDATEN.PDV_KENNZEICHEN) Is Null));
Zum Ende komme ich nicht, nach 9:29 Laufzeit ist das Management Studio abgekackt, wundert mich auch irgendwie nicht bei der Menge.
 
Wenn ich die Ergebnisse nicht mit Select auswerfe sondern in eine Tabelle schreibe
Code:
CREATE TABLE test_result(
   schleifenzaehler INT,
   result VARCHAR(MAX)
   );
bekomme ich diese beiden Datensätze mit dem höchsten Schleifenzähler
Code:
update BOADMIN.IDSDATEN set pdv_wert_st = to_char(to_number(pdv_wert_st) * 86.4) where blome_parameter =455 and blome_BP = '20087' and ARCHIV is NULL;  update BOADMIN.IDSDATEN set PDV_WERT_NM = to_number(PDV_WERT_ST) where ARCHIV is NULL;
Code:
update BOADMIN.IDSDATEN set pdv_startzeit =ltrim((to_char(trunc(to_number(pdv_startzeit)),'09'))) || ':' || ltrim((tu_char(trunc((to_number(pdv_startzeit)) - (trunc(to_number(pdv_startzeit))))*60),'00'))) where pdv_typ='HE' and pdv_startzeit is not null and ARCHIV is NULL;  commit;

PS: Ganz am Anfang wird auch einmal NULL zurück geliefert, da ist bestimmt auch was nicht richtig.
 
Hab das nur so gemacht, weil ichs von VBA gewohnt bin.... hab einfach nicht an ein if gedacht :D ....
Edit: Aber wie hätte ich das mit einem If lösen sollen wenn im selben schleifendurchgang das "case" ein zweites mal genutz werden muss weil mit dem zwischen Ergebnis weiter gearbeitet wird?
Ich bin kein MS SQL Expert... Komme aus der Oracle-Ecke.
Und zumindest Oracle lässt mich so genannte Subprograms deklarieren. Quasi eine Prozedur/Funktion die nur zur Laufzeit der derzeitigen Transaktion gültig ist.
Sieht in etwa so aus:

Code:
Declare
   var Varchar2(20);
   number_ Number(10, 0);

   Procedure amazing_stuff(a_variable In Out Varchar2, a_number In Out Number) Is
   Begin
      --do some amazing stuff here!
   End;
Begin
   Select mein_varchar, meine_number
   Into var, number_
   From tolle_tabelle
   Where rowid = 'abc';

   amazing_stuff(var, number_);
End;

Eben die elegante Variante eines GOTO ;)

Edit:
Hier mal ein kleines Beispiel von Rekursion...
Code:
Declare
   my_var Number;

   Procedure abc(some_number In Out Number) Is
   Begin
     some_number := some_number + 1;
     If some_number < 255 Then
       abc(some_number);
     End If;
   End;
Begin
  my_var := 1;
  abc(my_var);
  dbms_output.put_line(to_char(my_var));
End;
 
Zuletzt bearbeitet:
Ich würde sagen der Code funktioniert grundsätzlich. Nur das Ergebnis sollte vieleicht wirklich nochmal in eine Tabelle, da scheinen bei mir bis auf den einen NULL Wert nur vollständige SQL Codes zu liegen.
 
Hast du von deinem bisherigen Code das Ergebnis einfach mal in eine Tabelle geschrieben? Treten dann noch die Fehler auf?
 
Werbung:
Ich würde sagen der Code funktioniert grundsätzlich. Nur das Ergebnis sollte vieleicht wirklich nochmal in eine Tabelle, da scheinen bei mir bis auf den einen NULL Wert nur vollständige SQL Codes zu liegen.
Mir ging es garnicht darum das der Code nicht funktioniert... Sobald das ganze läuft, darf es derzeit keine Änderungen geben... In 2 Wochen weiß nämlich niemand mehr wie dieser Code funktioniert, was er macht und warum er es macht... :)

Man muss das ganze ja nicht in eine Prozedur auslagern... Man kann das ganze auch noch weiter kapseln (was ich sehr empfehlen würde...)...
 
Zurück
Oben