Nº Pedido

23/08/2006 - 13:47 por Tadeo Giner | Informe spam
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

Preguntas similare

Leer las respuestas

#1 Maxi
23/08/2006 - 14:39 | Informe spam
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


Respuesta Responder a este mensaje
#2 Tadeo Giner
23/08/2006 - 15:26 | Informe spam
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







Respuesta Responder a este mensaje
#3 Leonardo Azpurua [mvp vb]
23/08/2006 - 16:24 | Informe spam
"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



Hola, Tadeo:

"Este señor" es el propio Maxi :-)

El asunto es: quieres que un sistema asigne numeros correlativos en un
entorno concurrente y no quieres usar autonumericos.

La solución no es "crear una tabla" para cada cliente. La solución (y eso ya
es cosa de diseño, es decir de imaginación) es tener una tabla de
contadores, donde almacenas todos los contadores que necesites.

Y escribes algo como:

BEGIN TRANS
UPDATE ContadoresClientes SET ProximoPedido = ProximoPedido + 1 WHERE
Cliente = @elCliente
SET @pp = SELECT ProximoPedido FROM COntadores WHERE Cliente =
@elCliente
INSERT INTO Pedidos (Numero, ...) VALUES (@pp, ...)
COMMIT TRANS

No es "un parche": es la manera correcta de manejar contadores.


Salud!
Respuesta Responder a este mensaje
#4 Tadeo Giner
23/08/2006 - 17:19 | Informe spam
Perdon antes que nada si he ofendido a alguien, pero me parece que aun no me
habeis entendido

La solucion sigue siendo un parche (bajo mi punto de vista por supuesto) y
me explico. Tengo n clientes, cada clientes tiene m usuarios concurrentes,
la numeracion es distinta para cada cliente, es decir que el cliente 1 tiene
10 usuarios concurrentes y la numeracion es unica para cada cliente, asi que
perfectamete puedo tener 10 clientes (en realidad casi 50) trabajando a la
vez

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.

"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:
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



Hola, Tadeo:

"Este señor" es el propio Maxi :-)

El asunto es: quieres que un sistema asigne numeros correlativos en un
entorno concurrente y no quieres usar autonumericos.

La solución no es "crear una tabla" para cada cliente. La solución (y eso
ya es cosa de diseño, es decir de imaginación) es tener una tabla de
contadores, donde almacenas todos los contadores que necesites.

Y escribes algo como:

BEGIN TRANS
UPDATE ContadoresClientes SET ProximoPedido = ProximoPedido + 1 WHERE
Cliente = @elCliente
SET @pp = SELECT ProximoPedido FROM COntadores WHERE Cliente =
@elCliente
INSERT INTO Pedidos (Numero, ...) VALUES (@pp, ...)
COMMIT TRANS

No es "un parche": es la manera correcta de manejar contadores.


Salud!



Respuesta Responder a este mensaje
#5 Leonardo Azpurua [mvp vb]
23/08/2006 - 17:33 | Informe spam
"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!
Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente Respuesta Tengo una respuesta
Search Busqueda sugerida