SMO is incorrectly defaulting the schema-identifier, when it shouldn't be (e.g. on CREATE PROCEDURE).
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 35/100
Rechercherichtung
Reproduziere das Problem mit den gespeicherten Prozedurskripten TEST1 und TEST2 und untersuche anschließend die Scripting-Optionen und das API-Verhalten von SMO für Prozeduren, Ansichten und UDFs. Vergleiche die generierten Definitionen mit Schema Compare; abgeschlossen ist die Aufgabe, wenn ein weggelassenes Schema weiterhin weggelassen wird, sodass gleichwertige Objekte nicht als unterschiedlich gemeldet werden.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Create a database, e.g. TEST1, and create the following stored-procedure:
CREATE PROCEDURE GetServerName AS BEGIN SELECT @@SERVERNAME END
Note: no schema identifier was provided above.
Now, in something like SSMS (or Azure Database Studio), whatever, query the stored-procedure (sp) and it clearly states that it belongs to dbo/schema_id=1.
Now, to exercise SMO, use SSMS (or whatever) and generate the SQL to CREATE the sp, and you'll get:
CREATE PROCEDURE [dbo].[GetServerName] AS BEGIN SELECT @@SERVERNAME END
You'll notice that it's added the schema, [dbo].
I think, that this could actually be a bug. I contend that it shouldn't have added the schema.
Why? Well, apparently it makes a difference . . .
Now, create a second database, e.g. TEST2, and apply the generated sp, then compare, either with (i) Azure Data Studio's "Schema Compare" tool, or (ii) DacFx's SchemaComparison (I assume they are the same thing) and . . . it flags a difference: the SQL it generates for TEST1 doesn't have the schema, but the SQL it generates for TEST2 does have the schema.
My question is: how can I configure SMO options (for calling from C#) to only generate the schema-identifier value it was originally provided (or nothing, if that's the case)? With that, I could run DacFx/SchemaComparison and the two objects would be considered identical.
There could be a little debate as to whether the issue is SMO or DacFx/SchemaComparison, but it seems logical the problem originates in SMO.
Note: the same problem applies to views, UDFs, etc.
- Vorherrschende Sprache
- C#
- Sterne
- 143
- Forks
- 28
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Entwicklungsumgebung
Die Einrichtungsdateien dieses Projekts haben wir noch nicht geprüft. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus microsoft/sqlmanagementobjects
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 62/100
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 72/100
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 74/100
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 78/100
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 68/100
Alle Issues in microsoft/sqlmanagementobjects
Ähnliche Issues
-
agentic-workflows area/Docs partner/agentic-workflows
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
microsoft/fluentui-blazor#5364 ·
Maintainer antworten meist innerhalb von 1 Tag
-
.NET triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
microsoft/agent-framework#8811 ·
Maintainer antworten meist innerhalb von 1 Tag
-
.NET Docs
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 82/100
getsentry/sentry-dotnet#5637 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 2 Tagen
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
QuantConnect/Lean#9842 ·
Maintainer antworten meist innerhalb von 1 Tag