[c#]@@IDENTITY direct na insert geeft een open datareader?

[TeeDee]

Goedemorgen,

Zit nu al een poosje met een raar probleempje.
Ik wil namelijk na de insert de Identity ophalen.
Niet zo problematisch lijkt mij toch?

Volgens [rml][ C#] Laatste insert id uit MSSQL DB halen[/rml] moet het ook niet zo moeilijk zijn.

C#:

string sSQL = "INSERT INTO koerier (Opdrachtgever) VALUES (@p_Opdrachtgever)";
SqlCommand insertdata = new SqlCommand(sSQL, conn);
conn.Open();

insertdata.Parameters.Add("@p_Opdrachtgever", SqlDbType.VarChar);
insertdata.Parameters["@p_Opdrachtgever"].Value = txtOpdrachtgever.Text;
...
insertdata.ExecuteReader();
insertdata.Dispose();

SqlCommand cmdIdent = new SqlCommand("select @@IDENTITY as lastId from dbo.koerier", conn);
int koerierID = Int32.Parse(cmdIdent.ExecuteScalar().ToString());
...

_{het enige wat tussen deze code nog staat zijn nog wat parameters e.d.}
Deze code blijft aangeven dat er nog een Open DataReader aan de connectie hangt (jaja, geen engelse foutmelding )

• Het is niet mogelijk om een SCOPE_IDENTITY uit te voeren (sql 7 denk ik)
• Dit is zowat de enige code op de pagina.

Ik zie iets simpels over het hoofd imho, maar wat weet ik niet.

[whoami]

Heb je ergens datzelfde connection object gebruikt bij een SqlCommand dat een DataReader returned, en heb je in dat stuk code die reader en de connectie niet gesloten?

[TeeDee]

whoami schreef op 14 oktober 2004 @ 09:43:
Heb je ergens datzelfde connection object gebruikt bij een SqlCommand dat een DataReader returned, en heb je in dat stuk code die reader en de connectie niet gesloten?

Nee.
Dit is praktisch de enige code in het projectje.

[ Voor 20% gewijzigd door TeeDee op 14-10-2004 09:46 ]

[whoami]

Wat is die code dan op lijn 8 ?
Dat moet ExecuteNonQuery zijn, en niet ExecuteReader.

[TeeDee]

Zie je wel. Het was iets simpels.

edit:
Copy-pasten van oude code is niet handig

[ Voor 49% gewijzigd door TeeDee op 14-10-2004 09:51 ]

[gorgi_19]

En hoor je je connectie ook niet te sluiten? En kan je niet meerdere SQL Statements achter elkaar zetten met ;, zodat je eik maar 1 keer de database hoeft te benaderen ipv 2 keer?

[ Voor 61% gewijzigd door gorgi_19 op 14-10-2004 10:39 ]

[H!GHGuY]

plak die insert en die select aan elkaar, en dan kun je in 1 query zowel insert doen en onmiddellijk de identity ophalen

en dit valt me ook op:

code:

int koerierID = Int32.Parse(cmdIdent.ExecuteScalar().ToString());

is het niet makkelijker om dit simpelweg te doen?

code:

int koerierID = (int)cmdIdent.ExecuteScalar();

velden die in de DB zitten kun je toch rechtstreeks casten naar hun C# equivalent?

toch hetzelfde wanneer je met een reader data ophaalt

code:

int a = (int)rdr["getal"]

en is het niet 'standaard' om Convert.ToInt32() te gebruiken ipv Int32.Parse()...

[whoami]

Ik denk dat deze code

code:

(int)cmdIdent.ExecuteScalar();

ervoor zal zorgen dat je object geboxed (of is het nu ge-unboxed) wordt, terwijl, als je gebruik maakt van Convert.ToInt32 dat waarschijnlijk niet het geval is. (Althans, als je dit eens bekijkt dmv ildasm zie je geen box/unbox statements staan bij het 2de geval).

[gorgi_19]

Afaik roept Convert.ToInt32 intern In32.Parse aan
Zie ook gorgi_19 in "C# string to int probleempje"

quote: http://www.asp.net/Forums...x?tabindex=1&PostID=36354

Int32.Parse is quicker and requires one less stack frame.

Internally Convert.ToInt32 actually calls Int32.Parse.

Hoewel, als je je druk moet maken om 1 stack frame..

[ Voor 77% gewijzigd door gorgi_19 op 14-10-2004 11:02 ]

[TeeDee]

gorgi_19 schreef op 14 oktober 2004 @ 10:38:
En hoor je je connectie ook niet te sluiten? En kan je niet meerdere SQL Statements achter elkaar zetten met ;, zodat je eik maar 1 keer de database hoeft te benaderen ipv 2 keer?

Connectie wordt later gesloten inderdaad.
Meerdere Statements met ; wist ik niet. Eens naar kijken.

HIGHGuY schreef op 14 oktober 2004 @ 10:59:
en dit valt me ook op:

code:

int koerierID = Int32.Parse(cmdIdent.ExecuteScalar().ToString());

is het niet makkelijker om dit simpelweg te doen?

code:

int koerierID = (int)cmdIdent.ExecuteScalar();

velden die in de DB zitten kun je toch rechtstreeks casten naar hun C# equivalent?
toch hetzelfde wanneer je met een reader data ophaalt

code:

int a = (int)rdr["getal"]

en is het niet 'standaard' om Convert.ToInt32() te gebruiken ipv Int32.Parse()...

Zou kunnen, doe eigenlijk altijd een Int32.Parse(...). Waarom weet ik niet. Gewenning denk ik.

offtopic:
@gorgi_19, heb ik een keer een .net vraag, is het simpel op te lossen

[ Voor 7% gewijzigd door TeeDee op 14-10-2004 11:05 ]

[whoami]

TeeDee schreef op 14 oktober 2004 @ 11:05:
[...]

Connectie wordt later gesloten inderdaad.

Zorg ervoor dat je je connectie in een finally block sluit.

[TeeDee]

whoami schreef op 14 oktober 2004 @ 11:06:
[...]
Zorg ervoor dat je je connectie in een finally block sluit.

En dat heeft als reden?

[gorgi_19]

whoami schreef op 14 oktober 2004 @ 11:06:
[...]

Zorg ervoor dat je je connectie in een finally block sluit.

Waarom? Is het te verwachten dat hij in productie-omgeving gaat crashen? Gebeurd dat wel, dan loopt toch je hele applicatie vast, wordt een exception gegooid en kan je niet verder. Die open connectie is dan pech hebben, maar die voert toch weinig meer uit.

Normaliter zal je dan een nieuwe versie moeten maken; door het wijzigen van de /bin of web.config zal je application opnieuw geladen worden (en alle zut in het geheugen opgeruimd)

[ Voor 7% gewijzigd door gorgi_19 op 14-10-2004 11:09 ]

[H!GHGuY]

whoami schreef op 14 oktober 2004 @ 11:01:
Ik denk dat deze code

code:

(int)cmdIdent.ExecuteScalar();

ervoor zal zorgen dat je object geboxed (of is het nu ge-unboxed) wordt, terwijl, als je gebruik maakt van Convert.ToInt32 dat waarschijnlijk niet het geval is. (Althans, als je dit eens bekijkt dmv ildasm zie je geen box/unbox statements staan bij het 2de geval).

box/unbox?? dit moet je me eens fijner uitleggen
zowel Convert/Parse nemen toch de waarde van het 'object' en returnen het...
een cast is toch gewoon het 'interpreteren' van die waarde (of is dit van c++ -> c# gewijzigd?) dus sneller????

mss is het handiger (als je veel van SQL gebruik gaat maken) om daar een aparte klasse voor te maken, en ook daar je verbinding en DataReader's bij te houden...
kun je wanneer nodig (en als je SQL-strings compatibel zijn) overschakelen op een ander DBase systeem

[ Voor 69% gewijzigd door H!GHGuY op 14-10-2004 11:19 ]

[whoami]

Je wil je connectie toch altijd sluiten, ook als er een exceptie optreedt. Op die manier kan die connectie terug gegeven worden naar de connection-pool.