Nº Pedido

En ningun momento quiero entablar una discusion que me parece algo estupido,
pero depues de leer lo que me acabas de escribir si empiezo a ver
soluciones.

Creo que ni me habeis leido con detenimiento ni yo a vosotros entre otras
cosas por la rapidez con que funciona esto y la cantidad de consultas que
contestais.

Cuando hablas de una transaccion mas estricta es por donde tengo que ir a
buscar la solucion puesto que lo que necesito es un bloqueo del fichero
completo, no de registros, y este tipo de bloqueo es el que no se hacer, y
repito que no quiero discrepar de la solucion sino que simplemente no es
buena la primera ni la segunda que me habeis ofrecido e intento haceros
hablar (escribir en este caso) porque con lo que me cuentas en este ultimo
mail si empiezas a hablarme de niveles de bloqueo, puesto que el nivel que
necesito es bastante alto puesto que es critico para mi cliente el numero de
pedido por razones que no vienen al caso.

Otra cosa es que me digas que quizas este matando moscas a cañonazos o que
nadie necesita tanta proteccion. Te aseguro que en este caso si se necesita,
y que si fuera una gestion de pedidos normal y corriente de cualquier
empresa no existiria este problema.

y repito la pregunta: (no se si se puede hacer en sqlserver express)

Como hago un bloqueo de fichero?
leo el ultimo numero
le sumo uno
doy de alta el nuevo registro en el mismo fichero
le asigno el nuevo numero
desbloqueo

Gracias y perdon de nuevo por las molestias


"Leonardo Azpurua [mvp vb]" <l e o n a r d o (arroba) m v p s (punto) o r g>
escribió en el mensaje news:

"Tadeo Giner" escribió en el mensaje
news:u%

Si manejo los contadores de esa manera, PUEDO TENER PROBLEMAS, porque la
transaccion no quita que dos usuarios puedan concurrir a la vez. Recuerda
que la transaccion (teoricamente) no bloquea el fichero sino que hace que
todo el codigo se ejecute de una sola pasada y tiene la posibilidad de
vuelta atras si no se completa la ida y la vuelta.

Si me jurais que esta transaccion bloquea el fichero yo hago acto de fe,
y desde luego no hace falta que os diga lo agradecido que estoy por
vuestra ayuda aunque en este caso discrepe de la solucion.

Hola, Tadeo:

Las transacciones sí bloquean los registros modificados. SQL Server acepta
varios tipos de transacciones (Maxi sabe mejor que yo los detalles). El
más "estricto" impide que los usuarios lean los cambios no "confirmados"
(commited).

Esto significa que ningún usuario tendrá acceso al registro modificado
hasta que la transacción se confirme o se revierta.

Lo que se hace un poco fastidioso es esa insistencia en "discrepar de la
solución": o usas autonumericos o usas contadores, no hay mas. Y si usas
contadores dentro de transacciones, puedes estar seguro de que funcionarán
correctamente.

En el peor de los casos, si el indice de los pedido especifica valores
únicos, y aun en el caso de que las transacciones no bloquearan los
registros (que sí los bloquean), tienes la oportunidad de detectar la
clave duplicada y corregir el error.

Salud!

Hola, este modelo que te mostre en mi articulo funciona perfectamente y
jamas tendras 2 numeros iguales porque se esta bloqueando con el UPDATE.
Este patron de numeracion lo uso en todos mis sistemas, algunos de ellos con
mas de 500 usuarios.
Analicemos el codigo y veras que bloquea:

BEGIN TRAN
UPDATE NUMERADORES SET @NUMERO_FACTURA = ULTIMO_VALOR = ULTIMO_VALOR + 1
WHERE TABLA='FACTURAS'
IF @@ERROR <> 0
BEGIN
ROLLBACK TRAN
RETURN
END
INSERT INTO FACTURAS VALUES
(@NUMERO_FACTURA,CONVERT(CHAR(10),@FECHA,112),@IMPORTE)
IF @@ERROR <> 0
BEGIN
ROLLBACK TRAN
RETURN
END
COMMIT TRAN

Si te fijas bien el UPDATE esta dentro de la transaccion con lo cual se esta
generando un bloqueo
mientras dure la transaccion no podra ningun otro usuario tener acceso con
lo cual no obtendra ningun numero, cuando se desbloquea la transaccion entra
en el update el usuario que quedo en cola (es una explicacion simple) Podes
probarlo de una manera muy simple

1=) abri tu Query analizer (2 ventanas)
2) En una copia el codigo y saca el commit (lo cual hara que quede bloqueado
hasta espera un fin)
3) Ahora en la otra ventana (con todo el codigo incluso el commit) ejecuta
(veras que no pasa nada porque hay un bloqueo que impide hacer el update)
4) Anda a la ventana que sacaste el commit y escribi Commit Tran y ejecutalo

Veras que se termino la transaccion y cuando analises la tabla veras 2
registros consecutivos sin problemas.

Te vuelvo a repetir este algotirmo lo uso en miles de lugares y por como
esta pensado no vas a tener duplicados y ademas en tu tabla numeradora poder
poner otras cuestiones mas como por ej Prefijo, sufijo etc.

pd: espero que lo hayas entendido sino decime y te hago una demo


Salu2

Microsoft MVP SQL Server
Culminis Speaker
INETA Speaker

"Tadeo Giner" escribió en el mensaje
news:

Hola Maxi

Creo que la solucion que plantea este señor es un parche, no me parece que
resuelva el problema puesto que tendria que tener una tabla de numeracion
para cada uno de los clientes que tengo

La solucion seria bloquear la tabla mientras se genera el registro, pero
como se hace esto???? si pudiera bloquear y hacer una transaccion el
problema quedaria resuelto, pero no se como se hace en vs2005. Incluso en
red funcionaria sin bloquear por el tema de orden de ejecucion de comandos
en pila, pero en web no soy capaz de contestarte

Gracias de todas formas y muy agradecido por tu ayuda
Tadeo Giner


"Maxi" escribió en el mensaje
news:

Hola mirate este articulo:

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


Salu2

Microsoft MVP SQL Server
Culminis Speaker
INETA Speaker

"Tadeo Giner" escribió en el mensaje
news:

Hola a todos

En una aplicacion que estoy desarrollando tengo que dar de alta un nuevo
pedido que por supuesto va numerado, y me temo que si dos usuarios dan a
la vez un alta tenga problemas con la numeracion de ese pedido, tendria
que bloquear el fichero de pedidos? como se resuelve este caso? uso
v22005 express

No me sirve la solucion de un campo incremental puesto que cada cliente
va a tener su propia numeracion

Gracias

Leo, con el ejemplo del articulo jamas pasara eso, no hay forma de que
existan 2 valores iguales. En el mismo hilo explique porque y como funciona


Salu2

Microsoft MVP SQL Server
Culminis Speaker
INETA Speaker

"Leonardo Azpurua [mvp vb]" <l e o n a r d o (arroba) m v p s (punto) o r g>
escribió en el mensaje news:

"Tadeo Giner" escribió en el mensaje
news:u%

Si manejo los contadores de esa manera, PUEDO TENER PROBLEMAS, porque la
transaccion no quita que dos usuarios puedan concurrir a la vez. Recuerda
que la transaccion (teoricamente) no bloquea el fichero sino que hace que
todo el codigo se ejecute de una sola pasada y tiene la posibilidad de
vuelta atras si no se completa la ida y la vuelta.

Si me jurais que esta transaccion bloquea el fichero yo hago acto de fe,
y desde luego no hace falta que os diga lo agradecido que estoy por
vuestra ayuda aunque en este caso discrepe de la solucion.

Hola, Tadeo:

Las transacciones sí bloquean los registros modificados. SQL Server acepta
varios tipos de transacciones (Maxi sabe mejor que yo los detalles). El
más "estricto" impide que los usuarios lean los cambios no "confirmados"
(commited).

Esto significa que ningún usuario tendrá acceso al registro modificado
hasta que la transacción se confirme o se revierta.

Lo que se hace un poco fastidioso es esa insistencia en "discrepar de la
solución": o usas autonumericos o usas contadores, no hay mas. Y si usas
contadores dentro de transacciones, puedes estar seguro de que funcionarán
correctamente.

En el peor de los casos, si el indice de los pedido especifica valores
únicos, y aun en el caso de que las transacciones no bloquearan los
registros (que sí los bloquean), tienes la oportunidad de detectar la
clave duplicada y corregir el error.

Salud!

Tienes razon, he estado estudiando la web de microsoft, pero solo (bajo mi
punto de vista) en el caso de que pongas el "set transaction isolation level
serializable", y en este caso ya me da igual usar el metodo que tu has
desarrollado de la tabla de contadores (por otra parte muy brillante porque
te permite hacer una pantalla donde puedes ver on-line la situacion de cada
uno de los contadores de una forma muy comoda) que hacerlo directamente
sobre el fichero de pedidos porque no permite hacer ninguna otra transaccion
mientras se este ejecutando la primera. El tema esta entonces en establecer
el nivel de transaccion a serializable y al acabar devolver el nivel de
transacciones a como estaba al principio (que aun no se como estaba
establecido)

Asi que voy a fusilar el texto que me has pasado porque es mucho mas
brillante que el que yo estaba escribiendo y lo adapto al mio (en vez de
facturas ->pedidos, etc)

Por cierto, aunque discrepe he sacado la solucion gracias a vuestra ayuda,
porque solo hubiera sido incapaz

Muchas Gracias y un abrazo
Tadeo Giner

"Maxi" escribió en el mensaje
news:

Hola, este modelo que te mostre en mi articulo funciona perfectamente y
jamas tendras 2 numeros iguales porque se esta bloqueando con el UPDATE.
Este patron de numeracion lo uso en todos mis sistemas, algunos de ellos
con mas de 500 usuarios.
Analicemos el codigo y veras que bloquea:

BEGIN TRAN
UPDATE NUMERADORES SET @NUMERO_FACTURA = ULTIMO_VALOR = ULTIMO_VALOR + 1
WHERE TABLA='FACTURAS'
IF @@ERROR <> 0
BEGIN
ROLLBACK TRAN
RETURN
END
INSERT INTO FACTURAS VALUES
(@NUMERO_FACTURA,CONVERT(CHAR(10),@FECHA,112),@IMPORTE)
IF @@ERROR <> 0
BEGIN
ROLLBACK TRAN
RETURN
END
COMMIT TRAN

Si te fijas bien el UPDATE esta dentro de la transaccion con lo cual se
esta generando un bloqueo
mientras dure la transaccion no podra ningun otro usuario tener acceso con
lo cual no obtendra ningun numero, cuando se desbloquea la transaccion
entra en el update el usuario que quedo en cola (es una explicacion
simple) Podes probarlo de una manera muy simple

1=) abri tu Query analizer (2 ventanas)
2) En una copia el codigo y saca el commit (lo cual hara que quede
bloqueado hasta espera un fin)
3) Ahora en la otra ventana (con todo el codigo incluso el commit) ejecuta
(veras que no pasa nada porque hay un bloqueo que impide hacer el update)
4) Anda a la ventana que sacaste el commit y escribi Commit Tran y
ejecutalo

Veras que se termino la transaccion y cuando analises la tabla veras 2
registros consecutivos sin problemas.

Te vuelvo a repetir este algotirmo lo uso en miles de lugares y por como
esta pensado no vas a tener duplicados y ademas en tu tabla numeradora
poder poner otras cuestiones mas como por ej Prefijo, sufijo etc.

pd: espero que lo hayas entendido sino decime y te hago una demo


Salu2

Microsoft MVP SQL Server
Culminis Speaker
INETA Speaker

"Tadeo Giner" escribió en el mensaje
news:

Hola Maxi

Creo que la solucion que plantea este señor es un parche, no me parece
que resuelva el problema puesto que tendria que tener una tabla de
numeracion para cada uno de los clientes que tengo

La solucion seria bloquear la tabla mientras se genera el registro, pero
como se hace esto???? si pudiera bloquear y hacer una transaccion el
problema quedaria resuelto, pero no se como se hace en vs2005. Incluso en
red funcionaria sin bloquear por el tema de orden de ejecucion de
comandos en pila, pero en web no soy capaz de contestarte

Gracias de todas formas y muy agradecido por tu ayuda
Tadeo Giner


"Maxi" escribió en el mensaje
news:

Hola mirate este articulo:

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


Salu2

Microsoft MVP SQL Server
Culminis Speaker
INETA Speaker

"Tadeo Giner" escribió en el mensaje
news:

Hola a todos

En una aplicacion que estoy desarrollando tengo que dar de alta un
nuevo pedido que por supuesto va numerado, y me temo que si dos
usuarios dan a la vez un alta tenga problemas con la numeracion de ese
pedido, tendria que bloquear el fichero de pedidos? como se resuelve
este caso? uso v22005 express

No me sirve la solucion de un campo incremental puesto que cada cliente
va a tener su propia numeracion

Gracias

Hola, me alegro que te haya sido de utilidad. No es necesario cambiar ningun
tipo de isolation level dejalo como viene por default


Salu2

Microsoft MVP SQL Server
Culminis Speaker
INETA Speaker

"Tadeo Giner" escribió en el mensaje
news:%

Tienes razon, he estado estudiando la web de microsoft, pero solo (bajo mi
punto de vista) en el caso de que pongas el "set transaction isolation
level serializable", y en este caso ya me da igual usar el metodo que tu
has desarrollado de la tabla de contadores (por otra parte muy brillante
porque te permite hacer una pantalla donde puedes ver on-line la situacion
de cada uno de los contadores de una forma muy comoda) que hacerlo
directamente sobre el fichero de pedidos porque no permite hacer ninguna
otra transaccion mientras se este ejecutando la primera. El tema esta
entonces en establecer el nivel de transaccion a serializable y al acabar
devolver el nivel de transacciones a como estaba al principio (que aun no
se como estaba establecido)

Asi que voy a fusilar el texto que me has pasado porque es mucho mas
brillante que el que yo estaba escribiendo y lo adapto al mio (en vez de
facturas ->pedidos, etc)

Por cierto, aunque discrepe he sacado la solucion gracias a vuestra ayuda,
porque solo hubiera sido incapaz

Muchas Gracias y un abrazo
Tadeo Giner

"Maxi" escribió en el mensaje
news:

Hola, este modelo que te mostre en mi articulo funciona perfectamente y
jamas tendras 2 numeros iguales porque se esta bloqueando con el UPDATE.
Este patron de numeracion lo uso en todos mis sistemas, algunos de ellos
con mas de 500 usuarios.
Analicemos el codigo y veras que bloquea:

BEGIN TRAN
UPDATE NUMERADORES SET @NUMERO_FACTURA = ULTIMO_VALOR = ULTIMO_VALOR +
1 WHERE TABLA='FACTURAS'
IF @@ERROR <> 0
BEGIN
ROLLBACK TRAN
RETURN
END
INSERT INTO FACTURAS VALUES
(@NUMERO_FACTURA,CONVERT(CHAR(10),@FECHA,112),@IMPORTE)
IF @@ERROR <> 0
BEGIN
ROLLBACK TRAN
RETURN
END
COMMIT TRAN

Si te fijas bien el UPDATE esta dentro de la transaccion con lo cual se
esta generando un bloqueo
mientras dure la transaccion no podra ningun otro usuario tener acceso
con lo cual no obtendra ningun numero, cuando se desbloquea la
transaccion entra en el update el usuario que quedo en cola (es una
explicacion simple) Podes probarlo de una manera muy simple

1=) abri tu Query analizer (2 ventanas)
2) En una copia el codigo y saca el commit (lo cual hara que quede
bloqueado hasta espera un fin)
3) Ahora en la otra ventana (con todo el codigo incluso el commit)
ejecuta (veras que no pasa nada porque hay un bloqueo que impide hacer el
update)
4) Anda a la ventana que sacaste el commit y escribi Commit Tran y
ejecutalo

Veras que se termino la transaccion y cuando analises la tabla veras 2
registros consecutivos sin problemas.

Te vuelvo a repetir este algotirmo lo uso en miles de lugares y por como
esta pensado no vas a tener duplicados y ademas en tu tabla numeradora
poder poner otras cuestiones mas como por ej Prefijo, sufijo etc.

pd: espero que lo hayas entendido sino decime y te hago una demo


Salu2

Microsoft MVP SQL Server
Culminis Speaker
INETA Speaker

"Tadeo Giner" escribió en el mensaje
news:

Hola Maxi

Creo que la solucion que plantea este señor es un parche, no me parece
que resuelva el problema puesto que tendria que tener una tabla de
numeracion para cada uno de los clientes que tengo

La solucion seria bloquear la tabla mientras se genera el registro, pero
como se hace esto???? si pudiera bloquear y hacer una transaccion el
problema quedaria resuelto, pero no se como se hace en vs2005. Incluso
en red funcionaria sin bloquear por el tema de orden de ejecucion de
comandos en pila, pero en web no soy capaz de contestarte

Gracias de todas formas y muy agradecido por tu ayuda
Tadeo Giner


"Maxi" escribió en el mensaje
news:

Hola mirate este articulo:

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


Salu2

Microsoft MVP SQL Server
Culminis Speaker
INETA Speaker

"Tadeo Giner" escribió en el mensaje
news:

Hola a todos

En una aplicacion que estoy desarrollando tengo que dar de alta un
nuevo pedido que por supuesto va numerado, y me temo que si dos
usuarios dan a la vez un alta tenga problemas con la numeracion de ese
pedido, tendria que bloquear el fichero de pedidos? como se resuelve
este caso? uso v22005 express

No me sirve la solucion de un campo incremental puesto que cada
cliente va a tener su propia numeracion

Gracias