consulta ADO

25/08/2007 - 00:02 por Jordi Maycas | Informe spam
Hola!! Estoy haciendo esto con vc#.net 2005, y no se si es la manera
adecuada. No meda errores de compilacion ni de linker pero... ¿hay alguna
manera mejor de hacerlo? Me refiero a que es mejor ADODB, o OLEDB, y a parte
teniendo en cuenta que probablemente migre de access 2003 a sql express.

ADODB.Connection cn=new ADODB.Connection();

ADODB.Recordset res=new ADODB.Recordset();

object objAffected;

string strStatement="Select * from prueba";

string cnStr;

string fichero = "c:\\prueba.mdb ";

try

{

cnStr = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" + fichero;

cn.Open(cnStr, null, null, 0);

cn.Execute(strStatement, out objAffected, 0);

}

finally

{

cn.Close();

}

Preguntas similare

Leer las respuestas

#6 Jordi Maycas
26/08/2007 - 14:39 | Informe spam
probare con un executescalar aunque creo que algo hacia mal, porque de
hecho ya lo probe, y me daba algun error... en breve te comento.

"Alberto Poblacion"
escribió en el mensaje news:%23q%
"Jordi Maycas" wrote in message
news:
probe,pero en total me da siempre 0, aunque hayan registros o no... y
luego en el myReader.HasRows, siempre es verdadero...



Lógico. Estás preguntando por el RecordsAffected, que para una consulta
de Selección siempre es cero (te da el número de registros modificados
cuando haces una consulta que contenga Insert, Update o Delete).
myReader.HasRows siempre es verdadero porque tu consulta es un Select
Count(*)..., que siempre devuelve una fila con una columna, por lo que el
resultado siempre contiene una fila (HasRows), aunque la columna de esa
fila traiga un cero.

Para obtener la cuenta de los registros tal como deseas, lo más
eficiente es usar un ExecuteScalar, pero si insistes en usar un
ExecuteReader, entonces tienes que hacerle un Read() para posicionarte en
la primera fila devuelta, y a continuación leer la primera columna de
dicha fila.



Respuesta Responder a este mensaje
#7 Jordi Maycas
26/08/2007 - 14:44 | Informe spam
tendria que adaptar el codigo del guille... teniendo en cuenta que en vez de
usar sqlconnection, sqlcommand usariamos los oledb, cierto?


// Usar el procedimiento almacenado sp_TotalFilasPrueba
// para saber el número de filas o registros de la tabla Prueba
// El comando SQL es:
// SELECT COUNT(*) FROM Prueba
SqlConnection cnn = null;
SqlCommand cmd = null;
//
try
{
// Usar la cadena de conexión almacenada en el fichero app.config
// En este caso es para acceder a un fichero .mdf
// en el que habrá que cambiar el "path"
// por el correcto de nuestro equipo.
// Data
Source=.\SQLEXPRESS;AttachDbFilename=...\pruebasGuille_SQL.mdf;Integrated
Security=True
cnn = new SqlConnection(Settings.Default.cs_pruebasGuille);
cmd = new SqlCommand("sp_TotalFilasPrueba", cnn);
cmd.CommandType = CommandType.StoredProcedure;

cnn.Open();

int n;
n = Convert.ToInt32(cmd.ExecuteScalar());

this.LabelTotalFilas.Text = "Número de filas: " + n;
LabelStatus.Text = "Número de filas: " + n;
}
catch (Exception ex)
{
this.LabelTotalFilas.Text = "Error: " + ex.Message;
LabelStatus.Text = "ERROR";
}
finally
{
if (cnn != null && cnn.State != ConnectionState.Closed)
{
cnn.Close();
}
}"Jordi Maycas" escribió en el mensaje
news:
probare con un executescalar aunque creo que algo hacia mal, porque de
hecho ya lo probe, y me daba algun error... en breve te comento.

"Alberto Poblacion"
escribió en el mensaje news:%23q%
"Jordi Maycas" wrote in message
news:
probe,pero en total me da siempre 0, aunque hayan registros o no... y
luego en el myReader.HasRows, siempre es verdadero...



Lógico. Estás preguntando por el RecordsAffected, que para una consulta
de Selección siempre es cero (te da el número de registros modificados
cuando haces una consulta que contenga Insert, Update o Delete).
myReader.HasRows siempre es verdadero porque tu consulta es un Select
Count(*)..., que siempre devuelve una fila con una columna, por lo que el
resultado siempre contiene una fila (HasRows), aunque la columna de esa
fila traiga un cero.

Para obtener la cuenta de los registros tal como deseas, lo más
eficiente es usar un ExecuteScalar, pero si insistes en usar un
ExecuteReader, entonces tienes que hacerle un Read() para posicionarte en
la primera fila devuelta, y a continuación leer la primera columna de
dicha fila.







Respuesta Responder a este mensaje
#8 Jordi Maycas
26/08/2007 - 14:53 | Informe spam
bueno.. solucionado.

el codigo por fin es:

string fichero = "..\\..\\bd1.mdb ";

string ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" +
fichero;

OleDbConnection cnn = null;

OleDbCommand cmd=null;

try

{

cnn=new OleDbConnection(ConnectionString);

cmd=new OleDbCommand("Select count(*) from mayoristas",cnn);

cnn.Open();

int n=Convert.ToInt32(cmd.ExecuteScalar());

}

finally

{

cnn.Close();

}

"Jordi Maycas" escribió en el mensaje
news:
probare con un executescalar aunque creo que algo hacia mal, porque de
hecho ya lo probe, y me daba algun error... en breve te comento.

"Alberto Poblacion"
escribió en el mensaje news:%23q%
"Jordi Maycas" wrote in message
news:
probe,pero en total me da siempre 0, aunque hayan registros o no... y
luego en el myReader.HasRows, siempre es verdadero...



Lógico. Estás preguntando por el RecordsAffected, que para una consulta
de Selección siempre es cero (te da el número de registros modificados
cuando haces una consulta que contenga Insert, Update o Delete).
myReader.HasRows siempre es verdadero porque tu consulta es un Select
Count(*)..., que siempre devuelve una fila con una columna, por lo que el
resultado siempre contiene una fila (HasRows), aunque la columna de esa
fila traiga un cero.

Para obtener la cuenta de los registros tal como deseas, lo más
eficiente es usar un ExecuteScalar, pero si insistes en usar un
ExecuteReader, entonces tienes que hacerle un Read() para posicionarte en
la primera fila devuelta, y a continuación leer la primera columna de
dicha fila.







Respuesta Responder a este mensaje
#9 Alberto Poblacion
26/08/2007 - 17:39 | Informe spam
"Jordi Maycas" wrote in message
news:
tendria que adaptar el codigo del guille... teniendo en cuenta que en vez
de usar sqlconnection, sqlcommand usariamos los oledb, cierto?



Sí, asi podrías hacerlo, pero realmente no es necesario meter la
sentencia dentro de un procedimiento almacenado solo para usar el
ExecuteScalar. Te copio a continuación tu propio código pero modificado para
usar el ExecuteScalar:

int total;
string fichero = "..\\..\\bd1.mdb ";
string ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" +
fichero;
OleDbConnection connection = new OleDbConnection(ConnectionString);
OleDbCommand command = new OleDbCommand("SELECT count(*) from
mayoristas",connection);
connection.Open();
total = (int)command.ExecuteScalar();
connection.Close();
email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una pregunta AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida