Sé que esta no es una pregunta muy útil, pero no puedo evitar que me molesten.¿Por qué el "No" en "ExecuteNonQuery"?
Así,
Por qué dicho método (en *Command clases) se llama
ExecuteNonQuery en lugar de ExecuteQuery?
¿No son esas declaraciones de SQL las que lanzamos en DBs, consultas?
Semánticamente, una consulta es algo que se ejecuta para devolver datos. Está 'consultando' la base de datos para encontrar toda la X en Y.
Si no espera resultados, no es tanto una consulta como una instrucción o comando.
No, si son inserciones, borrados, crear tablas, etc.
Pero un método que ** puede ** ejecutar una consulta (es decir, SELECCIONAR) no se debe llamar ExecuteNonQuery. Eso es lo que me molesta. –
* Puede * ejecutar un 'SELECT', pero no tiene sentido usar 'ExecuteNonQuery' con un' SELECT', porque en realidad no devuelve un resultado. –
@Camilo las clases de base de datos no saben si necesita una respuesta que explique explícitamente al objeto de base de datos que no espera que nada atrás genere espacio para optimizaciones. Es posible que usted, como desarrollador, no desee que se devuelva nada con una declaración seleccionada (seleccione * en ... para uno) –
Lo pensaría como una consulta le está pidiendo a la base de datos que registre. Las acciones que alteran los datos/bases de datos no serían una consulta.
Pero puede ser un SELECCIONADO. Entonces, ¿por qué no simplemente "myCommand.Execute()"? –
@Camilo: Porque hay ExecuteReader() que devolverá los resultados de su consulta, o incluso ExecuteScalar(), para resultados de un solo valor. –
Gracias, no sabía de ExecuteScalar :) –