Debug Stored Procedure

strzata

Benutzer
Beiträge
24
Hallo,
in einer ellenlangen StoredProcedure (MySQL 8.0) tritt beim Umzug von 5.6 auf 8.0 ein Fehler auf. Ich werde ihn wohl nur finden können, wenn ich das Kontrukt debuggen kann. Aber VisualStudio lässt mich dabei im Stich oder ich bin zu dumm, es richtig zu machen. Nun habe ich gelesen, dass man mit der Workbench SPs debuggen kann. Aber auch hier komme ich nicht zurecht. Wo ist da ein Button für Debug?
Könnt ihr mir helfen? Danke!
Grüße Norbert
 
Werbung:
von MySQL 5.6 auf 8 wurden einige der schlimmsten Bugs in MySQL gefixt. Möglicherweise basierte die Funktion Deiner SP auf die Unwissenheit dieser Bugs. Zum Beispiel 'wußte' MySQL nicht, daß bei Aggregationen alle Spalten aggregiert oder gruppiert sein müssen. An Deiner Stelle würde ich mir die Fehlermeldung, die Du ja hier nicht zeigst, solange laut vorlesen, bis ich diese auswendig kann. Und dann mal drüber nachdenken.
 
Danke für die schnelle Reaktion! Natürlich zeige ich gern hier die Fehlermeldung:
upload_2020-2-23_16-18-32.png
Ich wüßte zu gern, in welcher Zeile diese Eyception geworfen wird. Wie komme ich dahinter? Ich denke, in einem SELECT, dessen Ergebnis weiter verarbeitet wird, kommt ein Leerstring zurück, der nicht in ein DATE umgewandelt werden kann. Die SP lief unter 5.6 astrein.
Ja, die Bugs kenne ich nicht. Hast eine gute Quelle, wo ich das alles nachlesen kann (für mich als Laien).
 
Ich hab von MySQL kaum Ahnung, sorry. Das war ja schon vor 20 Jahren bekanntermaßen kapott, damals entschied ich mich für PostgreSQL (für ein kleines Projekt @ work, heute verdiene ich damit mein Geld)

Aber ich tippe mal, da ist eine Spalte (varchar oder sowas), die oft ein DATE als Text enthält, und manchmal halt ein leeren String. Wäre vielleicht der Mühe wert, sich mal alle Tabellendefinitionen anzusehen.

Bugs in MySQL (kleine Auswahl):
  • Akzeptanz falscher Datumswerte wie '' oder '0000-00-00' oder '2019-02-29'
  • falsches reagieren bei Abfragen mit Aggregationen, wenn nicht alle nicht-aggregierten Spalten gruppiert sind. Zufallsergebniss statt Fehler
  • Syntax-Prüfung von Check-Constraints, ohne diese dann zu beachten
  • NULL-Handling (teilweise) kapott
  • fehlen von Features, die seit 20 Jahren im SQL-Spec sind und von allen anderen Datenbanken realisiert sind (Window-Funktionen, lateral join, funktionale/partielle Indexe, ...)
 
Vielen Dank für Deine Ausführungen. In der SP werden 8 Tabellen verarbeitet und in jeder davon gibt es Datums-Felder, die leer sind oder NULL haben. Hab in der SP aus DATE jetzt VARCHAR gemacht und da läuft sie. Hätte dennoch gern mal ein Debug gestartet, um nachzusehen, was da eigentlich gemacht wird. Hab noch kein Tool gefunden, mit dem das gehen würde ...
 
Werbung:
Danke Dravion. Den Artikel kannte ich und ich hab schon alles ausprobiert, was da steht. Weiter als bis zum Punkt 11.2 komme ich nicht. Ich kann die IN-Parameter eingeben. Aber ein Debugging Step by Step bekomme ich einfach nicht gebacken ...
 
Zurück
Oben