So che questa non è una domanda inutile, ma non posso fare a meno di esserne infastidita.Perché il "Non" in "ExecuteNonQuery"?
Quindi,
Perché detto metodo (in *Command classi) si chiama
ExecuteNonQuery invece di ExecuteQuery?
Non sono quelle istruzioni SQL che lanciamo ai DB, query?
Semanticamente, una query è qualcosa che si esegue per restituire i dati. Stai "interrogando" il database per trovare tutte le X nella Y.
Se non ti aspetti i risultati, non è tanto una query quanto una dichiarazione o comando.
Non se ne sono inserti, cancella, creare tabelle, ecc
Ma un metodo che ** può ** eseguire una query (ad esempio, SELECT) non deve essere chiamato ExecuteNonQuery. Questo è quello che mi dà fastidio. –
It * can * esegue un 'SELECT', ma non ha senso usare' ExecuteNonQuery' con un 'SELECT', perché in realtà non restituisce un risultato. –
@Camilo le classi DB non sanno se è necessaria una risposta che dica esplicitamente all'oggetto DB che non ci si aspetta nulla che renda spazio alle ottimizzazioni. Tu come dev potrebbe non volere qualcosa restituito da un'istruzione select (selezionare * in ... per uno) –
Vorrei pensarlo come una query sta chiedendo il database per i record. Le azioni che alterano i dati/database non sarebbero una query.
Ma può essere un SELECT. Quindi, perché non solo "myCommand.Execute()"? –
@Camilo: poiché esiste ExecuteReader() che restituisce i risultati della query o anche ExecuteScalar(), per risultati a valore singolo. –
Grazie, non sapevo di ExecuteScalar :) –