SP: no funciona cuando la diferencia de la insercion de datos es de msegs??

[mary*]

Hola a todos!!!...nuevamente por aquí solicitando su ayuda.

Tengo el siguiente SP:

Código:

create procedure dbo.spa_bdr_dato
     @CODEOUT VARCHAR(10) OUTPUT,
     @DIGITOUT VARCHAR(10) OUTPUT
as
SELECT TOP 1 
       @CODEOUT = CODE
      ,@DIGITOUT = TYPE
FROM   dbo.BDR
WHERE  (CODE > '0') 
ORDER BY 
       ID DESC

GO

Primero lo tenía condicionado con la Fecha...para que siempre me mostrara el ultimo dato insertado...pero resulta que dichos datos ingresan de 2 escaneres...y el problema es que en ocasiones la diferencia de insert entre uno y otro es de milisegundos...y para el SQL tienen el mismo rango de tiempo (ya que el formato es de hh:mm:ss)...por ejemplo:

ID---CODE-------DIGITO-----------FECHA

1 --- ABC23 ------ 4 -------- 04/04/2007 14:23:45 ---- (fecha real del insert 04/04/2007 14:23:45:24)
2 --- FG456 ------ 8 -------- 04/04/2007 14:23:45 ---- (fecha real del insert 04/04/2007 14:23:45:49)


Por lo tanto cuando esto sucede se perdía un dato...por lo tanto cambie la condición al ID...como se muestra en el SP que puse...pero resulta que de todas formas sucede lo mismo...esto lo corroboré insertando los datos que va generando el SP en otra tabla y al compararlas se muestra que sigo teniendo el mismo problema...como puedo solucionarlo???...por que estoy teniendo este problema???...existe alguna manera de modificar el formato de fecha y hra en el SQL??...les agradezco cualquier ayuda que me puedan dar!!!

[mary*]

Hola!!!...esperaba que alguien pudiera ayudarme...por lo menos alguien me podría decir si el SQL tiene la capacidad de capturar datos en milisegundos y tiene la capacidad para generar SP's en tiempos tan pequeños (milisegundos)???

[Mithrandir]

Si seleccionas el ultimo ID tendrás el último registro insertado (asumiendo que es un Identity).

El asunto de los ms se debe a que los datos no se escriben físicamente en el momento, sino un breve tiempo después. Cuando se hace el "flush" al archivo es cuando ves que muchas fechas coinciden a ese nivel pues en realidad se grabaron en el mismo momento.

[mary*]

Mithrandir!!!...gracias por responderme...efectivamente es un Identidy el ID...por lo tanto creo que coincides conmigo de que con el SP que anoté arriba logro obtener el ultimo dato insertado...pero te comento que por alguna razon esto está fallando...ya que cuando 2 datos conciden en el tiempo de insert solo me registra uno...por lo tanto siempre pierdo uin dato al darse ese caso...como podría garantizar no perder datos??...quiza si condicionara que se haga el query cada vez que el ID cambie...como se podría hacer esto?...espero me puedan ayudar!!!

[Mithrandir]

Pero no entiendo por qué dices que pierdes un dato. ¿El registro no se inserta?

TOP 1 te mostrará solamente un registro, incluso aunque los últimos dos registros se hayan insertado justamente en el mismo momento (comparten la fecha hasta el nivel de los ms), mostrará el que haya obtenido el último ID en la tabla.

¿En el problema de la inserción has probado utilizando transacciones?

[Mithrandir]

Ahora que vi tu otro mensaje...

Revisa que valor tienes para SET TRANSACTION ISOLATION LEVEL en tu conexión de la aplicación.

De cualquier forma, prueba los insert cambiando entre los diferentes valores de esta propiedad.

[mary*]

Hola Mithrandir!!!...te agradezco mucho los comentarios que me haces...fijate que efectivamente en el otro post estoy pretendiendo darle una posible solución a este problema...como te había comentado el SP me arroja unos datos que debo enviar a otro proceso, lo cual lo hacía fácilmente con el procedimiento que describo aqui, el problema es que cuando los datos llegan muy juntos se está perdiendo uno, y aunque lo estoy manejando con el ID sigo teniendo ese problema...

Código:

Pero no entiendo por qué dices que pierdes un dato. ¿El registro no se inserta?

TOP 1 te mostrará solamente un registro, incluso aunque los últimos dos registros se hayan insertado justamente en el mismo momento (comparten la fecha hasta el nivel de los ms), mostrará el que haya obtenido el último ID en la tabla.

¿En el problema de la inserción has probado utilizando transacciones?

Con respecto a tu comentario...así es uno de los 2 registros que comparte la misma fecha pero no el ID no se filtra y cuando corroboro con una inserción no se inserta...

Código:

Revisa que valor tienes para SET TRANSACTION ISOLATION LEVEL en tu conexión de la aplicación.

De cualquier forma, prueba los insert cambiando entre los diferentes valores de esta propiedad.

Con respecto a que si no he utilizado transacciones...fijate que no...y no sé a que te refieres con ello...como te comentaba no soy una experta y quizá algo tan sencillo podría ayudarme a solucionar mi problema...

Ojalá me puedas orientar como manejar lo de las transacciones...te lo agradecería muchísimo!!!!

[mary*]

Como te comentaba este SP es el que tengo funcionando, como veras me filtra siempre el ultimo dato que ingresa a mi tabla y los valores que me arroja los envio a otra aplicacion, es por ello que utilizo las variables de salida:

Código:

create procedure dbo.spa_bal_filtro
     @CODEOUT CHAR(10) OUTPUT,
     @DIGITOUT CHAR(10) OUTPUT
as
BEGIN
SELECT TOP 1 
       @CODEOUT = CODE,
       @DIGITOUT = DIGITO
FROM   dbo.BDORAS
WHERE  (ID > '0') 
ORDER BY 
       ID DESC
END

GO

Como te mencionada si funciona y siempre me filtra el ultimo dato en ingresar excepto cuando comparten la misma fecha ya que solo me filtra uno de los 2 datos ingresados...se supone que esto no debería pasar ya que el ID siempre va a cambiar...

y para comprobarlo complementé el SP anterior:

Código:

create procedure dbo.spa_bal_filtro2
     @CODEOUT CHAR(10) OUTPUT,
     @CODEOUT CHAR(10) OUTPUT
as
BEGIN
SELECT TOP 1 
       @CODEOUT = CODE,
       @DIGITOUT = DIGITO
FROM   dbo.BDORAS
WHERE  (ID > '0') 
ORDER BY 
       ID DESC
END

INSERT INTO BDR (CODE, DIGITO) VALUES (@CODEOUT, @DIGITOUT)

GO

El cual al momento de realizar el filtro inserta los datos en otra tabla, y ahí puedo comprobar que en el caso en el que comparten la misma fecha se pierde un dato, ya que no coincide mi tabla1 con mi tabla2...no sé si tenga que ver el hecho de que ingresan practicamente al mismo tiempo...

me comentas que utilice transacciones...como podría implementarlas en mi SP o modificar el parámetro que me comentas??

[Mithrandir]

Creo que empiezo a entender tu problema. El dato se inserta sin problema en la tabla origen, pero no encuentras como exportarlo al otro sistema sin que exista el problema que comentas.

Para eso tienes una mejor solución. Crea un trigger en la tabla origen y olvidate del SP, cada que se inserte/actualice/borre un registro tienes el dato de que registros (y sus claves) fueron alterados. En el trigger mete el código de la inserción a la otra tabla y de esa manera tienes controlado que todo registro que entre sea replicado en la otra tabla.

Lee sobre como crear triggers y acá te ayudamos con los problemas.

[mary*]

Es algo así...solo que la inserción de datos a la primer tabla no la controlo yo y no hay manera de modificarla...lo que si debo es enviar los datos de esa tabla a otro proceso...pero estoy teniendo ese problema...es por ello que debo solucionarlo de alguna manera...se supone que no debería tener ese problema con los tiempos...pero como los tengo...por eso es que estoy realizando lo que biene en el otro post...así yo mandaría los datos a la tabla2 y ya no me afectaría el factor tiempo...

alguna sugerencia??

[Mithrandir]

Bien a tiempo mi regreso

¿Que hay de los outer joins? Un outer join de la tabla original sobre la segunda tabla (más un pequeño filtro) te devolverá todos los registros no existentes en la segunda. Ese resultado lo metes en un insert y listo.