Statistik – Parameterparser wertet ZS-Markierungen innerhalb von SQL-Kommentaren aus

Rainer Gunstmann

Wir sind bei der Erstellung einer eigenen SQL-Statistik auf ein reproduzierbares Verhalten des Statistik-Parsers gestoßen.

Eine Zeichenfolge, die wie der Beginn eines tomedo-Statistikparameters aussieht, wird offenbar auch dann vom Parameterparser verarbeitet, wenn sie sich ausschließlich innerhalb eines regulären SQL-Blockkommentars /* ... */befindet.

Kommentare im SQL Befehlsblock finden wir sehr wichtig, weil wir bei unseren individuellen Statistiken in ein paar Monaten die Übersicht über die Funktionalität verlieren. Unser Wunsch Informationen auf der Statistik Seite direkt einzublenden fand ja leider keine Beachtung.

Zur Reproduktion haben wir die Abfrage auf ein minimales Beispiel reduziert. Der Kontrolltest ohne die Zeichenfolge funktioniert. Wird ausschließlich im Kommentar die entsprechende Markierung ergänzt, erscheint bereits beim Auswählen der Statistik „Ungültig parameterisierte SQL-Abfrage / Unzulässiger Parameter-Typ“.

Die eigentliche SQL-Anweisung ist in beiden Fällen lediglich select 1 as "Test";.

Nach unserem Verständnis sollte der tomedo-Präprozessor Inhalte von SQL-Kommentaren bei der Erkennung der Statistikparameter ignorieren.

Anbei Screenshot/Fehlertext sowie die beiden minimalen Testabfragen.

/* ============================================================

 * TEST C

 *

 * Der folgende Text ist ausschließlich SQL-Kommentar:

 *

 * <ZS:queryParameter1> SELECTION

 *

 * PostgreSQL darf diesen Inhalt nicht auswerten.

 * ============================================================ */



select

    1 as "Test";

[OS 26.6.2, tomedo v1.170.0.20] Exception: '-[__NSCFString substringWithRange:]: Range {158, 9223372036854775649} out of bounds; string length 313'

stack trace:

#0 CoreFoundation 0000000001832DB1E4 __exceptionPreprocess()

#1 tomedo 000000000108C33360 ZSExceptionPreprocessor()

#2 libobjc.A.dylib 000000000182D5691C objc_exception_throw()

#3 CoreFoundation 0000000001833D8C24 mutateError()

#4 CoreFoundation 0000000001832595F4 -[NSConstantDictionary objectForKey:]()

#5 tomedo 000000000107447248 -[ZSSQLParameterTableViewController prepareParameterViewsForStatistik:]()

#6 tomedo 000000000107395964 -[ZSStatistikWindowController onAbfrageSelected:]()

#7 tomedo 000000000107393690 -[ZSStatistikWindowController outlineViewSelectionDidChange:]()

#8 CoreFoundation 0000000001832619EC __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__()

#9 CoreFoundation 0000000001832EE0BC ___CFXRegistrationPost_block_invoke()

#10 CoreFoundation 0000000001832EE000 _CFXRegistrationPost()

#11 CoreFoundation 000000000183230408 _CFXNotificationPost()

#12 Foundation 000000000184A674A4 -[NSNotificationCenter postNotificationName:object:userInfo:]()

#13 AppKit 00000000018778E060 -[NSTableView _sendSelectionChangedNotificationForRows:columns:]()

#14 AppKit 000000000187742084 -[NSTableView _enableSelectionPostingAndPost]()

#15 AppKit 0000000001879393EC -[NSTableView mouseDown:]()

#16 AppKit 0000000001879383C0 -[NSOutlineView mouseDown:]()

#17 AppKit 000000000187837C64 -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:]()

#18 AppKit 0000000001877C6224 -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:]()

#19 AppKit 0000000001877C5E94 -[NSWindow(NSEventRouting) sendEvent:]()

#20 AppKit 0000000001882364C8 -[NSApplication(NSEventRouting) sendEvent:]()

#21 tomedo 0000000001058F6814 -[PKAppProtectionCoordinator sendEvent:]

#22 AppKit 000000000187E836D8 -[NSApplication _handleEvent:]()

#23 AppKit 000000000187695164 -[NSApplication run]()

#24 AppKit 00000000018766D7B0 NSApplicationMain()

#25 tomedo 0000000001049B8D6C main()

#26 dyld 000000000182DE44E4 start()

userInfo: (null)

Wir konnten das Verhalten noch weiter eingrenzen. Das Problem betrifft offenbar nicht nur Parameter-Markierungen, die versehentlich innerhalb eines SQL-Kommentars stehen.

Bei einer weiteren Statistik befinden sich reguläre tomedo-Parameter außerhalb der Kommentare. Die SQL-Abfrage enthält lediglich normale Blockkommentare /* ... */ zur Dokumentation.

Die ursprünglich gespeicherte Abfrage enthält beispielsweise einen vollständig geschlossenen Kommentar:

/* ... ZEITRAUM ... */

Nach der Parameteraufbereitung durch tomedo erscheint im ausgeführten SQL jedoch:

/* ... ZEITRAUM ...

Das abschließende */ ist dabei verschwunden. PostgreSQL bricht anschließend erwartungsgemäß mit

Unterminated block comment ... Expected */ sequence

ab.

Im selben Lauf wurden die ausgewählten Statistikparameter selbst korrekt ersetzt. Beispielsweise wurde die Quartalsauswahl korrekt zu

( X.datum >= '2026-07-01 00:00:00' and X.datum <= '2026-09-30 23:59:59' ) and

aufgelöst. Auch ein SELECTION-Parameter wurde korrekt zu false or true aufgelöst.

Der Fehler scheint daher bei der textuellen Vorverarbeitung der SQL-Abfrage bzw. beim Entfernen/Ersetzen der Statistikparameter aufzutreten. Dabei können offenbar Teile angrenzender SQL-Blockkommentare entfernt werden.

Als Workaround werden wir zunächst ausschließlich ---Zeilenkommentare verwenden.

Falls hilfreich, können wir Ihnen die vollständige ursprüngliche Abfrage sowie das von tomedo nach der Parameteraufbereitung protokollierte SQL zur Verfügung stellen.

Richard Kupke

Hallo Herr Gunstmann,

Ihr Stacktrace lässt sich zeichengenau zurückrechnen:

NSIntegerMax  9223372036854775807   (= NSNotFound)

minus 158                      158

=             9223372036854775649   ← Ihre gemeldete Länge

Und die 158 ist die Position direkt hinter <ZS:queryParameter1> (Tag beginnt bei 138, ist 20 Zeichen lang). Der Parser sucht also das schließende </ZS>, bekommt NSNotFound zurück und rechnet ungeprüft damit weiter. Es fehlt schlicht die Prüfung, ob das Tag geschlossen ist.

Wichtig für den Bugreport: Frame #6 ist onAbfrageSelected: — der Absturz passiert beim Anklicken der Statistik, nicht beim Ausführen. Eine so gespeicherte Statistik lässt sich damit nicht mehr öffnen, um sie zu reparieren.

Zu den Kommentaren trifft Ihre Vermutung zu: Es gibt keinen SQL-Lexer vor dem Parameterparser, er sucht per Stringsuche nach <ZS:. Daraus zwei getrennte Regeln:

Kein <ZS: in Kommentaren, egal welcher Art. Der Wechsel auf -- schützt davor nicht.
-- statt /* */ ist trotzdem richtig — als Schadensbegrenzung: Ein Blockkommentar trägt seinen Terminator am Ende, und genau der geht verloren. Eine ---Zeile endet am Umbruch, da ist nichts zu verlieren.

Dritte Regel derselben Familie: kein % in Kommentaren, das Zeichen ist in tomedo-HQL generell unzulässig.

Ein Gedanke zur Dokumentation. Wenn Ihre Abfragen mit KI-Unterstützung entstehen, kommen sie meist reich kommentiert zurück — genau das kollidiert hier. Für Auswertungen, die dauerhaft leben sollen, fahre ich deshalb zweigleisig: tomedo-Statistiken für alles, was den Absprung in die Kartei braucht, und Metabase für alles andere. Dort hängt an jeder Frage ein eigenes Beschreibungsfeld außerhalb des SQL, es gibt Versionshistorie, Parameter als echte Widgets statt Textersetzung, Dashboards und Zeitpläne. Ihr Wunsch aus Beitrag 124982 ist dort schlicht eingebaut.

Zwei Einschränkungen, damit das nicht zu rosig klingt: Metabase ist eine zusätzliche Installation mit eigenem Berechtigungskonzept, und ZS-Filter funktionieren dort nicht — die Parametrisierung wird neu gebaut. Der Rückweg in die Kartei geht über tomedo://patient#… als Spalten-Link.

Viele Grüße, RIchard Kupke