Extraño comportamiento de UpdateBatch y ADO

15/06/2008 - 16:44 por MhBeyle | Informe spam
Dejando a un lado las incomodidades deADO, os cuento algo
bastanteextrañoque me sucede con la actualización de un
recordsetADOcargado
con datos de SQL Server. Elcomportamientose reproduce igualmente en
vb 6.0, .NET y en SQL server 2000/2005. No he probado a reproducir el
síntoma en otros lenguajes.
También he leído bastante literatura al respecto de esto y de otros
fallos similares, pero nadie parece haber dado con una respuesta
correcta.

La cadena de conexión que utilizo es la siguiente:

.CursorLocation = adUseClient
.Open "Provider=MSDASQL;" & _
"driver={SQL Server};" & _
"server=" & Srv & ";" & _
"uid=" & uID & ";" & _
"pwd=" & pwd & ";" & _
"database=" & dB & ";"

La conexión del recordset:

.Open CadSQL, cnn_sql, adOpenDynamic, adBatchOptimistic, adCmdText

Y elcomportamientoextraño:

Realizo un .AddNew para que el cliente inserte datos en un formulario
lleno de cuadros de texto con su DataSource ligado al Recordset y sus
respectivos DataFiels ligados a los campos correspondientes.
Terminada la inserción de datos, se realiza un .UpdateBatch
adAffectAll y compruebo, tanto en el programa cliente y el Recordset
como en la traza del servidor que todo se ha realizado correctamente.
Sin problemas en ambos lugares. A excepción de algún problemilla con
un campo Identity que tengo que recuperar con un .Requery, todo bien.

Ahora supongamos que el cliente quiere manipular esos datos. Se abre
el formulario de la misma forma, pero apuntando al registro del
Recordset requerido, lo cual origina que queden rellenos los cuadros
de texto correspondientes. Se manipulan los datos y se acude a la
misma función y la misma órden .UpdateBatchadAffectAll . Compruebo
que los datos se actualizan en el Recordset y en la aplicación. Hago
incluso algún movimiento con .Move y vuelvo al registro manipulado.
Todo perfecto sobre el Recordset. Pero la traza del server no muestra
nada. Ni un miserable intento de acceso y, por supuesto, ni hablar de
un intento de actualización. El .UpdateBatchno genera errores de
ningún tipo. Todo se hace de la misma forma que el añadido de los
datos con .AddNew (incluso se utiliza la misma función), pero cuando
se manipulan datos que ya existen y se quieren grabar, la operación no
se realiza.

He probado con adUseServer y el resultado es similar. He cambiado el
tipo de cursor a Keyset y lo mismo. he probado a cambiar parámetros de
todo tipo y nada. Sencillamente, la operación Update no funciona. Y lo
peor es que no genera errores.

Por supuesto, realizar un Update mediante un sp o una cadena de
conexión funciona sin ningún tipo de problemas.

Me lo expliquen.

MhBeyle ____

Preguntas similare

Leer las respuestas

#1 Victor Koch
17/06/2008 - 17:04 | Informe spam
Hola,

.Open CadSQL, cnn_sql, adOpenDynamic, adBatchOptimistic, adCmdText

Por

.Open CadSQL, cnn_sql, adOpenDynamic, adLockBatchOptimistic, adCmdText


Un Saludo, Víctor Koch



"MhBeyle" escribió en el mensaje
news:
Dejando a un lado las incomodidades deADO, os cuento algo
bastanteextrañoque me sucede con la actualización de un
recordsetADOcargado
con datos de SQL Server. Elcomportamientose reproduce igualmente en
vb 6.0, .NET y en SQL server 2000/2005. No he probado a reproducir el
síntoma en otros lenguajes.
También he leído bastante literatura al respecto de esto y de otros
fallos similares, pero nadie parece haber dado con una respuesta
correcta.

La cadena de conexión que utilizo es la siguiente:

.CursorLocation = adUseClient
.Open "Provider=MSDASQL;" & _
"driver={SQL Server};" & _
"server=" & Srv & ";" & _
"uid=" & uID & ";" & _
"pwd=" & pwd & ";" & _
"database=" & dB & ";"

La conexión del recordset:

.Open CadSQL, cnn_sql, adOpenDynamic, adBatchOptimistic, adCmdText

Y elcomportamientoextraño:

Realizo un .AddNew para que el cliente inserte datos en un formulario
lleno de cuadros de texto con su DataSource ligado al Recordset y sus
respectivos DataFiels ligados a los campos correspondientes.
Terminada la inserción de datos, se realiza un .UpdateBatch
adAffectAll y compruebo, tanto en el programa cliente y el Recordset
como en la traza del servidor que todo se ha realizado correctamente.
Sin problemas en ambos lugares. A excepción de algún problemilla con
un campo Identity que tengo que recuperar con un .Requery, todo bien.

Ahora supongamos que el cliente quiere manipular esos datos. Se abre
el formulario de la misma forma, pero apuntando al registro del
Recordset requerido, lo cual origina que queden rellenos los cuadros
de texto correspondientes. Se manipulan los datos y se acude a la
misma función y la misma órden .UpdateBatchadAffectAll . Compruebo
que los datos se actualizan en el Recordset y en la aplicación. Hago
incluso algún movimiento con .Move y vuelvo al registro manipulado.
Todo perfecto sobre el Recordset. Pero la traza del server no muestra
nada. Ni un miserable intento de acceso y, por supuesto, ni hablar de
un intento de actualización. El .UpdateBatchno genera errores de
ningún tipo. Todo se hace de la misma forma que el añadido de los
datos con .AddNew (incluso se utiliza la misma función), pero cuando
se manipulan datos que ya existen y se quieren grabar, la operación no
se realiza.

He probado con adUseServer y el resultado es similar. He cambiado el
tipo de cursor a Keyset y lo mismo. he probado a cambiar parámetros de
todo tipo y nada. Sencillamente, la operación Update no funciona. Y lo
peor es que no genera errores.

Por supuesto, realizar un Update mediante un sp o una cadena de
conexión funciona sin ningún tipo de problemas.

Me lo expliquen.

MhBeyle ____
Respuesta Responder a este mensaje
#2 Jesús López
20/06/2008 - 18:09 | Informe spam
La verdad es que explicación no es que tenga mucha. Sólo te puedo decir que
el modo de actualizaciones por lotes sólo está disponible con cursores de
cliente de tipo estático, así que hay alguna inconsistencia en el código que
has mandado. Debería ser así:

Open CadSQL, cnn_sql, adOpenStatic, adLockBatchOptimistic, adCmdText

Cabría entoces preguntarse que si la combinación de CursorLocation,
CurrsorType y LockType no es posible, entonces ¿por qué no da error? Bien,
ADO hace lo que le da la gana y elige una combinación posible a partir de la
que tú le has solicitado, la combinación real no tiene por que ser la
solicitada.

Saludos:

Jesús López
www.solidq.com




"MhBeyle" escribió en el mensaje
news:
Dejando a un lado las incomodidades deADO, os cuento algo
bastanteextrañoque me sucede con la actualización de un
recordsetADOcargado
con datos de SQL Server. Elcomportamientose reproduce igualmente en
vb 6.0, .NET y en SQL server 2000/2005. No he probado a reproducir el
síntoma en otros lenguajes.
También he leído bastante literatura al respecto de esto y de otros
fallos similares, pero nadie parece haber dado con una respuesta
correcta.

La cadena de conexión que utilizo es la siguiente:

.CursorLocation = adUseClient
.Open "Provider=MSDASQL;" & _
"driver={SQL Server};" & _
"server=" & Srv & ";" & _
"uid=" & uID & ";" & _
"pwd=" & pwd & ";" & _
"database=" & dB & ";"

La conexión del recordset:

.Open CadSQL, cnn_sql, adOpenDynamic, adBatchOptimistic, adCmdText

Y elcomportamientoextraño:

Realizo un .AddNew para que el cliente inserte datos en un formulario
lleno de cuadros de texto con su DataSource ligado al Recordset y sus
respectivos DataFiels ligados a los campos correspondientes.
Terminada la inserción de datos, se realiza un .UpdateBatch
adAffectAll y compruebo, tanto en el programa cliente y el Recordset
como en la traza del servidor que todo se ha realizado correctamente.
Sin problemas en ambos lugares. A excepción de algún problemilla con
un campo Identity que tengo que recuperar con un .Requery, todo bien.

Ahora supongamos que el cliente quiere manipular esos datos. Se abre
el formulario de la misma forma, pero apuntando al registro del
Recordset requerido, lo cual origina que queden rellenos los cuadros
de texto correspondientes. Se manipulan los datos y se acude a la
misma función y la misma órden .UpdateBatchadAffectAll . Compruebo
que los datos se actualizan en el Recordset y en la aplicación. Hago
incluso algún movimiento con .Move y vuelvo al registro manipulado.
Todo perfecto sobre el Recordset. Pero la traza del server no muestra
nada. Ni un miserable intento de acceso y, por supuesto, ni hablar de
un intento de actualización. El .UpdateBatchno genera errores de
ningún tipo. Todo se hace de la misma forma que el añadido de los
datos con .AddNew (incluso se utiliza la misma función), pero cuando
se manipulan datos que ya existen y se quieren grabar, la operación no
se realiza.

He probado con adUseServer y el resultado es similar. He cambiado el
tipo de cursor a Keyset y lo mismo. he probado a cambiar parámetros de
todo tipo y nada. Sencillamente, la operación Update no funciona. Y lo
peor es que no genera errores.

Por supuesto, realizar un Update mediante un sp o una cadena de
conexión funciona sin ningún tipo de problemas.

Me lo expliquen.

MhBeyle ____
Respuesta Responder a este mensaje
#3 MhBeyle
20/06/2008 - 21:10 | Informe spam
¿Dónde has leído eso de que la actualización por lotes sólo funciona
con cursores estáticos? Yo creía que funcionaba con estáticos y
dinámicos y nunca, obviamente, con los cursores de sólo lectura.

Entiendo (bueno, no lo entiendo, otra chapuza más) que ADO
reinterprete el tipo de cursor y lo adapte a lo que cree que yo le
pido si los parámetros no son compatibles entre si, pero no entiendo
cómo es posible que en un proceso de INSERT funcione y en un UPDATE
no. Y que en el segundo ni tan siquiera de un miserable error.
Sencillamente no hace nada y el programa sigue adelante como si tal
cosa. Y está claro que el error está en ADO pues sobre SQL server no
se recibe ninguna operación.

Por cierto, creo que no lo he escrito, pero también probé con cursor
estático, a ver qué pasaba y el resultado fue el mismo.

En fin. Con esto de la actualización por lotes trataba de quitarme de
encima la escritura de procedimientos en SQL, ya que la aplicación que
estoy haciendo es muy sencilla, pero veo que tendré que seguir
escribiendo.

Un saludo y muchas gracias por el interés, a ver si a alguien se le
enciende alguna lucecita, aunque sólo sea ya por la honra :)

MhBeyle ___

"Jesús López" escribió lo
siguiente ...

La verdad es que explicación no es que tenga mucha. Sólo te puedo decir que
el modo de actualizaciones por lotes sólo está disponible con cursores de
cliente de tipo estático, así que hay alguna inconsistencia en el código que
has mandado. Debería ser así:

Open CadSQL, cnn_sql, adOpenStatic, adLockBatchOptimistic, adCmdText

Cabría entoces preguntarse que si la combinación de CursorLocation,
CurrsorType y LockType no es posible, entonces ¿por qué no da error? Bien,
ADO hace lo que le da la gana y elige una combinación posible a partir de la
que tú le has solicitado, la combinación real no tiene por que ser la
solicitada.

Saludos:

Jesús López
www.solidq.com




"MhBeyle" escribió en el mensaje
news:
Dejando a un lado las incomodidades deADO, os cuento algo
bastanteextrañoque me sucede con la actualización de un
recordsetADOcargado
con datos de SQL Server. Elcomportamientose reproduce igualmente en
vb 6.0, .NET y en SQL server 2000/2005. No he probado a reproducir el
síntoma en otros lenguajes.
También he leído bastante literatura al respecto de esto y de otros
fallos similares, pero nadie parece haber dado con una respuesta
correcta.

La cadena de conexión que utilizo es la siguiente:

.CursorLocation = adUseClient
.Open "Provider=MSDASQL;" & _
"driver={SQL Server};" & _
"server=" & Srv & ";" & _
"uid=" & uID & ";" & _
"pwd=" & pwd & ";" & _
"database=" & dB & ";"

La conexión del recordset:

.Open CadSQL, cnn_sql, adOpenDynamic, adBatchOptimistic, adCmdText

Y elcomportamientoextraño:

Realizo un .AddNew para que el cliente inserte datos en un formulario
lleno de cuadros de texto con su DataSource ligado al Recordset y sus
respectivos DataFiels ligados a los campos correspondientes.
Terminada la inserción de datos, se realiza un .UpdateBatch
adAffectAll y compruebo, tanto en el programa cliente y el Recordset
como en la traza del servidor que todo se ha realizado correctamente.
Sin problemas en ambos lugares. A excepción de algún problemilla con
un campo Identity que tengo que recuperar con un .Requery, todo bien.

Ahora supongamos que el cliente quiere manipular esos datos. Se abre
el formulario de la misma forma, pero apuntando al registro del
Recordset requerido, lo cual origina que queden rellenos los cuadros
de texto correspondientes. Se manipulan los datos y se acude a la
misma función y la misma órden .UpdateBatchadAffectAll . Compruebo
que los datos se actualizan en el Recordset y en la aplicación. Hago
incluso algún movimiento con .Move y vuelvo al registro manipulado.
Todo perfecto sobre el Recordset. Pero la traza del server no muestra
nada. Ni un miserable intento de acceso y, por supuesto, ni hablar de
un intento de actualización. El .UpdateBatchno genera errores de
ningún tipo. Todo se hace de la misma forma que el añadido de los
datos con .AddNew (incluso se utiliza la misma función), pero cuando
se manipulan datos que ya existen y se quieren grabar, la operación no
se realiza.

He probado con adUseServer y el resultado es similar. He cambiado el
tipo de cursor a Keyset y lo mismo. he probado a cambiar parámetros de
todo tipo y nada. Sencillamente, la operación Update no funciona. Y lo
peor es que no genera errores.

Por supuesto, realizar un Update mediante un sp o una cadena de
conexión funciona sin ningún tipo de problemas.

Me lo expliquen.

MhBeyle ____

Respuesta Responder a este mensaje
#4 Jesús López
21/06/2008 - 09:37 | Informe spam
¿Dónde has leído eso de que la actualización por lotes sólo funciona
con cursores estáticos?



Bueno en realidad, las actualizaciones por lotes solo funcionan con los
cursores de cliente, y sólo hay un tipo de cursor de cliente que son los
estáticos.

Saludos:

Jesús López
www.solidq.com






"MhBeyle" escribió en el mensaje
news:
¿Dónde has leído eso de que la actualización por lotes sólo funciona
con cursores estáticos? Yo creía que funcionaba con estáticos y
dinámicos y nunca, obviamente, con los cursores de sólo lectura.

Entiendo (bueno, no lo entiendo, otra chapuza más) que ADO
reinterprete el tipo de cursor y lo adapte a lo que cree que yo le
pido si los parámetros no son compatibles entre si, pero no entiendo
cómo es posible que en un proceso de INSERT funcione y en un UPDATE
no. Y que en el segundo ni tan siquiera de un miserable error.
Sencillamente no hace nada y el programa sigue adelante como si tal
cosa. Y está claro que el error está en ADO pues sobre SQL server no
se recibe ninguna operación.

Por cierto, creo que no lo he escrito, pero también probé con cursor
estático, a ver qué pasaba y el resultado fue el mismo.

En fin. Con esto de la actualización por lotes trataba de quitarme de
encima la escritura de procedimientos en SQL, ya que la aplicación que
estoy haciendo es muy sencilla, pero veo que tendré que seguir
escribiendo.

Un saludo y muchas gracias por el interés, a ver si a alguien se le
enciende alguna lucecita, aunque sólo sea ya por la honra :)

MhBeyle ___

"Jesús López" escribió lo
siguiente ...

La verdad es que explicación no es que tenga mucha. Sólo te puedo decir
que
el modo de actualizaciones por lotes sólo está disponible con cursores de
cliente de tipo estático, así que hay alguna inconsistencia en el código
que
has mandado. Debería ser así:

Open CadSQL, cnn_sql, adOpenStatic, adLockBatchOptimistic, adCmdText

Cabría entoces preguntarse que si la combinación de CursorLocation,
CurrsorType y LockType no es posible, entonces ¿por qué no da error? Bien,
ADO hace lo que le da la gana y elige una combinación posible a partir de
la
que tú le has solicitado, la combinación real no tiene por que ser la
solicitada.

Saludos:

Jesús López
www.solidq.com




"MhBeyle" escribió en el mensaje
news:
Dejando a un lado las incomodidades deADO, os cuento algo
bastanteextrañoque me sucede con la actualización de un
recordsetADOcargado
con datos de SQL Server. Elcomportamientose reproduce igualmente en
vb 6.0, .NET y en SQL server 2000/2005. No he probado a reproducir el
síntoma en otros lenguajes.
También he leído bastante literatura al respecto de esto y de otros
fallos similares, pero nadie parece haber dado con una respuesta
correcta.

La cadena de conexión que utilizo es la siguiente:

.CursorLocation = adUseClient
.Open "Provider=MSDASQL;" & _
"driver={SQL Server};" & _
"server=" & Srv & ";" & _
"uid=" & uID & ";" & _
"pwd=" & pwd & ";" & _
"database=" & dB & ";"

La conexión del recordset:

.Open CadSQL, cnn_sql, adOpenDynamic, adBatchOptimistic, adCmdText

Y elcomportamientoextraño:

Realizo un .AddNew para que el cliente inserte datos en un formulario
lleno de cuadros de texto con su DataSource ligado al Recordset y sus
respectivos DataFiels ligados a los campos correspondientes.
Terminada la inserción de datos, se realiza un .UpdateBatch
adAffectAll y compruebo, tanto en el programa cliente y el Recordset
como en la traza del servidor que todo se ha realizado correctamente.
Sin problemas en ambos lugares. A excepción de algún problemilla con
un campo Identity que tengo que recuperar con un .Requery, todo bien.

Ahora supongamos que el cliente quiere manipular esos datos. Se abre
el formulario de la misma forma, pero apuntando al registro del
Recordset requerido, lo cual origina que queden rellenos los cuadros
de texto correspondientes. Se manipulan los datos y se acude a la
misma función y la misma órden .UpdateBatchadAffectAll . Compruebo
que los datos se actualizan en el Recordset y en la aplicación. Hago
incluso algún movimiento con .Move y vuelvo al registro manipulado.
Todo perfecto sobre el Recordset. Pero la traza del server no muestra
nada. Ni un miserable intento de acceso y, por supuesto, ni hablar de
un intento de actualización. El .UpdateBatchno genera errores de
ningún tipo. Todo se hace de la misma forma que el añadido de los
datos con .AddNew (incluso se utiliza la misma función), pero cuando
se manipulan datos que ya existen y se quieren grabar, la operación no
se realiza.

He probado con adUseServer y el resultado es similar. He cambiado el
tipo de cursor a Keyset y lo mismo. he probado a cambiar parámetros de
todo tipo y nada. Sencillamente, la operación Update no funciona. Y lo
peor es que no genera errores.

Por supuesto, realizar un Update mediante un sp o una cadena de
conexión funciona sin ningún tipo de problemas.

Me lo expliquen.

MhBeyle ____

email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaRespuesta Tengo una respuesta
Search Busqueda sugerida