me parece a mi o ado.net es muy lento

Hola amigo. Como primer paso te recomendaría verifiques si la sentencia SQL ó
el stored procedure no son la causa del problema. Es posible que el query sea
el que se esté demorando y no sea culpa de ADO.NET.

Si logras determinar que el problema no es del motor de BD, entonces te
recomendaría utilices el método ExecuteReader() de tu objeto Command, en
lugar de usar el método Fill del DataAdapter. El ExcecuteReader es el más
rápido en cualquier escenario de acceso a datos. Por ejemplo, si tu motor es
SQL Server, deberías hacer algo así:

Dim cn as New SqlConnection("Tu Cadena de conexión")
Dim cmd as new SqlCommand("Tu Query ó SP", cn)
cn.Open()
Dim rdr as SqlDataReader = cmd.ExecuteReader()
While rdr.Read()
'Tu manejo de los datos
End While
cn.Close()

Espero haber podido ayudarte.
Julio Casal
.Net Solution Developer
MCAD
Grupo Lebed


"lolo" wrote:

Estoy haciendo pruebas y la verdad que ado.net me va superlento..
el comando fill es de lo mas lento

tengo comando sql con rownum =6 sobre tablas de 300.000 registros y aun asi
es lento

Provando oledb es lo mismo o peor...
donde esta el data de vb6 que era super-rapido...

Yo no se utilizar al 100% ado.net pero no tiene mucho mas misterio que abrir
conexion poner comantext y ejecutar datareader y hacer fill aunque en todo es
muy rapido en hacer el fill es donde se queda pensando.. mucho tiempo

hola, muchas gracias por tu contestacion..
te comento , ahora hago eso exactamente. los datos se visualizan en un
datagrid y lo que hago es mediante programacion insertar los datos en el
datagrid solo los que se ven y si quiere ver mas introduzco uno a uno...
hasta el final.
pero eso antes lo hacia solo el data en vb6 y no me preocupaba de nada,

Por eso digo que es lento cuando se utiliza el fill.
La verdad que como lo estoy haciendo ahora me resulta como programar
antiguamente, para que se invento el sql si tengo que mostrar los datos uno a
no mediante codigo

nose, gracias por tu respuesta. pero si hubiera sabido esto no me hubiera
pasado a .net

"Julio Casal" escribió:

Hola amigo. Como primer paso te recomendaría verifiques si la sentencia SQL ó
el stored procedure no son la causa del problema. Es posible que el query sea
el que se esté demorando y no sea culpa de ADO.NET.

Si logras determinar que el problema no es del motor de BD, entonces te
recomendaría utilices el método ExecuteReader() de tu objeto Command, en
lugar de usar el método Fill del DataAdapter. El ExcecuteReader es el más
rápido en cualquier escenario de acceso a datos. Por ejemplo, si tu motor es
SQL Server, deberías hacer algo así:

Dim cn as New SqlConnection("Tu Cadena de conexión")
Dim cmd as new SqlCommand("Tu Query ó SP", cn)
cn.Open()
Dim rdr as SqlDataReader = cmd.ExecuteReader()
While rdr.Read()
'Tu manejo de los datos
End While
cn.Close()

Espero haber podido ayudarte.
Julio Casal
.Net Solution Developer
MCAD
Grupo Lebed


"lolo" wrote:

> Estoy haciendo pruebas y la verdad que ado.net me va superlento..
> el comando fill es de lo mas lento
>
> tengo comando sql con rownum =6 sobre tablas de 300.000 registros y aun asi
> es lento
>
> Provando oledb es lo mismo o peor...
> donde esta el data de vb6 que era super-rapido...
>
> Yo no se utilizar al 100% ado.net pero no tiene mucho mas misterio que abrir
> conexion poner comantext y ejecutar datareader y hacer fill aunque en todo es
> muy rapido en hacer el fill es donde se queda pensando.. mucho tiempo

Espera a ver la nueva versión de Visual Studio, la 2005. Hay varias novedades
en relación a acceso a datos. Te lo recomiendo.

Saludos.

Julio Casal
.Net Solution Developer
MCAD
Grupo Lebed


"lolo" wrote:

hola, muchas gracias por tu contestacion..
te comento , ahora hago eso exactamente. los datos se visualizan en un
datagrid y lo que hago es mediante programacion insertar los datos en el
datagrid solo los que se ven y si quiere ver mas introduzco uno a uno...
hasta el final.
pero eso antes lo hacia solo el data en vb6 y no me preocupaba de nada,

Por eso digo que es lento cuando se utiliza el fill.
La verdad que como lo estoy haciendo ahora me resulta como programar
antiguamente, para que se invento el sql si tengo que mostrar los datos uno a
no mediante codigo

nose, gracias por tu respuesta. pero si hubiera sabido esto no me hubiera
pasado a .net

"Julio Casal" escribió:

> Hola amigo. Como primer paso te recomendaría verifiques si la sentencia SQL ó
> el stored procedure no son la causa del problema. Es posible que el query sea
> el que se esté demorando y no sea culpa de ADO.NET.
>
> Si logras determinar que el problema no es del motor de BD, entonces te
> recomendaría utilices el método ExecuteReader() de tu objeto Command, en
> lugar de usar el método Fill del DataAdapter. El ExcecuteReader es el más
> rápido en cualquier escenario de acceso a datos. Por ejemplo, si tu motor es
> SQL Server, deberías hacer algo así:
>
> Dim cn as New SqlConnection("Tu Cadena de conexión")
> Dim cmd as new SqlCommand("Tu Query ó SP", cn)
> cn.Open()
> Dim rdr as SqlDataReader = cmd.ExecuteReader()
> While rdr.Read()
> 'Tu manejo de los datos
> End While
> cn.Close()
>
> Espero haber podido ayudarte.
> Julio Casal
> .Net Solution Developer
> MCAD
> Grupo Lebed
>
>
> "lolo" wrote:
>
> > Estoy haciendo pruebas y la verdad que ado.net me va superlento..
> > el comando fill es de lo mas lento
> >
> > tengo comando sql con rownum =6 sobre tablas de 300.000 registros y aun asi
> > es lento
> >
> > Provando oledb es lo mismo o peor...
> > donde esta el data de vb6 que era super-rapido...
> >
> > Yo no se utilizar al 100% ado.net pero no tiene mucho mas misterio que abrir
> > conexion poner comantext y ejecutar datareader y hacer fill aunque en todo es
> > muy rapido en hacer el fill es donde se queda pensando.. mucho tiempo