consulta sobre recordset y grid

Tenes razón, no es una discusión, fue una forma de decir que iba a venir un
intercambio de opiniones.
Si ves el mensaje que te envíe en donde dice:

"Esto que te envío es un ejemplo, yo uso mas propiedades que ahora no vienen
al caso"

Las propiedades que uso y modifico a mano como decís vos son las que a
continuación te envío, y estas las uso únicamente cuando tengo cursores del
lado del server ya que para algunas bases de datos estas propiedades se
inicializan mal, según mi opinión.

Dim TB As adodb.recordset
Set TB = New ADODB.Recordset
With TB
..
...
.

If .CursorLocation = adUseServer Then
.Properties("IRowsetIdentity").Value = True
.Properties("Preserve On Commit") = True
.Properties("Preserve On Abort") = True
End If
.Open SQL, , , , adCmdText
End With

Todos los días se aprende algo nuevo.

Un saludo, Víctor Koch.


"Softjaen" escribió en el mensaje
news:

"Victor Koch" escribió:

> Bueno, empezaron las discusiones, jeje,

Discusiones, ninguna, porque coincido contigo sobre la propiedad
«CursorLocation». :-)

> el CursorLocation del objeto connection será utilizado siempre y cuando
> no se especifique implícitamente la asignación a esta propiedad del
> recordset

Efectivamente. Sólo he intentado aclarar que, según el código fuente
publicado por Carlos Mauricio, en éste caso, y a fin de evitar problemas,

la

propiedad «CursorLocation» hay que establecerza a «adUseClient» en el

objeto

«Connection» y no en el objeto «Recordset», porque de hacerlo en éste

último

objeto, continuará obteniendo el mismo error (el conjunto de filas no

admite

marcadores), dependiendo en la parte del código dónde establezca la
propiedad «CursorLocation».

Si observas el código, Carlos Mauricio utiliza dos instrucciones

«Set» -cosa

ésta, por cierto, que podría evitar-, para asignar una referencia de

objeto

a la variable objeto «rcsUsuarios»: la primera para ejecutar de una manera
muy «sui géneris», aunque válida, la instrucción SQL «Delete», y la

segunda

para abrir una consulta SQL de selección.

'*************************************
(1) Set rcsUsuarios = New ADODB.Recordset

rcsUsuarios.Open StrSql, acnProduccion, ..

StrSql = "select * from m_usuarios"

(2) Set rcsUsuarios = New ADODB.Recordset

rcsUsuarios.Open StrSql, acnProduccion, ..
'*************************************

Si especifica la propiedad «CursorLocation=adUseClient» en la primera
apertura del «Recordset», de nada sirve haberlo especificado porque al
asignar una nueva referencia al objeto, todas las propiedades del objeto
«Recordset» toman de nuevo sus respectivos valores por defecto, en el caso
de la propiedad «CursorLocation», el valor «adUseServer». En cambio, si
escribe la propiedad inmediatamente antes de llamar por segunda vez al
método «Open», entonces sí dispondrá de los cursores del lado cliente. Por
éste motivo, le indiqué que estableciera la propiedad
«CursorLocation=adUseClient» en el objeto «Connection», porque de ésta
manera, el «Recordset» heredará la posición del motor de cursores del

objeto

«Connection» al abrir el «Recordset», por lo que nos aseguramos que el
control «DataGrid» se rellenará con los valores devueltos por el conjunto

de

registros.

> yo tengo, en mis aplicaciones, objetos connection con cursores del lado
> del server y abro recordset con cursores del lado del cliente o server
> sobre el mismo objeto connection, ...

Aprovechando que estamos hablando de la propiedad «CursorLocation». No sé

si

sabras que también puedes utilizar sólo cursores del lado servidor
(adUseServer) e implementar la interfaz «IRowsetIdentity» para que de ésta
manera se puedan rellenar los controles «DataGrid» o «DataCombo», por
ejemplo, sin necesidad de especificar el valor «adUseClient», y ésto es

así

porque muchos proveedores de datos -entre ellos el popular Jet.OLEDB.4.0-,
no soportan la propiedad «DBPROP_LITERALIDENTITY», por lo que

necesariamente

hay que implementarla "a mano". :-)

Por si tú, o el resto de usuarios del grupo de noticias, deseáis probar el
ejemplo, os muestro cómo implementar la interfaz «IRowsetIdentity» para

que

se rellene el «DataGrid» con cursores del lado servidor:

Dim cnn As ADODB.Connection
Dim rst As ADODB.Recordset

' Configuramos el objeto «Connection»
Set cnn = New ADODB.Connection
With cnn
.Provider = "Microsoft.Jet.OLEDB.4.0"
.ConnectionString = "C:\Mis documentos\Bd1.mdb"
.Open
End With

' Creamos un nuevo objeto «Recordset»
Set rst = New ADODB.Recordset

With rst
' IMPORTANTE: para implementar la interfaz «IRowsetIdentity»
' hay que especificar explicitamente
' mediante la propiedad «ActiveConnection», a qué
' objeto «Connection» pertenece el objeto «Recodset»
.ActiveConnection = cnn

' Implementamos la propiedad «IRowsetIdentity»
.Properties("IRowsetIdentity") = True

' Configuramos el tipo de cursor y bloqueo
.CursorType = adOpenStatic
.LockType = adLockOptimistic

' Abrimos la tabla «Clientes», pero sin especificar
' el objeto «Connection»
.Open "Clientes", , , , adCmdTable
End With

' Enlazamos el control «DataGrid» con el objeto «Recordset»
Set DataGrid1.DataSource = rst

' Comprobamos los valores de ciertas propiedades
Debug.Print "CursorLocation del objeto Connection: " & _
cnn.CursorLocation

Debug.Print "CursorLocation del objeto Recordset: " & _
rst.CursorLocation

Debug.Print "CursorType del objeto Recordset: " & _
rst.CursorType

Debug.Print "LockType del objeto Recordset: " & _
rst.LockType

Debug.Print "RecordCount del objeto Recordset: " & _
rst.RecordCount

> por supuesto que en este ejemplo hay cosas que se contradicen, por
> ejemplo abrir un recordset con adOpenStatic no podría asignarce
> adLockOptimistic,

Víctor, yo creo que sí se puede asignar. Con independencia del valor de la
propiedad «CursorLocation», tanto con el proveedor Microsoft Jet, como con
el de SQL Server, el valor de la propiedad «LockType» puedes establecerla

a

«adLockOptimistic», aunque el valor de la propiedad «CursorType» sea
«adOpenStatic».

En cambio, la propiedad «CursorType», sí depende del valor de la propiedad
«CursorLocation». Si utilizas cursores del lado cliente, las propiedad
«CursorType» y «LockType» del objeto «Recordset», siempre tendrán los
siguientes valores:

TB.CursorType = adOpenStatic
TB.LockType = adLockOptimistic

Por el contrario, si utilizas cursores del lado servidor, una vez abierto

el

objeto «Recordset» dichas propiedades tendrán los siguiente valores,

aunque

hayas especificado «adOpenStatic» en la propiedad «CursorType»:

TB.CursorType = adOpenKeyset
TB.LockType = adLockOptimistic

Lo que no tiene sentido es especificar «CursorType = adOpenDynamic», con

el

proveedor de datos de «Microsoft.Jet», porque ese valor nunca podrá

tenerlo

el objeto «Recordset», y en el caso del proveedor de SQL Server, puede

tener

dicho valor si la propiedad «CursorLocation» está establecida a
«adUseServer», porque de lo contrario, tendrá el valor «adOpenStatic».

Bueno, termino ya porque creo que me he enrollado. :-)

Un saludo, Víctor.

Enrique Martínez
[MS MVP - VB]

"Victor Koch" escribió:

Las propiedades que uso y modifico a mano como decís vos son las que a
continuación te envío, y estas las uso únicamente cuando tengo cursores
del lado del server ya que para algunas bases de datos estas propiedades
se inicializan mal, según mi opinión.

If .CursorLocation = adUseServer Then
.Properties("IRowsetIdentity").Value = True
.Properties("Preserve On Commit") = True
.Properties("Preserve On Abort") = True
End If
.Open SQL, , , , adCmdText
End With

Efectivamente. Cuando se utilizan cursores del lado servidor, a veces es
necesario proporcionar al objeto «Recordset» algunas propiedades dinámicas
que sólo están disponibles si utilizamos cursores del lado cliente, de ésta
manera sólo utilizamos las propiedades necesarias que creamos conveniente, y
no todas las propiedades que están disponibles si establecemos la propiedad
«CursorLocation» a «adUseClient».

Todos los días se aprende algo nuevo.

Totalmente de acuerdo. :-)

Un saludo.

Enrique Martínez
[MS MVP - VB]

Bien, llegamos al mismo final pero tomando diferentes caminos, cuando me
puse a investigar esto del ADO y los cursores y llegue a la conclusión de
hacer el código tal cual te lo envíe, me refiero a esas propiedades tocadas
a mano, me parecía algo muy loco y pense que le estaba pifiando en algo,
pero el tiempo, dado que tengo aplicaciones corriendo desde hace mas de dos
años con ese código sin problemas, me confirma que hice bien las cosas, a
eso sumale lo que vos me confirmas, me salió todo redondo.

Un saludo, Víctor Koch.


"Softjaen" escribió en el mensaje
news:

"Victor Koch" escribió:
>
> Las propiedades que uso y modifico a mano como decís vos son las que a
> continuación te envío, y estas las uso únicamente cuando tengo cursores
> del lado del server ya que para algunas bases de datos estas propiedades
> se inicializan mal, según mi opinión.
>
> If .CursorLocation = adUseServer Then
> .Properties("IRowsetIdentity").Value = True
> .Properties("Preserve On Commit") = True
> .Properties("Preserve On Abort") = True
> End If
> .Open SQL, , , , adCmdText
> End With
>

Efectivamente. Cuando se utilizan cursores del lado servidor, a veces es
necesario proporcionar al objeto «Recordset» algunas propiedades dinámicas
que sólo están disponibles si utilizamos cursores del lado cliente, de

ésta

manera sólo utilizamos las propiedades necesarias que creamos conveniente,

y

no todas las propiedades que están disponibles si establecemos la

propiedad

«CursorLocation» a «adUseClient».

> Todos los días se aprende algo nuevo.
>

Totalmente de acuerdo. :-)

Un saludo.

Enrique Martínez
[MS MVP - VB]