Registro contable cuadrado

09/05/2008 - 14:04 por Guillermo Rojas | Informe spam

Dos tablas de un sistema de contabilidad para registros contables:

regConth (registro contable encabezado)
-
regno int -- pk identity
fecha date
...

regContd (registro contable detalle)

regno int
ctano char(10) --cuenta contable
debito decimal
credito decimal
...

Tengo que hacer que cada registro (regno) este cuadrado: que la suma de los
debitos sea igual a la suma de los creditos. Si no esta no debe aceptarlo.
No veo como poner esta restriccion en SQL Server, si un trigger o check, etc
y en cual de las dos tablas o si tengo que validarlo desde la aplicacion.
Que me podrian decir para orientarme?

Siga el debate

22 respuestas

Tengo una respuesta

Preguntas similare

Mostrar todos los temas similares

Leer las respuestas

#21 Maxi Accotto

15/05/2008 - 17:57 | Informe spam

es cierto, los check no ven los borrados, por eso aclare que lo deberian
implementar con trigger esa regla de negocio

Microsoft MVP SQLServer
www.sqltotalconsulting.com
-

"Alfredo Novoa" escribió en el mensaje de
noticias:13gfs2rd7dwzl.rsjlnqptui7s$

Hola Maxi,

El Wed, 14 May 2008 21:00:10 -0300, Maxi Accotto escribió:

Hola, bueno la cosa no es asi, quien dijo que no se puede modificar?

Lo dije yo :-)

si
haces un update se modifica!

Si haces un update y este viola una regla de un CHECK no se modifica.

Pero los checks no funcionan con los borrados :-(

para evitar esas cosas deberias definir reglas
de negocio que lo impidan

Los manuales de SQL Server las llaman reglas de integridad definidas por
el
usuario:

http://msdn.microsoft.com/en-us/lib...88258.aspx

Aunque esto es bastante tonto, por que todas las reglas de integridad son
definidas por los usuarios.

, por ejemplo por medio de trigger, pero por
defecto sql te deja hacer la sentencia DML que tengas permiso y no viele
alguna restriccion si existe

Como dijo Carlos, te deja ejecutar deletes aunque violen restricciones
CHECK :-(

CHECK constraints are not validated during DELETE statements. Therefore,
executing DELETE statements on tables with certain types of check
constraints may produce unexpected results.

http://msdn.microsoft.com/en-us/lib...88258.aspx

Saludos

Responder a este mensaje

#22 Carlos M. Calvelo

15/05/2008 - 20:07 | Informe spam

Hola Alfredo,

On 15 mei, 10:27, Alfredo Novoa wrote:

El Wed, 14 May 2008 16:48:12 -0700 (PDT), Carlos M. Calvelo escribió:

> He estado pensando un poco mas sobre esto y creo que lo que se está
> tratando de expresar aquí no es una restricción de integridad típica,
> si no una regla de transición. Digamos una restricción de transición
> (insert, update o delete).

Si, aunque una regla de transición tampoco tiene nada de atípico,

Cierto. Era solo una forma de hablar. :-)

> Para asegurarse de que algo no cambia se necesita poder 'ver' las
> versiones anterior y actual de los registros (deleted, inserted).
> Y por lo tanto creo que no es posible sin hacer uso de triggers.

En Tutorial D si que se podría definir fácilmente sin usar triggers.

Pues lo he buscado, y si. Es que han pensado en todo!
Pero es para mi una confirmación de que no iba yo para
nada por mal camino en como estaba evaluando el asunto
en cuanto a la necesidad de tener acceso a las versiones
anterior y actual de los registros.
Y lo ideal sería poder hacerlo de forma declarativa, claro;
y sin acoplar la restricción a determinadas acciones como
es el caso con los triggers.

Saludos,
Carlos

Siga el debate Respuesta

Responder a este mensaje

Ads by Google

Hacer una pregunta

Tengo una respuesta

1 2 3 4 5

Busqueda sugerida