9
MSSQL, Problem bei ausführen einer SP (remote)
Hallo zusammen,
bei meinem Problem geht es darum, das wir Datenbanken einer Software haben, die auf Grund von Templates der Software erstellt und wir hier keine Änderungen machen dürfen. In den Datenbanken gibt es Views und StoredProcedures, die Daten aus den Tabellen zusammenstellen.
Um Statusdaten abfragen zu können, muss ich auf eine immer gleich benannte StoredProcedure zugreifen, die zur passenden DB-Version die Tabellen und Felder abfrägt, was je nach Version unterschiedlich sein kann.
Eine "simple" SP liefert zum Beispiel nur True oder False zurück, habe mir die SP mal angeschaut, die Rückgabe erfolgt nur über "Select 'True'" oder "Select 'False'", ohne den Spaltennamen mitzugeben (as ...).
Rufe ich diese SP mit OpenRowSet auf, geht das solange gut wie der Rückgabewert "False" ist, sobald ein "True" zurückgegeben wird, erhalte ich wegen der Unterschiedlichen Länge die Meldung:
Rufe ich die SP von zwei DB manuell auf (jeweils Rückgabe True oder False), bekomme ich das Ergebnis ohne Fehler (was zu erwarten war), mache ich das in einer Schleife, wird der Fehler geworfen sobald die erste DB den Wert True zurückgibt.
Habt Ihr mir ein Tipp wie ich das anpassen kann, insbesondere wie ich die Spalte "fassen" kann da hier kein Name zurückgegeben wird?
bei meinem Problem geht es darum, das wir Datenbanken einer Software haben, die auf Grund von Templates der Software erstellt und wir hier keine Änderungen machen dürfen. In den Datenbanken gibt es Views und StoredProcedures, die Daten aus den Tabellen zusammenstellen.
Um Statusdaten abfragen zu können, muss ich auf eine immer gleich benannte StoredProcedure zugreifen, die zur passenden DB-Version die Tabellen und Felder abfrägt, was je nach Version unterschiedlich sein kann.
Eine "simple" SP liefert zum Beispiel nur True oder False zurück, habe mir die SP mal angeschaut, die Rückgabe erfolgt nur über "Select 'True'" oder "Select 'False'", ohne den Spaltennamen mitzugeben (as ...).
Rufe ich diese SP mit OpenRowSet auf, geht das solange gut wie der Rückgabewert "False" ist, sobald ein "True" zurückgegeben wird, erhalte ich wegen der Unterschiedlichen Länge die Meldung:
Msg 7356, Level 16, State 1, Line 173
The OLE DB provider "SQLNCLI11" for linked server "(null)" supplied inconsistent metadata for a column. The column "(null)" (compile-time ordinal 1) of object "EXEC DBName.Schema.SPName" was reported to have a "LENGTH" of 5 at compile time and 4 at run time. Rufe ich die SP von zwei DB manuell auf (jeweils Rückgabe True oder False), bekomme ich das Ergebnis ohne Fehler (was zu erwarten war), mache ich das in einer Schleife, wird der Fehler geworfen sobald die erste DB den Wert True zurückgibt.
Habt Ihr mir ein Tipp wie ich das anpassen kann, insbesondere wie ich die Spalte "fassen" kann da hier kein Name zurückgegeben wird?
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 671864
Url: https://administrator.de/forum/mssql-problem-bei-ausfuehren-einer-sp-remote-671864.html
Ausgedruckt am: 12.03.2025 um 02:03 Uhr
9 Kommentare
Neuester Kommentar
Der Rückgabewert ist scheinbar ein VARCHAR(?). true hat 4 Zeichen, false hat 5. In der SP ist irgendwo vermutlich ein Format definiert, oder fehlt das komplett?
Eventuell steht da nur RETURN 'true' und RETURN 'false', da würde ich dann DECLARE @returnvalue VARCHAR(5) machen und SET @returnvalue = 'true' bzw. false und dann RETURN @returnvalue und das einfach mal probieren. Dann dürfte der Rückgabewert immer VARCHAR(5) sein.
Format fehlt leider komplett, es wird mit einem IF am Ende entschieden ob "Select 'True'" oder "Select 'False'" zurückgegeben wird, kein Spaltenname mit as ... / [ ], keine Variable die deklariert wurde.
Leider wird der Hersteller der Software hier nichts ändern da diese nicht nur von uns eingesetzt wird und die Software damit klar kommt.
Es ist halt nicht vorgesehen das wir für Reports die Daten abfragen
Leider wird der Hersteller der Software hier nichts ändern da diese nicht nur von uns eingesetzt wird und die Software damit klar kommt.
Es ist halt nicht vorgesehen das wir für Reports die Daten abfragen
Zitat von @ukulele-7:
Eventuell steht da nur RETURN 'true' und RETURN 'false', da würde ich dann DECLARE @returnvalue VARCHAR(5) machen und SET @returnvalue = 'true' bzw. false und dann RETURN @returnvalue und das einfach mal probieren. Dann dürfte der Rückgabewert immer VARCHAR(5) sein.
Eventuell steht da nur RETURN 'true' und RETURN 'false', da würde ich dann DECLARE @returnvalue VARCHAR(5) machen und SET @returnvalue = 'true' bzw. false und dann RETURN @returnvalue und das einfach mal probieren. Dann dürfte der Rückgabewert immer VARCHAR(5) sein.
So würde ich das ebenfalls machen, nur können wir die SP nicht selber anpassen die in verschiedener Form in über 100.000 Datenbanken vorkommt, leider...
Dann mache in deiner Abfrage, die die SP aufruft, ein SELECT convert(VARCHAR(5),DBName.Schema.SPName) oder etwas in der Art.
Moin,
Ich hab noch nie verstanden, warum manche Entwickler sich nicht ordentlich ans Deklarieren von Variablen halten und diese dann auch korrekt auswerten...
Kannst du den SP nachbauen?
Wenn ja, würde ich deinen SP abfragen und die Werte direkt als Bit deklarieren:
Ergebnis
Ich hab noch nie verstanden, warum manche Entwickler sich nicht ordentlich ans Deklarieren von Variablen halten und diese dann auch korrekt auswerten...
Kannst du den SP nachbauen?
Wenn ja, würde ich deinen SP abfragen und die Werte direkt als Bit deklarieren:
declare @val1 as bit, @val2 as bit
Select @val1 = 'true', @val2 = 'false'
Select
column1 = @val1
, column2 = @val2
, column3 = CONVERT(bit, 'true')
, column4 = CONVERT(bit, 'false') Ergebnis
column1 column2 column3 column4
1 0 1 0
Technisch wären Bits natürlich optimal, falls das aber eh eine Ausgabe wird will man vermutlich eher mit true / false arbeiten, weil es sich optisch besser unterscheidet. Grundsätzlich ist das aber ziemlich unsauber umgesetzt. Auch wenn es einen Text ausgibt sollte man das sauber deklarieren. Das wäre durchaus etwas, was der Hersteller mal verbessern könnte...
Das Problem entsteht immer dann, wenn der erste Wert einer Spalte ein true ist. Dann setzt MSSQL implizit den Spaltentyp, der entspricht dann einem VARCHAR(4). Wenn dann irgendwo "später" ein false dazu kommt knallt es. Wenn also das Ergebnis der SP in irgendeiner Weise zu einer Tabelle zusammen gesetzt wird muss halt dafür Sorge getragen werden, das der Spaltentyp mindestens 5 Zeichen aufnehmen kann. Eventuell ist es sogar nur ein CHAR(), dann tritt das Problem immer auf egal welcher Wert als erstes kommt.
Das Problem entsteht immer dann, wenn der erste Wert einer Spalte ein true ist. Dann setzt MSSQL implizit den Spaltentyp, der entspricht dann einem VARCHAR(4). Wenn dann irgendwo "später" ein false dazu kommt knallt es. Wenn also das Ergebnis der SP in irgendeiner Weise zu einer Tabelle zusammen gesetzt wird muss halt dafür Sorge getragen werden, das der Spaltentyp mindestens 5 Zeichen aufnehmen kann. Eventuell ist es sogar nur ein CHAR(), dann tritt das Problem immer auf egal welcher Wert als erstes kommt.
probier mal die Prozedur mit OPTION RECOMPILE auszuführen. Der Query Analyzer hat da ggf. noch einen "alten" Plan
https://www.mssqltips.com/sqlservertip/8154/sql-server-option-recompile- ...
https://www.mssqltips.com/sqlservertip/8154/sql-server-option-recompile- ...
Hallo Daniel,
Du kannst der Prozedur mitgeben, was für ein Ergebnis zurückkommt:
Gruß, Mad Max
Du kannst der Prozedur mitgeben, was für ein Ergebnis zurückkommt:
exec Meine_Prozedur with result sets ((Spalte1 varchar (5)))Gruß, Mad Max
