Get Rows devuelve campos vacíos

A mi también me extrañó, y le di vueltas de mala manera,
porque además creo que no debería fallar sólo en algunos
campos y no en algunos registros, pero lo cierto es que
utilizando otro cursor distinto de adForwardOnly todo va bien.

No entiendo por qué dices que usar getRows con cursores
estáticos desperdicia muchos recursos. Siempre había creido
que era la forma más eficiente de trabajar con los datos de
un recordset. ¿puedes darme alguna pista o alguna dirección
en la que buscar?

gracias y saludos
Pablo Taboada

Pues eso si que me extraña... se supone que por defecto es 0
(adOpenForwardOnly)... es decir que ni siquiera deberías

decirselo!! (no

estarás dandole CursorLocation en el server???)
Por otro lado usar getrows con cursores estáticos o

dinámicos es un

desperdicio de recursos... tampoco te funciona con keyset??
Dale una mirada a éste artículo (y algunos otros mediante

sus links)

http://www.learnasp.com/learn/dbcount.asp

Sashka
MS MVP Access
MCP ASP.Net

La idea es destruir inmediatamente cualquier Recordset y connection
asociado, y trabajar con el getrows posteriormente... con esto liberas
recursos...


"Pablo Taboada" escribió en el mensaje
news:3f2501c4aacd$dbc11be0$
A mi también me extrañó, y le di vueltas de mala manera,
porque además creo que no debería fallar sólo en algunos
campos y no en algunos registros, pero lo cierto es que
utilizando otro cursor distinto de adForwardOnly todo va bien.

No entiendo por qué dices que usar getRows con cursores
estáticos desperdicia muchos recursos. Siempre había creido
que era la forma más eficiente de trabajar con los datos de
un recordset. ¿puedes darme alguna pista o alguna dirección
en la que buscar?

gracias y saludos
Pablo Taboada

Pues eso si que me extraña... se supone que por defecto es 0
(adOpenForwardOnly)... es decir que ni siquiera deberías

decirselo!! (no

estarás dandole CursorLocation en el server???)
Por otro lado usar getrows con cursores estáticos o

dinámicos es un

desperdicio de recursos... tampoco te funciona con keyset??
Dale una mirada a éste artículo (y algunos otros mediante

sus links)

http://www.learnasp.com/learn/dbcount.asp

Sashka
MS MVP Access
MCP ASP.Net

¡Importante!: Colabora con el grupo.Contesta a este mensaje y dinos si te
sirvió o no la respuesta dada. Muchas gracias
Bueno.. no es una pregunta fácil de responder basicamente me refería a
que estás "duplicando" facilidades es decir si abres un recordset como
dinámico obtendrás las mismas facilidades (posibilidad de contar los
registros, por ejemplo) que recogiendo un forwardonly en un array (con
getrows)... sólo que implica más recursos (demora más en abrir!!)...
Hay muchas pruebas por allí ... te paso un par de links...
http://www.adopenstatic.com/experim...paging.asp
http://www.avdf.com/oct98/art_ot002.html


Sashka
MS MVP Access
MCP ASP.Net

"Pablo Taboada" escribió en el mensaje
news:3f2501c4aacd$dbc11be0$
A mi también me extrañó, y le di vueltas de mala manera,
porque además creo que no debería fallar sólo en algunos
campos y no en algunos registros, pero lo cierto es que
utilizando otro cursor distinto de adForwardOnly todo va bien.

No entiendo por qué dices que usar getRows con cursores
estáticos desperdicia muchos recursos. Siempre había creido
que era la forma más eficiente de trabajar con los datos de
un recordset. ¿puedes darme alguna pista o alguna dirección
en la que buscar?

gracias y saludos
Pablo Taboada

Pues eso si que me extraña... se supone que por defecto es 0
(adOpenForwardOnly)... es decir que ni siquiera deberías

decirselo!! (no

estarás dandole CursorLocation en el server???)
Por otro lado usar getrows con cursores estáticos o

dinámicos es un

desperdicio de recursos... tampoco te funciona con keyset??
Dale una mirada a éste artículo (y algunos otros mediante

sus links)

http://www.learnasp.com/learn/dbcount.asp

Sashka
MS MVP Access
MCP ASP.Net

Sigo con el mismo tema, pero antes de nada, muchas gracias
por todos vuestros comentarios, me están sirviendo de mucho
y me están ayudando a entender mejor el tema de los
recordsets y demás, que siempre me interesó (soy un poco
maniático de la optimización).

Después de darle muchas vueltas creo que el problema está
en la combinación de varias cosas:
- hace poco hice la migración de la aplicación desde Access
a SQLServer, para lo cual utilicé los proyectos de Access
para "importar" a la base de SQLServer todas las tablas y
datos de la base originaria. En principio parece que todo
fué bien, pero me da la sensación de que el problema ahora
me lo están dando los campos "memo" de access.

Acabo de hacer una página que prueba todas las
combinaciones de CursorType y LockType entre si frente a la
misma tabla de base de datos. En realidad la página es un
bucle que va obteniendo un registro completo de la tabla
uqe me da problemas con los distintos valores, lo vuelca en
un array con getRows y lo muestra por pantalla (además del
tiempo que le llevó el proceso en cada caso).

Lo primero que llama la atención es que los tiempos son
mucho menores para el caso de usar el adForwardOnly, pero
sólo en este caso hay problemas con los campos memo. Si
utilizo adForwardOnly junto con adLockReadOnly no me
muestra datos en ninguno de los campos desde el primero de
tipo memo hasta el último de tipo memo (ni en todos los que
hay entre ellos que no son memo). En todos los demás casos
usando adForwardOnly me muestra los campos intermedios,
pero no me muestra los campos de tipo memo.

Usando cualquier otro tipo de cursor me muestra todos los
campos (independientemente del tipo), pero los tiempos de
respuestas se disparan por 10 o más.

Además, en el MSDN, en la página de constantes de ADO, bajo
el apartado de CursorType, figura la siguiente nota:
<i>Nota Los cursores ForwardOnly (desplazamiento sólo
hacia delante) no están disponibles para el control de
datos ADO.</i>
Por lo que el problema también puede estar aquí. Por otros
lados leí que con sql-server es mejor utilizar OLEDB como
controlador en lugar de un ODBC cualquiera, pero no tengo
posibilidad de cambiar esto, que yo sepa, pues no tengo
acceso al servidor de base de datos.

Por último, en cuanto al tema de los recursos y getRows, lo
que hago siempre es exactamente lo que comentais, es decir:
Creo el objeto RecordSet, establezco sus propiedades, lo
abro, vuelco el contenido con getRows, lo cierro y lo
destruyo antes de hacer nada más con el array.

Bueno, lamento la longitud del mensaje, pero no he
encontrado otra forma mejor de expresar todo esto. Creo que
a partir de ahora voy a participar más en este foro, que
promete.

más saludos

¡Importante!: Colabora con el grupo.Contesta a este

mensaje y dinos si te

sirvió o no la respuesta dada. Muchas gracias
Bueno.. no es una pregunta fácil de responder

basicamente me refería a

que estás "duplicando" facilidades es decir si abres

un recordset como

dinámico obtendrás las mismas facilidades (posibilidad de

contar los

registros, por ejemplo) que recogiendo un forwardonly en

un array (con

getrows)... sólo que implica más recursos (demora más en

abrir!!)...

Hay muchas pruebas por allí ... te paso un par de links...
http://www.adopenstatic.com/experim...paging.asp
http://www.avdf.com/oct98/art_ot002.html


Sashka
MS MVP Access
MCP ASP.Net

"Pablo Taboada"

escribió en el mensaje

news:3f2501c4aacd$dbc11be0$
A mi también me extrañó, y le di vueltas de mala manera,
porque además creo que no debería fallar sólo en algunos
campos y no en algunos registros, pero lo cierto es que
utilizando otro cursor distinto de adForwardOnly todo va bien.

No entiendo por qué dices que usar getRows con cursores
estáticos desperdicia muchos recursos. Siempre había creido
que era la forma más eficiente de trabajar con los datos de
un recordset. ¿puedes darme alguna pista o alguna dirección
en la que buscar?

gracias y saludos
Pablo Taboada

Pues eso si que me extraña... se supone que por defecto es 0
(adOpenForwardOnly)... es decir que ni siquiera deberías

decirselo!! (no

estarás dandole CursorLocation en el server???)
Por otro lado usar getrows con cursores estáticos o

dinámicos es un

desperdicio de recursos... tampoco te funciona con keyset??
Dale una mirada a éste artículo (y algunos otros mediante

sus links)

http://www.learnasp.com/learn/dbcount.asp

Sashka
MS MVP Access
MCP ASP.Net

.

¡Importante!: Colabora con el grupo.Contesta a este mensaje y dinos si te
sirvió o no la respuesta dada. Muchas gracias
:)) Haber comenzado por allí!!!
Se trata de la forma en que SQL Server devuelve los datos BLOB y es que
lo hace secuencialmente... por eso no se aconseja tener más de un campo...
pero sobre todo.. tengas los que tengas (en el sql) deben ir al final (y de
ser posible primero los más pequeños y luego los mas grandes)
Tu problema está documentado
http://support.microsoft.com/defaul...?scid=http://support.microsoft.com:80/support/kb/articles/Q175/2/39.asp&NoWebContent=1
Y aunque a ti no te dé el error específico que dice el KB... hay algunos que
han reportado lo que tu al respecto ...
http://www.mail-archive.com//msg01037.html
Por otro lado, lo del control ADO no aplica a ASP
Y además no tiene que ver el que tu no tengas acceso servidor de base de
datos con tu cadena de conexión si estas usando dsn quizá podrías
probar con coneciones dsnless. aca tienes algunos ejemplos (fijate que
en OLE DB Provider for ODBC Databases dice... WARNING: This OLE DB Provider
is considered obsolete by Microsoft!) y revisa la cadena de conexión para
OLE DB Provider for SQLBase
http://www.able-consulting.com/ADO_Conn.htm

Sashka
MS MVP Access
MCP ASP.Net

"Pablo Taboada" escribió en el mensaje
news:40d301c4ab9e$2e9fbee0$
Sigo con el mismo tema, pero antes de nada, muchas gracias
por todos vuestros comentarios, me están sirviendo de mucho
y me están ayudando a entender mejor el tema de los
recordsets y demás, que siempre me interesó (soy un poco
maniático de la optimización).

Después de darle muchas vueltas creo que el problema está
en la combinación de varias cosas:
- hace poco hice la migración de la aplicación desde Access
a SQLServer, para lo cual utilicé los proyectos de Access
para "importar" a la base de SQLServer todas las tablas y
datos de la base originaria. En principio parece que todo
fué bien, pero me da la sensación de que el problema ahora
me lo están dando los campos "memo" de access.

Acabo de hacer una página que prueba todas las
combinaciones de CursorType y LockType entre si frente a la
misma tabla de base de datos. En realidad la página es un
bucle que va obteniendo un registro completo de la tabla
uqe me da problemas con los distintos valores, lo vuelca en
un array con getRows y lo muestra por pantalla (además del
tiempo que le llevó el proceso en cada caso).

Lo primero que llama la atención es que los tiempos son
mucho menores para el caso de usar el adForwardOnly, pero
sólo en este caso hay problemas con los campos memo. Si
utilizo adForwardOnly junto con adLockReadOnly no me
muestra datos en ninguno de los campos desde el primero de
tipo memo hasta el último de tipo memo (ni en todos los que
hay entre ellos que no son memo). En todos los demás casos
usando adForwardOnly me muestra los campos intermedios,
pero no me muestra los campos de tipo memo.

Usando cualquier otro tipo de cursor me muestra todos los
campos (independientemente del tipo), pero los tiempos de
respuestas se disparan por 10 o más.

Además, en el MSDN, en la página de constantes de ADO, bajo
el apartado de CursorType, figura la siguiente nota:
<i>Nota Los cursores ForwardOnly (desplazamiento sólo
hacia delante) no están disponibles para el control de
datos ADO.</i>
Por lo que el problema también puede estar aquí. Por otros
lados leí que con sql-server es mejor utilizar OLEDB como
controlador en lugar de un ODBC cualquiera, pero no tengo
posibilidad de cambiar esto, que yo sepa, pues no tengo
acceso al servidor de base de datos.

Por último, en cuanto al tema de los recursos y getRows, lo
que hago siempre es exactamente lo que comentais, es decir:
Creo el objeto RecordSet, establezco sus propiedades, lo
abro, vuelco el contenido con getRows, lo cierro y lo
destruyo antes de hacer nada más con el array.

Bueno, lamento la longitud del mensaje, pero no he
encontrado otra forma mejor de expresar todo esto. Creo que
a partir de ahora voy a participar más en este foro, que
promete.

más saludos

¡Importante!: Colabora con el grupo.Contesta a este

mensaje y dinos si te

sirvió o no la respuesta dada. Muchas gracias
Bueno.. no es una pregunta fácil de responder

basicamente me refería a

que estás "duplicando" facilidades es decir si abres

un recordset como

dinámico obtendrás las mismas facilidades (posibilidad de

contar los

registros, por ejemplo) que recogiendo un forwardonly en

un array (con

getrows)... sólo que implica más recursos (demora más en

abrir!!)...

Hay muchas pruebas por allí ... te paso un par de links...
http://www.adopenstatic.com/experim...paging.asp
http://www.avdf.com/oct98/art_ot002.html


Sashka
MS MVP Access
MCP ASP.Net

"Pablo Taboada"

escribió en el mensaje

news:3f2501c4aacd$dbc11be0$
A mi también me extrañó, y le di vueltas de mala manera,
porque además creo que no debería fallar sólo en algunos
campos y no en algunos registros, pero lo cierto es que
utilizando otro cursor distinto de adForwardOnly todo va bien.

No entiendo por qué dices que usar getRows con cursores
estáticos desperdicia muchos recursos. Siempre había creido
que era la forma más eficiente de trabajar con los datos de
un recordset. ¿puedes darme alguna pista o alguna dirección
en la que buscar?

gracias y saludos
Pablo Taboada

Pues eso si que me extraña... se supone que por defecto es 0
(adOpenForwardOnly)... es decir que ni siquiera deberías

decirselo!! (no

estarás dandole CursorLocation en el server???)
Por otro lado usar getrows con cursores estáticos o

dinámicos es un

desperdicio de recursos... tampoco te funciona con keyset??
Dale una mirada a éste artículo (y algunos otros mediante

sus links)

http://www.learnasp.com/learn/dbcount.asp

Sashka
MS MVP Access
MCP ASP.Net

.