Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

ScriptDom interprets ambiguously the next word right after transaction control statement

Offen
  • Stimmt etwas nicht?
#70 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
25/100
Issue-Typ
Bug
Klarheit
Muss geklärt werden
Aktivitätsstatus
Veraltet
Tech-Stack
sql
Bereich
compilers

Rechercherichtung

Beginne damit, die BEGIN-, SAVE-, COMMIT- und ROLLBACK-Beispiele mit den ScriptDom-Kompatibilitätsstufen 150 und 160 nachzustellen. Prüfe, wie Transaktionsnamen und nachfolgende aus einem Wort bestehende Anweisungen klassifiziert werden, und definiere dann das erwartete Verhalten für Fälle wie THROW und CONTINUE; das Issue ist abgeschlossen, wenn die Mehrdeutigkeit aufgelöst oder konsistent eine Warnung ausgegeben wird.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

bug
  • ScriptDom Version: 161.8910.0
  • CompatibilityLevel used for parsing: 150, 160

Some keywords written right next to the transaction control statement are treated as transaction name and some as a separate command/next statement. This may lead to significant misunderstanding of what the code will actually do.

Statements:

  • BEGIN TRAN
  • SAVE TRAN
  • COMMIT TRAN
  • ROLLBACK TRAN

Examples of keywords/statements treated as valid identifier for transaction name:

  • THROW
  • RECEIVE
  • SEND

Steps to Reproduce:

If you write BEGIN TRAN THROW - here THROW will be treated as a valid transaction name. However in BEGIN TRAN CONTINUE the CONTINUE will be treated as a separate command. BEGIN/COMMIT/ROLLBACK behave similarly - they can take modern keywords/commands as a valid tran name but "ignore" "oldschool" keywords/commands and treat them as a separate statement even if no statement terminator is present between them. SAVE TRAN unlikely mentioned statements requires transaction name to be provided and if the next word is parsed as an invalid tran identifier candidate the parsing fails with syntax error.

Examples of ambiguity:

COMMIT TRAN CONTINUE
COMMIT TRAN BREAK
COMMIT TRAN THROW     -- tran name
COMMIT TRAN RECEIVE   -- tran name
COMMIT TRAN SEND      -- tran name
COMMIT TRAN RETURN
COMMIT TRAN COMMIT
COMMIT TRAN ROLLBACK

in all lines not marked with comment the last word is treated as a separate statement.
SAVE TRAN requires third word in statement and in all lines except marked with comment parser would say that syntax is broken:
image

The most ambiguous case to me is this one:

BEGIN TRY
    BEGIN TRAN

    SELECT 1 / 0

    COMMIT TRAN
END TRY
BEGIN CATCH
    ROLLBACK TRAN
    THROW -- "Divide by zero" error will not be rethrown here
          -- new error will be generated:
          -- Cannot roll back THROW. No transaction or savepoint of that name was found
END CATCH

On ROLLBACK TRAN docs page it is said that transaction name must be a valid identifier, identifier is valid if it does not match any of reserved words and THROW is not listed there. On THROW docs page it is said that preceding statement must end with semicolon. Thus ROLLBACK TRAN THROW in the example above behaves expectedly speaking of the docs. But it is an error so easy to make and you need so much to remember to avoid it while coding.

It would be great if

  • all one-word statements were included into reserved keywords (especially THROW); maybe in future compatibility levels
  • SSDT/DacFx would show at least a warning in such cases and recommend to put semicolon before THROW or choose another identifier for transaction name

As a workaround I'm developing another rule for our custom linter which would detect such suspicious cases.

(DacFx/SqlPackage/SSMS/Azure Data Studio)

Vorherrschende Sprache
GAP
Sterne
278
Forks
46
Ø Merge
9 T. 23 Std.
Gemergte PRs (30 T.)
2

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus microsoft/SqlScriptDOM

Alle Issues in microsoft/SqlScriptDOM

Ähnliche Issues

Weitere Issues zu Compilers

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.