Fehlermeldung: Object reference not set to an instance of an object

[j.schoenbrunner]

Liebe C# Forum Mitglieder!
Ich kann eine Execption Message von einem Systemmodul, wo kein Sourcecode verfügbar ist nicht nachvollziehen:
Es handelt sich um einen Aufruf eines Objekts von SqlCommand
im Namespace System.Data.SqlClient
Beim Aufruf der Methode (SqlCommand cmd).ExecuteScalar ()
gibt die abgefangene Exception e in e.Message die folgende Meldung aus:

Object reference not set to an instance of an object

Der Command Text ist eine sql-insert anweisung für 3 Parameter für Tabellenspalten.
Im Debugger habe ich die Richtigkeit Werte der Parameter-Felder @-Name, SqlDbTyp u. Value gesehen.
Aufgefallen ist mir nur daß die Property SourceColumn mit "" belegt ist.

Die sql-anweisung war
CommandText = "insert into ag_se(ags_ag_id, ags_se_id, ags_name)values(@ags_ag_id, @ags_se_id, '@ags_name')"

Meine Frage:
Was kann ich tun um in die Fehlerursache Einsicht zu bekommen.
Genauer: welche Object reference nicht gesetzt ist
(und für welche instanz von welchem Objekt).

Für Hinweise dankbar
Josef Schönbrunner

[robert.oh.]

Hallo,

Fuer einen Insert bietet sich die 'ExecuteNonQuery()' Methode an; 'ExecuteScalar()' gibt dir die erste Spalte der ersten Zeile des Ergebnis Cursors zurueck und da Insert nichts derartiges retour gibt, koennte die Meldung daraus resultieren.

[Jürgen Thomas]

Benutze nicht e.Message, sondern e.ToString(); das liefert bei Exceptions mehr Informationen. Zusätzlich können die anderen Eigenschaften von Exception (siehe SDK-Doku) helfen.

Die Hochkommata beim letzten Parameter sollten entfernt werden; das wird durch die DbParameter automatisch gesteuert.

Kannst Du feststellen, warum für einen Insert-Befehl ExecuteScalar verwendet wird (Standard wäre ExecuteNonQuery)?

Den Code, den Du beeinflussen kannst und an dem der Fehler auftritt, könntest Du kopieren (auch wenn es wahrscheinlich nicht mehr viel hilft). Jürgen

[Ralf Jansen]

Hast du vielleicht vergessen die SQLConnection zu setzen?

Bei ein paar Aufrufen knallt SQLCommand einfach wenn keine Connection gesetzt ist. MS hat leider an ein paar Stellen vergessen auf die Existenz der Connection zu testen und ein sprechendere Exception zu werfen.

Ansonsten, wenn es das nicht ist, kannst du immer noch den Stack der bei der Exception mitgeliefert wird auswerten und dir die passende Stelle in der System.Data Assembly per Reflector anschauen.

[j.schoenbrunner]

Hallo,

Fuer einen Insert bietet sich die 'ExecuteNonQuery()' Methode an; 'ExecuteScalar()' gibt dir die erste Spalte der ersten Zeile des Ergebnis Cursors zurueck und da Insert nichts derartiges retour gibt, koennte die Meldung daraus resultieren.

Danke robert.oh
Ein vorangehendes mit ExecuteSalar mit leerer Parameterliste hat aber so fuktioniert und die identity zurückgegeben

[j.schoenbrunner]

An alle die geantwortet haben

Herzlichen Dank allen!
Hat mir alles perfekt zur Lösung verholfen.
im einzelnen habe ich befolgt (+) nicht (-) :

+ Hochkommata im letzten parameter entfernt - Jürgens Vorschlag
- 'ExecuteNonQuery()' statt 'ExecuteScalar()' - naja es geht schon mit letzteren, aber man muß das Command mit irgendeinen Select abschließen,
ich habe einfach "select 0" rechts angehängt.
Warum ich mich auf das kapriziere ist dass ich es in einer Methode verwende,
wo ein Rückgabewert (Status oder eine Identity) gebraucht wird.

Danke Jürgen auch wegen des Hinweises zur Verbesserung der Fehlerdiagnosen

[robert.oh.]

Hallo,

Wenn du schon einen Rueckgabewert nach dem INSERT brauchst koenntest du anstelle des 'SELECT 0' einen 'SELECT @@IDENTITY' ausfuehren, welcher dir die ID des eingefuegten Datensatzes liefert (bei INT Primary Keys).

[b.IT]

Hallo,

Wenn du schon einen Rueckgabewert nach dem INSERT brauchst koenntest du anstelle des 'SELECT 0' einen 'SELECT @@IDENTITY' ausfuehren, welcher dir die ID des eingefuegten Datensatzes liefert (bei INT Primary Keys).

Vorsicht! @@IDENTITY liefert nicht zwingend die vom Insert erzeugte Identity zurück sondern die letzte auf dem SQL-Server erzeugte. Und das muß auf Systemen mit parallelen Zugriffen nicht zwingend übereinstimmen. Der sichere Weg (ab sql2005) ist:

/*Create Table foo( foo_id int not null identity(1,1), bar char(3), baz char(3))*/

insert into foo  (bar, baz) output inserted.foo_id values ('bar', 'baz')

Auf diesem Weg lassen sich auch mehrere Felder zurückgeben - auf diese Art ist eine sehr elegante Kontrolle der eingefügten Daten möglich. Das gleiche funktioniert übrigens auch mit

delete from foo output deleted.* where baz='baz'