Prozedur Defekt, nach Neuerstellung wieder Intakt
lima-city → Forum → Programmiersprachen → Sonstige Programmiersprachen
adresse
aufruf
auftritt
befehl
code
datenbank
ergebnis
fehler
liegen
manager
mitarbeiter
ort
problem
programm
prozedur
server
set
string
treten
url
-
Hallo Community,
ich habe eine Prozedur geschrieben, welche bestimmte Adressen aus einer Datenbank (MS-SQL Server 2005) selektiert.
Diese Prozedur rufe ich über eine C# Oberfläche auf und gebe dort die Ergebnisse zurück.
Des öfteren ist es nun schon passiert, das folgende Fehlermeldung eintritt:
Fehler bei der Konvertierung des varchar Wertes "381.." in den Int-Datentyp
Warum dieser Fehler auftritt, was die Ursache dafür ist, weiß ich nicht.
Ich weiß allerdings wie ich ihn beheben kann. Ich erstelle die Prozedur neu. Ohne Änderungen an der Prozedur
Einfach im Datenbank-Manager Copy and Paste.
Oder: ich überschreibe die Prozedur mit dem Alter Procedure Befehl.
Das sieht dann so aus:
set ANSI_NULLS ON set QUOTED_IDENTIFIER ON go ALTER PROCEDURE [dbo].[Adressen_Selektieren_Geodaten1] @Adresse1 varchar(50) AS SET NOCOUNT ON; /* Hier steht der Prozedur-Inhalt. Da dieser allerdings knapp 300 Zeilen lang ist, blende ich ihn hier aus. */
Nochmal möchte ich betonen das der Prozeduren Inhalt völlig gleich bleibt
Wie kann es sein, das die Prozedur wieder funktioniert, nachdem ich sie neu erstellt habe?
Wird die Prozedur von irgendwem blockiert? Zugriff verweigert?
Nachdem ich sie neu erstelle, ist sie ja eine komplett neue prozedur und somit nicht mehr geblockt.
Aber warum dann ein Konvertierungsfehler?
Kann es sein das die Prozedur im laufe der Nutzung verändert wird?
Nachdem ich sie neu erstelle, sollten die Änderungen weg sein
Aber warum dann ein Konvertierungsfehler?
Und warum sollte sich eine Gespeicherte Prozedur durch aufruf verändern?
Kann es am
set ANSI_NULLS ON
set QUOTED_IDENTIFIER ON
liegen?
Diese Befehle stehen nicht in der Prozedur, sondern werden automatisch beim Klick auf "Alter-Prozedur" eingefügt
Aber warum dann ein Konvertierungsfehler?
Was haben diese 2 Befehle überhaupt zu bedeuten? Im mehr als 800 Seiten starken MS SQL Buch ist darüber nichts zu finden. Der Index verweist jediglich auf eine Seite, in der diese 2 Befehle nur als Beispiel eines Befehls auftauchen
Ich bin absolut ratlos
Beitrag zuletzt geändert: 6.4.2011 16:18:11 von marius71 -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
Hallo marius71,
warum Deine Prozedur manchmal den Geist aufgibt kann ich Dir leider auch nicht sagen.
Diese Fehlermeldung bekommt man normalerweise, wenn man in der Prozedur einen Wert zurückgeben will, der sich nicht in einen Integer konvertieren lässt. Von daher würde ich zuerst mal nachschauen, was bzw. welches Feld die Prozedur zurückgibt und ob das evtl. ein Wert sein kann, der sich nicht in eine Ganzzahl konvertieren lässt.
Die Option 'set ANSI_NULLS ON' bewirkt, dass Vergleiche mit dem Wert 'NULL' gemäß dem ISO-Standard durchgeführt werden.
Die Option 'set QUOTED_IDENTIFIER ON' bewirkt, dass Anführungszeichen gemäß dem ISO-Standard interpretiert werden.
Mehr zu den Optionen kannst Du hier und hier nachlesen. -
darkpandemic schrieb:
Diese Fehlermeldung bekommt man normalerweise, wenn man in der Prozedur einen Wert zurückgeben will, der sich nicht in einen Integer konvertieren lässt. Von daher würde ich zuerst mal nachschauen, was bzw. welches Feld die Prozedur
Habe ich bereits überprüft, ich gebe keine Int-Datentypen zurück und lasse auch keine ausgeben.
Nur sehr wunderlich ist, das die Prozedur wieder funktioniert, nachdem man sie einfach neu erstellt. Beim ersten mal dachte ich noch es wäre Zufall. Aber nachdem ich es nun schon öfters und sogar mit Publikum getestet habe, bin ich echt verwundert.
an QUOTED_IDENTIFIER ON und ANSI_NULLS ON scheint es wohl auch nicht zu liegen. Beim nächsten Fehler werde ich versuchen anstatt dem Neueinfügen der Prozedur einfach diese beiden Befehle auszuführen, um auf Nummer sicher zu gehen.
Aber es bleibt mir immer noch ein Rätsel, warum die Prozedur beim Neuerstellen wieder geht =( Völlig egal, welche Fehlermeldung er ausgibt. Mir fällt kein Grund ein warum es nach Neuerstellung wieder funktioniert -
Das erinnert mich an Konvertierungsfehler bei Pascal und Delphi. Char entspricht dort einem Byte ( 0 .. 255 ) und integer geht von -32768 bis + 32767. So gesehen würde zwar das Char im integer aufgehen, umgekehrt aber nicht, denn der obere Teile des integer würde abgeschnitten. Inwieweit Dir das jetzt weiterhilft, weiß ich nicht, aber ich würde sehen, ob möglich ist, statt des integers einen Bytewert einzusetzen. Von c# habe ich keine Ahnung.
Allerdings kommt mir gerade noch etwas in den Sinn. Beim Umstieg von Delphi 1 auf 32-Bit-Versionen kam es immer wieder zu unerklärlich scheinenden Fehlern beim Zugriff auf Dateien, die feste Datenstrukturen hatten. Ursache : Statt Bytewerten wurden immer Words geschrieben/gelesen. Integer und Words haben ja jeweils 2 Bytes. Bei Delphi ist es möglich, die Voreinstellung auf Word-Ausrichtung durch die Anweisung "absolute" zu umgehen, also "byte absolute".
Wie sowas dann bei c# aussehen muß, weiß ich nicht.
P.S. : Ich habe gerade oben nochmal nachgelesen. "varchar(50)" entspricht wohl einem String. Auf welche Weise wird der String gespeichert ? Mit vorangestelltem Längenbyte oder durch #0 abgeschlossen ? Vielleicht kommt es dabei zu einem Problem ?
Beitrag zuletzt geändert: 7.4.2011 9:15:45 von rorambur -
rorambur schrieb:
P.S. : Ich habe gerade oben nochmal nachgelesen. "varchar(50)" entspricht wohl einem String. Auf welche Weise wird der String gespeichert ? Mit vorangestelltem Längenbyte oder durch #0 abgeschlossen ? Vielleicht kommt es dabei zu einem Problem ?
ein varchar(50) string ist genau 50 Zeichen lang. Die Zahl in der Klammer, gibt die Länge an
das hier sind alle variablen die ich in der Prozedur verwende:
DECLARE @erdradius int;set @erdradius = 6371; DECLARE @starten int; SET @starten=0; DECLARE @lat1 decimal(18,5)/*Latitude der 1.Adresse*/ DECLARE @lon1 decimal(18,5)/*Longitude der 1.Adresse*/ DECLARE @str1 varchar(50);/*Straßenname der 1.Adresse*/ DECLARE @o1 varchar(50);/*Ort der 1.Adresse*/ DECLARE @lat2 decimal(18,5)/*Latitude der 2.Adresse*/ DECLARE @lon2 decimal(18,5)/*Longitude der 2.Adresse*/ DECLARE @str2 varchar(50);/*Straßenname der 2.Adresse*/ DECLARE @o2 varchar(50);/*Ort der 1.Adresse*/ DECLARE @kurzbez varchar(50); DECLARE @knr int; DECLARE @name1 varchar(255); DECLARE @name2 varchar(255); DECLARE @ergebnis varchar(50);/*Straßenname des Ergebnis*/ DECLARE @plz char(6); DECLARE @ort varchar(255); DECLARE @telefon1 varchar(255); DECLARE @geos varchar(40); DECLARE @status varchar(255); DECLARE @LetzteHistDatum datetime; DECLARE @HistorieBemerkung varchar(3000); DECLARE @ORTSTEIL varchar(40); DECLARE @Mitarbeiter varchar(255); DECLARE @Termin smalldatetime; DECLARE @ergebnislat decimal(18,5);/*Latitude des Ergebnis*/ DECLARE @ergebnislong decimal(18,5);/*Longitude des Ergebnis*/
trotzdem bleibt es mir schleierhaft warum der Fehler nach Neuerstellung der Prozedur nicht mehr auftritt
Dieser Fehler tritt außerdem auf, wenn ich die Prozedur in Excel starte. Es liegt also nicht umbedingt an C# -
Na gut, gehen wir also davon aus, daß Du einen Datenblock fester Größe hast. Wenn nun ein Programm auf diesen Datenblock zugreift und Teile davon mit falscher Länge interpretiert ( wie von mir erwähnt ) muß es zu solchem Fehler kommen.
trotzdem bleibt es mir schleierhaft warum der Fehler nach Neuerstellung der Prozedur nicht mehr auftritt
Dieser Fehler tritt außerdem auf, wenn ich die Prozedur in Excel starte. Es liegt also nicht umbedingt an C#
Was heißt das denn genau ? Tritt der Fehler jedesmal auf, wenn Du mit Excel drauf zugreifst oder kam er nur ein mal vor ?
Wenn er nach Neuerstellung ( vom C#-Programm aus ) nicht vorhanden ist, dann aber nach Zugriff über Excel ist es eindeutig eine Fehlinterpretation von Variablenlängen durch Excel. Das müßte dann aber durch entsprechende Compileranweisung(en) bei C# kompensierbar sein.
Oder habe ich irgendwas falsch verstanden ? Ich benutze kein c# und kein excel, aber das Problem selbst kommt mir bekannt vor. Sonst hätte ich mich nicht dazu geäußert. -
Das Problem tritt, wenn einmal aufgetreten, danach außnahmslos bei jedem Prozeduraufruf wieder ein.
Ob ich die Prozedur von Excel oder C# aufrufe ist dabei völlig egal.
Wenn ich nun im DB Manager die Prozedur neu erstelle (Prozedur kopieren, löschen, neu einfügen), funktioniert der Aufruf in Excel sowie in C# wieder. -
Also nochmal :
Nachdem Du die Prozedur erstellt hast, ist sie nach jedem Aufruf wieder weg ?
Oder meinst Du die Daten ?
Was ist der "DB Manager" ? -
Okay, also nochmal ganz genau:
Die Prozedur wird vom einem externen Programm, wie zb. C# oder Excel aufgerufen. Der Prozedur werden verschiedene Parameter übergeben (Die Adressdaten verschiedener Kunden)
Die Prozedur gibt als Ergebnis eine Tabelle zurück, in der alle in der Datenbank gespeicherten Kunden mit einem Umkreis von X km von der übergebenen Adresse liegen.
So sieht die Rückgabe Tabelle aus:
DECLARE @MyTableVar TABLE ( Kurzbezeichnung varchar(50), Kundenummer varchar(50), Nachname varchar(255), Vorname varchar(255), Strasse varchar(50), PLZ char(6), Ort varchar(255), Telefon varchar(50), Geodaten varchar(40), Status varchar(255), LetzteHistDatum datetime, HistorieBemerkung varchar(3000), Ortsteil varchar(40), Mitarbeiter varchar(255), Termin smalldatetime, Latitude decimal(18,5), Longitude decimal(18,5), Entfernung_zu_Adresse_1 decimal(7,2), Entfernung_zu_Adresse_2 decimal(7,2), Gesamtabstand decimal(7,2) );
Verschiedene Mitarbeiter nutzen diese Prozedur täglich. Sie rufen sie mit einem C# Programm oder Excel auf.
Normalerweise läuft alles stabil. manchmal sogar Monate lang.
Doch irgendwann, tritt der besagte Fehler ein.
Ab diesem Zeitpunkt, tritt der Fehler jedes mal wieder ein. Außnahmslos.
Jetzt öffne ich den Datenbanken Manager (SQL Server Management Studio Express)
Hier werden alle Tabellen, Sichten, Prozeduren etc. unseres Datenbank servers angezeigt.
Unter dem Punkt Prozeduren sind alle gespeicherten Prozeduren aufgelistet.
Diese kann ich mit einem rechtsklick kopieren einfügen löschen etc.
Wenn ich diese nun
kopiere
dann lösche
und dann wieder einfüge
funktioniert der Prozeduraufruf mit C# Excel etc. wieder. d.h. ab nun können die Mitarbeiter wieder arbeiten, bis der Fehler in ein paar Wochen wahrscheinlich wieder eintritt
Beitrag zuletzt geändert: 7.4.2011 11:01:06 von marius71 -
Oh !
Das verkompliziert die Sache ganz erheblich. Allerdings kommt mir dabei ein bestimmter Verdacht, nämlich der, daß dieser Fehler reproduzierbar ist und immer dann auftritt, wenn ein Datentyp eingegeben wurde, der nicht ins - na sagen mir mal "Fangraster" paßt.
Wenn ich also z.B. in ein Feld, das eine Ganzzahl erwartet, einen Gleitkommawert eingebe oder statt eines Bytewertes ( bis 255 ) eine höhere Zahl, dann produziere ich dadurch unwissentlich Müll.
Mein Tipp : Teste mal ganz gezielt alle Eingabefelder mit Datenwerten, die außerhalb der zulässigen Bereichsgrenzen liegen. Falls danach der Fehler sofort auftritt, mußt Du entweder die Bereichsgrenzen erhöhen ( was bei bestehenden hohen Datenmengen eine aufwändige Umkonvertierung erfordern könnte ) oder Du mußt Fehleingaben durch Bereichsüberprüfungen vor der Übernahme der Daten in die Datenbank abfangen.
Teste das mal und berichte dann, ob es daran lag. Mehr wüßte ich im Moment auch nicht. Ich bin aber jetzt erstmal für einige Stunden weg und sehe erst am späten Nachmittag wieder rein. Viel Glück !
-
rorambur schrieb:
Mein Tipp : Teste mal ganz gezielt alle Eingabefelder mit Datenwerten, die außerhalb der zulässigen Bereichsgrenzen liegen. Falls danach der Fehler sofort auftritt, mußt Du entweder die Bereichsgrenzen erhöhen ( was bei bestehenden hohen Datenmengen eine aufwändige Umkonvertierung erfordern könnte ) oder Du mußt Fehleingaben durch Bereichsüberprüfungen vor der Übernahme der Daten in die Datenbank abfangen.
Das habe ich bereits getan. Schon lange bevor ich das Programm freigegeben habe. Sämtliche Fehleingaben werden abgefangen, da die Mitarbeiter sonst sowiso zu 100% irgendwann Müll eintippen würden.
Sämtliche Fehlerhaft Übergabeparameter werden alle abgefangen.
Außerdem speichert das Programm jeden Übergabeparameter, sodass ich einen "Problemaufruf" immer wieder testen kann.
Soll heißen:
Aufruf mit "Max" "Mustermann" funktioniert plötzlich nicht.
Prozedur wird neu erstellt
Aufruf mit "Max" "Mustermann" funktioniert plötzlich wieder.
Da ich an den Parametern nicht geändert habe, kann es daran ja nicht liegen =(
Ganz schön komplizierte Sache die da vorgeht, aber es freut mich das sich jemand dafür interessiert und mir hilft
-
Tja, dann bin ich aber leider mit meiner Weisheit auch am Ende. Wie schon erwähnt basiert meine Erfahrung auf Pascal und Delphi, was aber was die Problemstellung als solche betrifft ähnliche Rückschlüsse zuläßt.
Schade, daß ich Dir nicht helfen konnte, denn mehr fällt mir dazu jetzt auch nicht mehr ein. Trotzdem viel Glück. Ich wünsche Dir, daß Du die Ursache rausbekommst.
Ich hatte Deine Antwort noch abgewartet, weil ich mir im Nachhinein fast schon dachte, daß Du das schon alles getestet hattest. Aber jetzt muß ich noch einige erledigen und schalte darum ab.
So, zwischendurch fand ich doch noch mal kurz etwas Zeit.
set ANSI_NULLS ON siehe z.B. : http://msdn.microsoft.com/de-de/library/ms188048.aspx
set QUOTED_IDENTIFIER ON : Da kommen diverse Quellen in Betracht :
https://encrypted.google.com/search?hl=de&lr=lang_de&client=firefox-a&hs=pgn&rls=org.mozilla%3Ade%3Aofficial&tbs=lr%3Alang_1de&q=%22set+QUOTED_IDENTIFIER+ON%22&btnG=Suche&aq=f&aqi=&aql=&oq=
Der zweite Suchlink ist für Firefox., ggf. muß er angepaßt werden. Entscheidend ist, den Suchbegriff komplett in Anführungsstricke zu setzen, also so : "set QUOTED_IDENTIFIER ON"
Beitrag zuletzt geändert: 7.4.2011 12:55:54 von rorambur -
Ich werde demnächst meinen Chef fragen, ob Pozeduren bei bestimmten Fehlern evtl gesperrt werden.
Das halte ich für die einzige noch Mögliche Lösung.
--> Fehler tritt ein, Prozedur wird vom Server gesperrt.
--> Prozedur wird neu erstellt -> der Server weiß nicht das es die gleiche ist und somit ist keine Sperre vorhanden
Wenn ich etwas herausfinde, werde ich es posten
danke
-
Was Du schreibst, klingt plausibel. Würde mich dann auch interessieren.
-
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
