Acceso exclusivo a la Tabla de la Base de Datos mediante código VBA

13/09/2004 - 03:33 por nadura | Informe spam
Con el siguiente Código mediante ADO puedo conseguir
bloquear un determinado registro de la base de Datos
cuando dos usuarios pretenden acceder a él de forma
simultánea:

Private Sub Command0_Click()
Dim cn As ADODB.Connection
Dim rs As ADODB.Recordset
Dim strText As String
Dim strConn As String
Dim iCliente As Integer
Dim iClienteValorCambiado As String

On Error GoTo err_ADO:

iCliente = InputBox("Introduzca el Código de Cliente a
buscar:" & vbNewLine & "Debe Introducir un valor
numerico.")
If Len(iCliente) = 0 Then
Exit Sub
End If

iClienteValorCambiado = InputBox("Introduzca el Valor
nuevo:")
If Len(iClienteValorCambiado) = 0 Then
Exit Sub
End If

strConn = "Provider=SQLOLEDB.1;Integrated
Security=SSPI;Persist Security Info=False;Initial
Catalog=Base de Datos SQL Server 2000;Data
Source=WINDOWSXP"
Set cn = New ADODB.Connection
Set rs = New ADODB.Recordset

cn.Open strConn
rs.Open "Select * from [Tabla de Clientes] WHERE
[C_CLIENTE]= " & iCliente, cn, adOpenStatic,
adLockPessimistic < Bloqueo del Registro con número
de cliente coincidente con el criterio de búsqueda.

MsgBox "Registro bloqueado: " & iCliente

Do Until rs.EOF
rs.Fields("N_CLIENTE").Value =
iClienteValorCambiado
MsgBox "Valor cambiado de " & iClienteValor & "
a " & iClienteValorCambiado
rs.MoveNext
Loop

rs.Close
cn.Close

Exit Sub

err_ADO:

MsgBox "Error: " & Err.Description
Resume Next

End Sub


Cuestión a Plantear: ¿Como debería modificar dicho código
para bloquear toda la Tabla, es decir, permitir a un
usuario concreto abrir la Tabla en modo exclusivo,
impidiendo a otros usuarios acceder a ésta, mientras el
primero esté realizando consultas ó modificaciones en la
misma?

¿Existe algún conversor para pasar código en DAO a ADO?

Preguntas similare

Leer las respuestas

#11 Maxi
15/09/2004 - 21:17 | Informe spam
Hola, perdon no, pero yo escribi hace poco un patron de esto que esta
publicado en:

http://www.microsoft.com/spanish/ms...art187.asp

Quizas te sea util


Salu2
Maxi
Buenos Aires - Argentina
Desarrollador Microsoft 3 Estrellas .NET
Nunca consideres el estudio como una obligación sino como
una oportunidad para penetrar en el bello y maravillosos
mundo del saber.
- Albert Einstein



"Rodrigo Corral [MVP]" escribió en el mensaje
news:
Interesante lo del articulo. Un patrón para obtener codigos unicos que no
sean identity es algo que seria muy util. Son tipicas las tablas de
secuencias de codigos.

Podrias orientarlo exponiendo las soluciones habituales y erroneas que


solo
funcionan con muy baja concurrencia y luego proponer la buena solución. En
cuanto lo tengas mandamelo!!!

Y ya por pedir si lo orientas tanto TSQL como a ADO perfecto!!!

Si necesitas mi colaboración en algo, algun ejemplo de código o lo que sea
me dices...


Un saludo
Rodrigo Corral González [MVP]

FAQ de microsoft.public.es.vc++
http://rcorral.mvps.org








Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.748 / Virus Database: 500 - Release Date: 01/09/2004
Respuesta Responder a este mensaje
#12 Rodrigo Corral [MVP]
16/09/2004 - 16:09 | Informe spam
Gracias... le hechare un vistazo!!!


Un saludo
Rodrigo Corral González [MVP]

FAQ de microsoft.public.es.vc++
http://rcorral.mvps.org
Respuesta Responder a este mensaje
#13 nadura
16/09/2004 - 18:26 | Informe spam
Hola a Todos.
Os agradezco enormemente vuestra colaboración por la
consulta que lanze el grupo de noticias, nunca pense que
despertase tanta inventiva por vuestra parte.

He estado observando vuestras aclaraciones y sugerencias
con mucha atención, y he encontrado algo de luz en esta
incidencia tan complicada...

Realmente he estudiado con profundidad vuestras
sugerencias y posibilidades para evitar la creación de
registros con ID duplicado y he pensado en plantear las
siguiente situación, a ver que os parece (quiero una
critica constructiva):

Caso planteado:
En el caso expuesto, utilizo mediante ADO acceso a la
misma por dos puestos Clientes,Si los usuarios de estos
dos puestos pretenden crear un nuevo registro de Cliente
al mismo tiempo (Planteo el peor de los casos)podrían
ocasionarse problemas de duplicación de registro y por
tanto error en la signación del campo que es clave
principal.

Por ello, para evitarlo, si uno de los usuarios logra
acceder a la tabla de forma exclusiva, realiza un bloqueo
de la misma al otro usuario, recuperando el número de
registro a utilizar para el nuevo cliente, mientras tanto
el otro usuario quedará a la espera de acceder a la tabla
mostrando un mensaje de acceso a la Base de datos
servidor de escasos milisegundos; una vez recuperao el
número de registro por el otro usuario, éste desbloqueará
seguidamente dicha Tabla, para que otro usuario que
estaba en espera pueda
acceder a ella. Por tanto el bloqueo de dicha tabla es
mínimo, evitando así esperas excesivas en el acceso a la
misma, evitando así la duplicación del ID.

En este sentido, en la base de Datos servidor se podría
tener una tabla de bloqueo para saber que registros está
manipulando cada usuario en la misma, si los está
consultando, modificando, creando o eliminando...evitando
así bloqueos innecesarios según la situación.

Ejemplo: dos usuarios distintos pretenden crear al mismo
tiempo dos clientes diferentes, y planteamos también la
situación que uno de los compañeros citaba: el
responsable de ventas quiere obtener un listado con los
clientes que alcanzan un mayor volumen de negocio; en
este caso expuesto, tres usuarios diferentes intentarán
acceder de manera simultánea a la base de datos para
obtener la información crítica necesaria para cada uno de
ellos.

Planteamiento: la bloquear la Tabla de clientes, sólo uno
de ellos accederá con éxito a la Tabla de la base de
Datos servidor, Se produce el bloqueo exclusivo, los
otros dos quedan a la espera,El administrador del sistema
lanza a estos dos usuarios un mensaje de conexión a la
base de datos servidor, mientras tanto.
Una vez que este usuario obtiene su número de ID de
cliente, está en situación de desbloquear dicha tabla y
permitir el acceso a otro de ellos.

En esta situación, y centrandonós en el usuario que ha
obtenido el nuevo ID de cliente, tendrán todo el tiempo
que necesite para introducir los datos en la ficha del
Cliente, que una vez introducidos en el formulario se
agregarán a la tabla anteriormente consultada, al mismo
tiempo su número de ID quedará reflejado en la tabla de
bloqueo de la Base de datos servidor para consultas de
otros usuarios que pretendan crear un nuevo cliente,
siendo eliminado una vez creado.

Volvamos al caso de los otros dos, si uno de ellos (caso
del otro usuario que pretende dar de alta), En este
sentido accederá a la tabla de bloqueo con acceso
exclusivo y no a la tabla de clientes (con lo cual
descargamos el bloqueo de ésta), comprobando si algún
otro usuario está dando de alta a Clientes, si esto es
así el ID para este será el consecutivo al mayor
indicado, claro, si es que hay más de uno, sino es así,
entonces accederemos a la tabla de clientes en modo
exclusivo y procederemos de la misma manera descrita
anteriormente, con lo cual, el bloqueo en la tabla de
clientes será mínimo (obteniendo el ID y añadiendolo a la
tabla de bloqueo).

Si nos centramos, en la creación del usuario, una vez
introducidos todos los datos del cliente, se procederá a
anular su registro en la tabla de bloqueo de manera
definitiva.evitando así duplicaciones de ID.

Posteriormente podríamos llevar en una tabla de Registros
eliminados, los números de ID de Clientes previamente
asignados y que posteriormente no han llegado a ser dados
de alta, el usuario que rellena la ficha del cliente
decide un crearlo después de obtener el ID, consultandola
antes de crear un nuevo cliente de manera exclusiva...

Ejemplo:

Usuario 01: obtiene el ID 05 Lo crea con exito
Usuario 02: Obtiene el ID 06 Descarta su creación.
Usuario 03: Obtiene el ID 07 Lo crea con exito
Usuario 04: Obtiene el ID 08 No es correcto / sería el
06, que fue descartado por el usuario 02.

¿De esta manera no desplazamos la carga de acceso y
liberamos de bloqueos innecesarios la Tabla de Clientes,
para las consultas ó modificaciones que otros usuarios
pretendan realizar?

¿Cómo inconveniente, número considerable de
comprobaciones?
Lo veis factible y eficaz
Quedo a la espera de vuestras consideraciones.
un saludo a todos...














Gracias... le hechare un vistazo!!!


Un saludo
Rodrigo Corral González [MVP]

FAQ de microsoft.public.es.vc++
http://rcorral.mvps.org


.

Respuesta Responder a este mensaje
#14 Maxi
16/09/2004 - 23:08 | Informe spam
Hola, mira yo uso el ejemplo que marque en el articulo que publique en MS, y
nunca vas a tener valores duplicados porque hay un bloqueo a nivel registro
con el UPDATE y todo esto al estar dentro de una transaccion funciona muy
bien :-)

Lo tengo implementado en todas mis aplicacion y nunca un problema :-D,
ademas de ser algo muy simple y configurable por disponer de una tabla para
configurar los valores, por ej mis Ordenes de Compra tienen un Prefijo "OC"
y luego el numero correlativo, con el ejemplo del articulo lo pude lograr
perfectamente :-D

Un abrazo


Salu2
Maxi
Buenos Aires - Argentina
Desarrollador Microsoft 3 Estrellas .NET
Nunca consideres el estudio como una obligación sino como
una oportunidad para penetrar en el bello y maravillosos
mundo del saber.
- Albert Einstein



"" escribió en el
mensaje news:171b01c49c09$f7baa6e0$
Hola a Todos.
Os agradezco enormemente vuestra colaboración por la
consulta que lanze el grupo de noticias, nunca pense que
despertase tanta inventiva por vuestra parte.

He estado observando vuestras aclaraciones y sugerencias
con mucha atención, y he encontrado algo de luz en esta
incidencia tan complicada...

Realmente he estudiado con profundidad vuestras
sugerencias y posibilidades para evitar la creación de
registros con ID duplicado y he pensado en plantear las
siguiente situación, a ver que os parece (quiero una
critica constructiva):

Caso planteado:
En el caso expuesto, utilizo mediante ADO acceso a la
misma por dos puestos Clientes,Si los usuarios de estos
dos puestos pretenden crear un nuevo registro de Cliente
al mismo tiempo (Planteo el peor de los casos)podrían
ocasionarse problemas de duplicación de registro y por
tanto error en la signación del campo que es clave
principal.

Por ello, para evitarlo, si uno de los usuarios logra
acceder a la tabla de forma exclusiva, realiza un bloqueo
de la misma al otro usuario, recuperando el número de
registro a utilizar para el nuevo cliente, mientras tanto
el otro usuario quedará a la espera de acceder a la tabla
mostrando un mensaje de acceso a la Base de datos
servidor de escasos milisegundos; una vez recuperao el
número de registro por el otro usuario, éste desbloqueará
seguidamente dicha Tabla, para que otro usuario que
estaba en espera pueda
acceder a ella. Por tanto el bloqueo de dicha tabla es
mínimo, evitando así esperas excesivas en el acceso a la
misma, evitando así la duplicación del ID.

En este sentido, en la base de Datos servidor se podría
tener una tabla de bloqueo para saber que registros está
manipulando cada usuario en la misma, si los está
consultando, modificando, creando o eliminando...evitando
así bloqueos innecesarios según la situación.

Ejemplo: dos usuarios distintos pretenden crear al mismo
tiempo dos clientes diferentes, y planteamos también la
situación que uno de los compañeros citaba: el
responsable de ventas quiere obtener un listado con los
clientes que alcanzan un mayor volumen de negocio; en
este caso expuesto, tres usuarios diferentes intentarán
acceder de manera simultánea a la base de datos para
obtener la información crítica necesaria para cada uno de
ellos.

Planteamiento: la bloquear la Tabla de clientes, sólo uno
de ellos accederá con éxito a la Tabla de la base de
Datos servidor, Se produce el bloqueo exclusivo, los
otros dos quedan a la espera,El administrador del sistema
lanza a estos dos usuarios un mensaje de conexión a la
base de datos servidor, mientras tanto.
Una vez que este usuario obtiene su número de ID de
cliente, está en situación de desbloquear dicha tabla y
permitir el acceso a otro de ellos.

En esta situación, y centrandonós en el usuario que ha
obtenido el nuevo ID de cliente, tendrán todo el tiempo
que necesite para introducir los datos en la ficha del
Cliente, que una vez introducidos en el formulario se
agregarán a la tabla anteriormente consultada, al mismo
tiempo su número de ID quedará reflejado en la tabla de
bloqueo de la Base de datos servidor para consultas de
otros usuarios que pretendan crear un nuevo cliente,
siendo eliminado una vez creado.

Volvamos al caso de los otros dos, si uno de ellos (caso
del otro usuario que pretende dar de alta), En este
sentido accederá a la tabla de bloqueo con acceso
exclusivo y no a la tabla de clientes (con lo cual
descargamos el bloqueo de ésta), comprobando si algún
otro usuario está dando de alta a Clientes, si esto es
así el ID para este será el consecutivo al mayor
indicado, claro, si es que hay más de uno, sino es así,
entonces accederemos a la tabla de clientes en modo
exclusivo y procederemos de la misma manera descrita
anteriormente, con lo cual, el bloqueo en la tabla de
clientes será mínimo (obteniendo el ID y añadiendolo a la
tabla de bloqueo).

Si nos centramos, en la creación del usuario, una vez
introducidos todos los datos del cliente, se procederá a
anular su registro en la tabla de bloqueo de manera
definitiva.evitando así duplicaciones de ID.

Posteriormente podríamos llevar en una tabla de Registros
eliminados, los números de ID de Clientes previamente
asignados y que posteriormente no han llegado a ser dados
de alta, el usuario que rellena la ficha del cliente
decide un crearlo después de obtener el ID, consultandola
antes de crear un nuevo cliente de manera exclusiva...

Ejemplo:

Usuario 01: obtiene el ID 05 Lo crea con exito
Usuario 02: Obtiene el ID 06 Descarta su creación.
Usuario 03: Obtiene el ID 07 Lo crea con exito
Usuario 04: Obtiene el ID 08 No es correcto / sería el
06, que fue descartado por el usuario 02.

¿De esta manera no desplazamos la carga de acceso y
liberamos de bloqueos innecesarios la Tabla de Clientes,
para las consultas ó modificaciones que otros usuarios
pretendan realizar?

¿Cómo inconveniente, número considerable de
comprobaciones?
Lo veis factible y eficaz
Quedo a la espera de vuestras consideraciones.
un saludo a todos...














Gracias... le hechare un vistazo!!!


Un saludo
Rodrigo Corral González [MVP]

FAQ de microsoft.public.es.vc++
http://rcorral.mvps.org


.






Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.764 / Virus Database: 511 - Release Date: 15/09/2004
Respuesta Responder a este mensaje
#15 nadura
17/09/2004 - 01:01 | Informe spam
Contestación a Maximiliano D. Accotto:
He estado observado tu reporte, parece fácil, sencillo y
práctico..., pero debo implementarlo con ADO para acceder
desde una base de Datos mdb a la Base de datos SQL Server
(archivo adp), ¿esta alternativa la podría incluir
utilizando esta misma filosofía?...













Hola, perdon no, pero yo escribi hace poco un patron de


esto que esta
publicado en:

http://www.microsoft.com/spanish/ms...mtj.net/vo


ices/art187.asp

Quizas te sea util


Salu2
-


-
Maxi
Buenos Aires - Argentina
Desarrollador Microsoft 3 Estrellas .NET
-


-
Nunca consideres el estudio como una obligación sino como
una oportunidad para penetrar en el bello y maravillosos
mundo del saber.
- Albert Einstein



"Rodrigo Corral [MVP]" escribió


en el mensaje
news:
Interesante lo del articulo. Un patrón para obtener




codigos unicos que no
sean identity es algo que seria muy util. Son tipicas




las tablas de
secuencias de codigos.

Podrias orientarlo exponiendo las soluciones habituales




y erroneas que
solo
funcionan con muy baja concurrencia y luego proponer la




buena solución. En
cuanto lo tengas mandamelo!!!

Y ya por pedir si lo orientas tanto TSQL como a ADO




perfecto!!!

Si necesitas mi colaboración en algo, algun ejemplo de




código o lo que sea
me dices...


Un saludo
Rodrigo Corral González [MVP]

FAQ de microsoft.public.es.vc++
http://rcorral.mvps.org








Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.748 / Virus Database: 500 - Release Date:


01/09/2004


.

Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida