Transascciones

Hola Octavio y amigos, un placer leerles,

El problema con lo que está haciendo nuestro amigo es que el select max(x)
+1 suele ser un gran generador de problemas, ya que nada impide a dos o mas
conexiones ejecutar el select max()+1 y encontrar el mismo valor de clave al
mismo tiempo, ni siquiera en el nivel serializable una lectura impediría
otra. lectura ya que lecturas no bloquean lecturas (puedes usar hints para
esto pero dudo mucho que tu aplicación quede muy escalable).

Mi sugerencia para estas cosas es, create una tabla con el nombre de la
tabla y el valor del contador (si necesitas crear series añade la serie como
campo) algo así

Create table Claves (NombreTabla sysname not null primary key, contador int)
(si tu contador es un smallint o un bigint u otro tipo puedes hacer una
tabla para cada tipo diferente, esto no supone grandes problemas por que no
habrán muchas tablas)

Después create dos procedimientosAlmacenados uno puede ser el siguiente (te
lo escribo de memoria así que lo más normal es que no funcione, pero será
facil de corregir), observa que no le he puesto control de errores, te lo
dejo a que lo perfeccciones

Create Proc ObtenerId(@tabla sysname,@contador int output)
as
begin
begin tran
update Claves set @contador=contador=contador+1 where NombreTabla=@Tabla
if @@rowcount=0 /* no existía el registro, hay que insentarlo)
begin
insert into Claves (NombreTabla, Contador) values (@tabla,1)
set @contador=1
end
commit tran
return 0
end

El otro procedimiento almacenado debería recibir un parámetro más que sea
cuantas claves quieres obtener por si necesitas hacer inserciones masivas,
no entro en detalles, igual si os hace falta puedo escribirlo y publicarlo
en PortalSQL.com

¿que beneficios obtienes con esto frente al select max?

Primero el update genera un bloqueo, ese bloqueo impide que dos conexiones
obtengan el mismo ID, es decir resultará beneficioso.
Segundo evitas un select max(), que dependiendo de tu indexacion y el número
de registros puede ser una tarea bastante costosa.
Tercero creas un método estandar para todas las tablas de obtener una nueva
clave primaria.

Hay más mecanismos, este es el "pesismista", en un mecanismo optimistas
puedes usar algo parecido al select max (no el select max en mi opinión), y
recuperarte del error por clave duplicada, quizá sea un poco más escalable,
pero hasta donde llega mi experiencia este método funciona bastante bien y
supone menor esfuerzo de programación.

Saludos
Miguel Egea
SQL Server MVP



"Octavio Hernandez" wrote in message
news:

Hola,

Por cierto, cómo puedo bloquear específicamente un registro de una tabla
y
no la tabla completa ?

Me parece recordar que la cláusula HOLDLOCK de SQL Server permite lograr
eso:


http://msdn.microsoft.com/library/d...z_4ox9.asp

Pruébalo, no estoy seguro de eso...

Slds - Octavio

"solusoft" escribió en el mensaje
news:

Gracias, el problema era que se utilizaba otra conexión para obtener el
siguiente código (el select max() + 1) y claro, si había iniciado la
transacción con otra conexión, pues ahí estaban los problemas.


Por cierto, cómo puedo bloquear específicamente un registro de una tabla
y
no la tabla completa ?

Saludos


"Octavio Hernandez" escribió:

Hola,

El valor por defecto normalmente es ReadCommitted, como en el proveedor
de
SQL Server:


http://www.syncfusion.com/library/c...ltopic.htm

¿Puedes aportar el fragmento de código para ver exactamente qué estás
tratando de hacer?

Slds - Octavio

"solusoft" escribió en el mensaje
news:
> Hola a todos,
>
> una pregunta, creoq ue se puede especificar el tipo de bloqueo en las
> transacciones de .NET, pero c uál es el valor por defecto ?.
>
> Estaba utilizando transascciones, y me bloquea la tabla para lectura y
> no
> puedo insertar más de un registro por tabla.
> Ya que tengo que insertar varios registros en una tabla y al hacer la
> consulta del código para el siguiente registro (select max() + 1), me
> genera
> un error.
>
> Si no se puede, tengo que pensar en otra forma de hacerlo.
> Pero tiene que haber una manera, porque no puede ser que bloquee toda
> la
> tabla en modo lectura también, a no ser que sea una aplicación que
> requiera
> ese nivel tan alto de protección. En la mayoría de los casos, lo
> lógico es
> que bloquee solamente los registros afectados por la transaccion para
> cualquier modificación o inserción.
>
> Saludos cordiales.
>
>
>
>
>

¡Hola, Miguel!

Es un placer encontrarte por aquí, genial tu explicación!

Slds - Octavio

"Miguel Egea" escribió en el mensaje
news:

Hola Octavio y amigos, un placer leerles,

El problema con lo que está haciendo nuestro amigo es que el select max(x)
+1 suele ser un gran generador de problemas, ya que nada impide a dos o
mas conexiones ejecutar el select max()+1 y encontrar el mismo valor de
clave al mismo tiempo, ni siquiera en el nivel serializable una lectura
impediría otra. lectura ya que lecturas no bloquean lecturas (puedes usar
hints para esto pero dudo mucho que tu aplicación quede muy escalable).

Mi sugerencia para estas cosas es, create una tabla con el nombre de la
tabla y el valor del contador (si necesitas crear series añade la serie
como campo) algo así

Create table Claves (NombreTabla sysname not null primary key, contador
int) (si tu contador es un smallint o un bigint u otro tipo puedes hacer
una tabla para cada tipo diferente, esto no supone grandes problemas por
que no habrán muchas tablas)

Después create dos procedimientosAlmacenados uno puede ser el siguiente
(te lo escribo de memoria así que lo más normal es que no funcione, pero
será facil de corregir), observa que no le he puesto control de errores,
te lo dejo a que lo perfeccciones

Create Proc ObtenerId(@tabla sysname,@contador int output)
as
begin
begin tran
update Claves set @contador=contador=contador+1 where
NombreTabla=@Tabla
if @@rowcount=0 /* no existía el registro, hay que insentarlo)
begin
insert into Claves (NombreTabla, Contador) values (@tabla,1)
set @contador=1
end
commit tran
return 0
end

El otro procedimiento almacenado debería recibir un parámetro más que sea
cuantas claves quieres obtener por si necesitas hacer inserciones masivas,
no entro en detalles, igual si os hace falta puedo escribirlo y publicarlo
en PortalSQL.com

¿que beneficios obtienes con esto frente al select max?

Primero el update genera un bloqueo, ese bloqueo impide que dos conexiones
obtengan el mismo ID, es decir resultará beneficioso.
Segundo evitas un select max(), que dependiendo de tu indexacion y el
número de registros puede ser una tarea bastante costosa.
Tercero creas un método estandar para todas las tablas de obtener una
nueva clave primaria.

Hay más mecanismos, este es el "pesismista", en un mecanismo optimistas
puedes usar algo parecido al select max (no el select max en mi opinión),
y recuperarte del error por clave duplicada, quizá sea un poco más
escalable, pero hasta donde llega mi experiencia este método funciona
bastante bien y supone menor esfuerzo de programación.

Saludos
Miguel Egea
SQL Server MVP



"Octavio Hernandez" wrote in message
news:

Hola,

Por cierto, cómo puedo bloquear específicamente un registro de una tabla
y
no la tabla completa ?

Me parece recordar que la cláusula HOLDLOCK de SQL Server permite lograr
eso:


http://msdn.microsoft.com/library/d...z_4ox9.asp

Pruébalo, no estoy seguro de eso...

Slds - Octavio

"solusoft" escribió en el mensaje
news:

Gracias, el problema era que se utilizaba otra conexión para obtener el
siguiente código (el select max() + 1) y claro, si había iniciado la
transacción con otra conexión, pues ahí estaban los problemas.


Por cierto, cómo puedo bloquear específicamente un registro de una tabla
y
no la tabla completa ?

Saludos


"Octavio Hernandez" escribió:

Hola,

El valor por defecto normalmente es ReadCommitted, como en el proveedor
de
SQL Server:


http://www.syncfusion.com/library/c...ltopic.htm

¿Puedes aportar el fragmento de código para ver exactamente qué estás
tratando de hacer?

Slds - Octavio

"solusoft" escribió en el mensaje
news:
> Hola a todos,
>
> una pregunta, creoq ue se puede especificar el tipo de bloqueo en las
> transacciones de .NET, pero c uál es el valor por defecto ?.
>
> Estaba utilizando transascciones, y me bloquea la tabla para lectura
> y no
> puedo insertar más de un registro por tabla.
> Ya que tengo que insertar varios registros en una tabla y al hacer la
> consulta del código para el siguiente registro (select max() + 1), me
> genera
> un error.
>
> Si no se puede, tengo que pensar en otra forma de hacerlo.
> Pero tiene que haber una manera, porque no puede ser que bloquee toda
> la
> tabla en modo lectura también, a no ser que sea una aplicación que
> requiera
> ese nivel tan alto de protección. En la mayoría de los casos, lo
> lógico es
> que bloquee solamente los registros afectados por la transaccion para
> cualquier modificación o inserción.
>
> Saludos cordiales.
>
>
>
>
>

Hola Miguel,

¡muy buena explicación!, pero sólo me queda una duda con respecto al método
optimista que comentas al final, y es ¿qué? utilizar en lugar del select
max. Tengo claro que te refieres a un método de reintento mediante detección
de clave duplicada, pero me quedo ahí.
Un Saludo,

Miguel Angel Campos
MCAD.NET

"Miguel Egea" escribió en el mensaje
news:

Hola Octavio y amigos, un placer leerles,

El problema con lo que está haciendo nuestro amigo es que el select max(x)
+1 suele ser un gran generador de problemas, ya que nada impide a dos o
mas conexiones ejecutar el select max()+1 y encontrar el mismo valor de
clave al mismo tiempo, ni siquiera en el nivel serializable una lectura
impediría otra. lectura ya que lecturas no bloquean lecturas (puedes usar
hints para esto pero dudo mucho que tu aplicación quede muy escalable).

Mi sugerencia para estas cosas es, create una tabla con el nombre de la
tabla y el valor del contador (si necesitas crear series añade la serie
como campo) algo así

Create table Claves (NombreTabla sysname not null primary key, contador
int) (si tu contador es un smallint o un bigint u otro tipo puedes hacer
una tabla para cada tipo diferente, esto no supone grandes problemas por
que no habrán muchas tablas)

Después create dos procedimientosAlmacenados uno puede ser el siguiente
(te lo escribo de memoria así que lo más normal es que no funcione, pero
será facil de corregir), observa que no le he puesto control de errores,
te lo dejo a que lo perfeccciones

Create Proc ObtenerId(@tabla sysname,@contador int output)
as
begin
begin tran
update Claves set @contador=contador=contador+1 where
NombreTabla=@Tabla
if @@rowcount=0 /* no existía el registro, hay que insentarlo)
begin
insert into Claves (NombreTabla, Contador) values (@tabla,1)
set @contador=1
end
commit tran
return 0
end

El otro procedimiento almacenado debería recibir un parámetro más que sea
cuantas claves quieres obtener por si necesitas hacer inserciones masivas,
no entro en detalles, igual si os hace falta puedo escribirlo y publicarlo
en PortalSQL.com

¿que beneficios obtienes con esto frente al select max?

Primero el update genera un bloqueo, ese bloqueo impide que dos conexiones
obtengan el mismo ID, es decir resultará beneficioso.
Segundo evitas un select max(), que dependiendo de tu indexacion y el
número de registros puede ser una tarea bastante costosa.
Tercero creas un método estandar para todas las tablas de obtener una
nueva clave primaria.

Hay más mecanismos, este es el "pesismista", en un mecanismo optimistas
puedes usar algo parecido al select max (no el select max en mi opinión),
y recuperarte del error por clave duplicada, quizá sea un poco más
escalable, pero hasta donde llega mi experiencia este método funciona
bastante bien y supone menor esfuerzo de programación.

Saludos
Miguel Egea
SQL Server MVP



"Octavio Hernandez" wrote in message
news:

Hola,

Por cierto, cómo puedo bloquear específicamente un registro de una tabla
y
no la tabla completa ?

Me parece recordar que la cláusula HOLDLOCK de SQL Server permite lograr
eso:


http://msdn.microsoft.com/library/d...z_4ox9.asp

Pruébalo, no estoy seguro de eso...

Slds - Octavio

"solusoft" escribió en el mensaje
news:

Gracias, el problema era que se utilizaba otra conexión para obtener el
siguiente código (el select max() + 1) y claro, si había iniciado la
transacción con otra conexión, pues ahí estaban los problemas.


Por cierto, cómo puedo bloquear específicamente un registro de una tabla
y
no la tabla completa ?

Saludos


"Octavio Hernandez" escribió:

Hola,

El valor por defecto normalmente es ReadCommitted, como en el proveedor
de
SQL Server:


http://www.syncfusion.com/library/c...ltopic.htm

¿Puedes aportar el fragmento de código para ver exactamente qué estás
tratando de hacer?

Slds - Octavio

"solusoft" escribió en el mensaje
news:
> Hola a todos,
>
> una pregunta, creoq ue se puede especificar el tipo de bloqueo en las
> transacciones de .NET, pero c uál es el valor por defecto ?.
>
> Estaba utilizando transascciones, y me bloquea la tabla para lectura
> y no
> puedo insertar más de un registro por tabla.
> Ya que tengo que insertar varios registros en una tabla y al hacer la
> consulta del código para el siguiente registro (select max() + 1), me
> genera
> un error.
>
> Si no se puede, tengo que pensar en otra forma de hacerlo.
> Pero tiene que haber una manera, porque no puede ser que bloquee toda
> la
> tabla en modo lectura también, a no ser que sea una aplicación que
> requiera
> ese nivel tan alto de protección. En la mayoría de los casos, lo
> lógico es
> que bloquee solamente los registros afectados por la transaccion para
> cualquier modificación o inserción.
>
> Saludos cordiales.
>
>
>
>
>

Me refiero a utilizar identitys por ejemplo, o utilizar select top 1 order
by ese campo desc y tener un índice descendente en ese campo, es decir
operaciones que ayuden al motor de base de datos a encontrar más rápidamente
el vlaor en cuestión y con menos sobrecarga.

Espero que ayude.

Saludos
Miguel Egea
"Miguel Angel Campos" <SPAMmacampos ARRUBA .idesarrollaSPAM.com> wrote in
message news:%

Hola Miguel,

¡muy buena explicación!, pero sólo me queda una duda con respecto al
método optimista que comentas al final, y es ¿qué? utilizar en lugar del
select max. Tengo claro que te refieres a un método de reintento mediante
detección de clave duplicada, pero me quedo ahí.
Un Saludo,

Miguel Angel Campos
MCAD.NET

"Miguel Egea" escribió en el mensaje
news:

Hola Octavio y amigos, un placer leerles,

El problema con lo que está haciendo nuestro amigo es que el select
max(x) +1 suele ser un gran generador de problemas, ya que nada impide a
dos o mas conexiones ejecutar el select max()+1 y encontrar el mismo
valor de clave al mismo tiempo, ni siquiera en el nivel serializable una
lectura impediría otra. lectura ya que lecturas no bloquean lecturas
(puedes usar hints para esto pero dudo mucho que tu aplicación quede muy
escalable).

Mi sugerencia para estas cosas es, create una tabla con el nombre de la
tabla y el valor del contador (si necesitas crear series añade la serie
como campo) algo así

Create table Claves (NombreTabla sysname not null primary key, contador
int) (si tu contador es un smallint o un bigint u otro tipo puedes hacer
una tabla para cada tipo diferente, esto no supone grandes problemas por
que no habrán muchas tablas)

Después create dos procedimientosAlmacenados uno puede ser el siguiente
(te lo escribo de memoria así que lo más normal es que no funcione, pero
será facil de corregir), observa que no le he puesto control de errores,
te lo dejo a que lo perfeccciones

Create Proc ObtenerId(@tabla sysname,@contador int output)
as
begin
begin tran
update Claves set @contador=contador=contador+1 where
NombreTabla=@Tabla
if @@rowcount=0 /* no existía el registro, hay que insentarlo)
begin
insert into Claves (NombreTabla, Contador) values (@tabla,1)
set @contador=1
end
commit tran
return 0
end

El otro procedimiento almacenado debería recibir un parámetro más que sea
cuantas claves quieres obtener por si necesitas hacer inserciones
masivas, no entro en detalles, igual si os hace falta puedo escribirlo y
publicarlo en PortalSQL.com

¿que beneficios obtienes con esto frente al select max?

Primero el update genera un bloqueo, ese bloqueo impide que dos
conexiones obtengan el mismo ID, es decir resultará beneficioso.
Segundo evitas un select max(), que dependiendo de tu indexacion y el
número de registros puede ser una tarea bastante costosa.
Tercero creas un método estandar para todas las tablas de obtener una
nueva clave primaria.

Hay más mecanismos, este es el "pesismista", en un mecanismo optimistas
puedes usar algo parecido al select max (no el select max en mi opinión),
y recuperarte del error por clave duplicada, quizá sea un poco más
escalable, pero hasta donde llega mi experiencia este método funciona
bastante bien y supone menor esfuerzo de programación.

Saludos
Miguel Egea
SQL Server MVP



"Octavio Hernandez" wrote in message
news:

Hola,

Por cierto, cómo puedo bloquear específicamente un registro de una
tabla y
no la tabla completa ?

Me parece recordar que la cláusula HOLDLOCK de SQL Server permite lograr
eso:


http://msdn.microsoft.com/library/d...z_4ox9.asp

Pruébalo, no estoy seguro de eso...

Slds - Octavio

"solusoft" escribió en el mensaje
news:

Gracias, el problema era que se utilizaba otra conexión para obtener el
siguiente código (el select max() + 1) y claro, si había iniciado la
transacción con otra conexión, pues ahí estaban los problemas.


Por cierto, cómo puedo bloquear específicamente un registro de una
tabla y
no la tabla completa ?

Saludos


"Octavio Hernandez" escribió:

Hola,

El valor por defecto normalmente es ReadCommitted, como en el
proveedor de
SQL Server:


http://www.syncfusion.com/library/c...ltopic.htm

¿Puedes aportar el fragmento de código para ver exactamente qué estás
tratando de hacer?

Slds - Octavio

"solusoft" escribió en el mensaje
news:
> Hola a todos,
>
> una pregunta, creoq ue se puede especificar el tipo de bloqueo en
> las
> transacciones de .NET, pero c uál es el valor por defecto ?.
>
> Estaba utilizando transascciones, y me bloquea la tabla para lectura
> y no
> puedo insertar más de un registro por tabla.
> Ya que tengo que insertar varios registros en una tabla y al hacer
> la
> consulta del código para el siguiente registro (select max() + 1),
> me
> genera
> un error.
>
> Si no se puede, tengo que pensar en otra forma de hacerlo.
> Pero tiene que haber una manera, porque no puede ser que bloquee
> toda la
> tabla en modo lectura también, a no ser que sea una aplicación que
> requiera
> ese nivel tan alto de protección. En la mayoría de los casos, lo
> lógico es
> que bloquee solamente los registros afectados por la transaccion
> para
> cualquier modificación o inserción.
>
> Saludos cordiales.
>
>
>
>
>

:-)

"Octavio Hernandez" wrote in message
news:uAbk%23X$

¡Hola, Miguel!

Es un placer encontrarte por aquí, genial tu explicación!

Slds - Octavio

"Miguel Egea" escribió en el mensaje
news:

Hola Octavio y amigos, un placer leerles,

El problema con lo que está haciendo nuestro amigo es que el select
max(x) +1 suele ser un gran generador de problemas, ya que nada impide a
dos o mas conexiones ejecutar el select max()+1 y encontrar el mismo
valor de clave al mismo tiempo, ni siquiera en el nivel serializable una
lectura impediría otra. lectura ya que lecturas no bloquean lecturas
(puedes usar hints para esto pero dudo mucho que tu aplicación quede muy
escalable).

Mi sugerencia para estas cosas es, create una tabla con el nombre de la
tabla y el valor del contador (si necesitas crear series añade la serie
como campo) algo así

Create table Claves (NombreTabla sysname not null primary key, contador
int) (si tu contador es un smallint o un bigint u otro tipo puedes hacer
una tabla para cada tipo diferente, esto no supone grandes problemas por
que no habrán muchas tablas)

Después create dos procedimientosAlmacenados uno puede ser el siguiente
(te lo escribo de memoria así que lo más normal es que no funcione, pero
será facil de corregir), observa que no le he puesto control de errores,
te lo dejo a que lo perfeccciones

Create Proc ObtenerId(@tabla sysname,@contador int output)
as
begin
begin tran
update Claves set @contador=contador=contador+1 where
NombreTabla=@Tabla
if @@rowcount=0 /* no existía el registro, hay que insentarlo)
begin
insert into Claves (NombreTabla, Contador) values (@tabla,1)
set @contador=1
end
commit tran
return 0
end

El otro procedimiento almacenado debería recibir un parámetro más que sea
cuantas claves quieres obtener por si necesitas hacer inserciones
masivas, no entro en detalles, igual si os hace falta puedo escribirlo y
publicarlo en PortalSQL.com

¿que beneficios obtienes con esto frente al select max?

Primero el update genera un bloqueo, ese bloqueo impide que dos
conexiones obtengan el mismo ID, es decir resultará beneficioso.
Segundo evitas un select max(), que dependiendo de tu indexacion y el
número de registros puede ser una tarea bastante costosa.
Tercero creas un método estandar para todas las tablas de obtener una
nueva clave primaria.

Hay más mecanismos, este es el "pesismista", en un mecanismo optimistas
puedes usar algo parecido al select max (no el select max en mi opinión),
y recuperarte del error por clave duplicada, quizá sea un poco más
escalable, pero hasta donde llega mi experiencia este método funciona
bastante bien y supone menor esfuerzo de programación.

Saludos
Miguel Egea
SQL Server MVP



"Octavio Hernandez" wrote in message
news:

Hola,

Por cierto, cómo puedo bloquear específicamente un registro de una
tabla y
no la tabla completa ?

Me parece recordar que la cláusula HOLDLOCK de SQL Server permite lograr
eso:


http://msdn.microsoft.com/library/d...z_4ox9.asp

Pruébalo, no estoy seguro de eso...

Slds - Octavio

"solusoft" escribió en el mensaje
news:

Gracias, el problema era que se utilizaba otra conexión para obtener el
siguiente código (el select max() + 1) y claro, si había iniciado la
transacción con otra conexión, pues ahí estaban los problemas.


Por cierto, cómo puedo bloquear específicamente un registro de una
tabla y
no la tabla completa ?

Saludos


"Octavio Hernandez" escribió:

Hola,

El valor por defecto normalmente es ReadCommitted, como en el
proveedor de
SQL Server:


http://www.syncfusion.com/library/c...ltopic.htm

¿Puedes aportar el fragmento de código para ver exactamente qué estás
tratando de hacer?

Slds - Octavio

"solusoft" escribió en el mensaje
news:
> Hola a todos,
>
> una pregunta, creoq ue se puede especificar el tipo de bloqueo en
> las
> transacciones de .NET, pero c uál es el valor por defecto ?.
>
> Estaba utilizando transascciones, y me bloquea la tabla para lectura
> y no
> puedo insertar más de un registro por tabla.
> Ya que tengo que insertar varios registros en una tabla y al hacer
> la
> consulta del código para el siguiente registro (select max() + 1),
> me
> genera
> un error.
>
> Si no se puede, tengo que pensar en otra forma de hacerlo.
> Pero tiene que haber una manera, porque no puede ser que bloquee
> toda la
> tabla en modo lectura también, a no ser que sea una aplicación que
> requiera
> ese nivel tan alto de protección. En la mayoría de los casos, lo
> lógico es
> que bloquee solamente los registros afectados por la transaccion
> para
> cualquier modificación o inserción.
>
> Saludos cordiales.
>
>
>
>
>