Skriptentwickung/dev/[DD_ECM_REF]-Database/plan.md

Plan: Neue transaktionssichere Treeview-Prozedur

Die neue Prozedur wird in DD_ECM_REF erstellt und ausgeführt, liest zuerst aus DD_ECM, verarbeitet die Daten vollständig lokal in temporären/klassischen Tabellen und vermeidet jede Schreiboperation auf memory-optimized Tabellen innerhalb desselben Aufrufs. Dadurch bleibt sie auch bei offener äußerer User-Transaktion lauffähig und umgeht Msg 41317. Die Ausgabe erfolgt als Resultset direkt aus lokaler Arbeitsmenge statt aus MOTB_MON_TREEVIEW_RESULTS.

Steps

1. Phase 1: Ist-Logik in DD_ECM_READ-Teil und REF_WRITE-Teil zerlegen, inklusive aller Stellen mit Cross-DB-Read und MOT-Zugriff. Grundlage sind die Zugriffe in [PRMOT_MON_GET_TREEVIEW_RESULTS]_ok.sql.
2. Phase 1: Neue Zielprozedur in DD_ECM_REF entwerfen, die Eingaben SEARCH_VALUE und USR_ID beibehält und die Ergebnisstruktur zur bisherigen Ausgabe kompatibel liefert. Diese Prozedur verwendet nur lokale #Temp-Tabellen für den Aufbau der Baumdaten.
3. Phase 2: Cross-DB-Vorstufe implementieren: DD_ECM-Reads ausschließlich in lokale #Temp-Tabellen laden (MessageIDs, AddedWhen und ggf. weitere Felder), bevor irgendeine weitere Verarbeitung stattfindet. Diese Phase ist nur lesend gegenüber DD_ECM.
4. Phase 2: Bestehende Cursor-/Loop-Logik auf lokale #Temp-Tabellen umstellen; Aufrufe von PRMOT_MON_TREEVIEW_ADD_ROW durch direkte Inserts in lokale Ergebnistabelle ersetzen. Abhängigkeit: Schritt 3.
5. Phase 2: Aufruf von PRMOT_MON_GET_TREEVIEW_RESULTS_PER_MESSAGEID entkoppeln. Falls diese Prozedur auf MOT schreibt, wird eine neue lokale Hilfsvariante erstellt, die nur in #Temp-Ergebnistabellen schreibt. Abhängigkeit: Schritt 4.
6. Phase 3: Finale Ausgabe ausschließlich per SELECT aus lokaler Ergebnistabelle zurückgeben, sortiert wie bisher nach GUID. Kein Zugriff auf MOTB_MON_TREEVIEW_RESULTS in der neuen Prozedur.
7. Phase 3: Vorhandene Prozedur unverändert lassen und neue Prozedur mit neuem Namen bereitstellen (zuerst Parallelbetrieb), damit Rückfallpfad vorhanden bleibt.

Relevant files

• [PRMOT_MON_GET_TREEVIEW_RESULTS]_ok.sql([PRMOT_MON_GET_TREEVIEW_RESULTS]_ok.sql) — Referenz für bestehende Suchlogik, Cursorfluss und Ausgabeverhalten.
• [PRMOT_MON_GET_TREEVIEW_RESULTS]_ok.sql([PRMOT_MON_GET_TREEVIEW_RESULTS]_ok.sql#L48) — aktueller MOT-DELETE-Zugriff, in neuer Prozedur zu vermeiden.
• [PRMOT_MON_GET_TREEVIEW_RESULTS]_ok.sql([PRMOT_MON_GET_TREEVIEW_RESULTS]_ok.sql#L70) — DD_ECM-Read INVOICE_NUMBER.
• [PRMOT_MON_GET_TREEVIEW_RESULTS]_ok.sql([PRMOT_MON_GET_TREEVIEW_RESULTS]_ok.sql#L74) — DD_ECM-Read HISTORY.
• [PRMOT_MON_GET_TREEVIEW_RESULTS]_ok.sql([PRMOT_MON_GET_TREEVIEW_RESULTS]_ok.sql#L125) — DD_ECM-Read CREATEDWHEN.
• [PRMOT_MON_GET_TREEVIEW_RESULTS]_ok.sql([PRMOT_MON_GET_TREEVIEW_RESULTS]_ok.sql#L135) — Abhängigkeit zu PER_MESSAGEID.
• [PRMOT_MON_GET_TREEVIEW_RESULTS]_ok.sql([PRMOT_MON_GET_TREEVIEW_RESULTS]_ok.sql#L173) — bisherige Endausgabe aus MOT-Tabelle.

Verification

1. Technischer Negativtest: Ausführung der neuen Prozedur innerhalb BEGIN TRAN/COMMIT bei offenem Transaktionskontext; erwartetes Ergebnis: kein Msg 41317.
2. Funktionaler Vergleichstest: identische Suchwerte mit alter und neuer Prozedur ausführen, Ergebnisanzahl und Sortierung vergleichen (mindestens 10 reale Belegnummern).
3. Randfalltest: Suche mit zu kurzer Belegnummer, keine Treffer, Treffer > BATCH_SIZE, führende Nullen in SEARCH_VALUE.
4. Parallelitätstest: gleichzeitige Aufrufe mit unterschiedlichen USR_ID; erwartetes Ergebnis: keine gegenseitige Beeinflussung.
5. Performance-Schnelltest: Laufzeitvergleich alt/neu für typische und teure Suchfälle (LIKE mit Wildcards).

Decisions

• Muss auch bei offener äußerer User-Transaktion laufen.
• Darf weiterhin aus DD_ECM lesen.
• Neue Prozedur wird in DD_ECM_REF gespeichert und ausgeführt.
• Zur Behebung von Msg 41317 werden MOT-Schreib-/Lesezugriffe in der neuen Prozedur vollständig vermieden.

Further Considerations

1. Kompatibilitätsentscheidung: Soll die alte MOTB_MON_TREEVIEW_RESULTS als Persistenzziel künftig entfallen, oder braucht ihr zusätzlich eine optionale Nachschreib-Prozedur außerhalb der offenen Transaktion?
2. Abhängigkeitsentscheidung: Falls PER_MESSAGEID zwingend benötigt wird und MOT-Zugriffe enthält, sollte eine zweite, temp-table-basierte Variante mit gleicher Fachlogik erstellt werden.
3. Betriebsentscheidung: Für den Produktivschnitt kann ein Feature-Flag sinnvoll sein, um schrittweise von alt auf neu umzuschalten.