La mejor manera de realizar esta situación
#1
Escrito 20 marzo 2009 - 02:28
Saludos.
#2
Escrito 21 marzo 2009 - 09:29
if UltimoMesInicializado <> MesActual then Iniciocontador; LeoContador;
#3
Escrito 21 marzo 2009 - 09:34
#4
Escrito 21 marzo 2009 - 09:39
me falto colocar que cuanto inicializas el contador inicias el ultimo mes...
#5
Escrito 21 marzo 2009 - 11:53
Anoche vi el hilo y me quedé pensando. Tengo mis dudas y reservas sobre el tema... y viendo lo que comenta Eduardo debo decir ¡Momento!¡Paren el carro!
Antes que nada pregunto: ¿Es buena idea reiniciar la secuencia autonumérica? Se supone que el autonumérico es único.
¿En que medida esto puede afectar al diseño de tu base de datos? ¿Cómo está estructura tu base de datos?
En tu descripción nos comentas que tienes un campo autoincremental para las facturas, y luego tienes otro destinado para una tabla ¿Que tabla? Si estos mismos campos actuan de clave primaria y/o foráneas veo una practica peligrosa la de reiniciar el contador.
Si no es mucha molestia para comprender mejor el tema... ¿podríamos conocer un poco más del tema? ¿Es posible ver una diseño del DER o MER?
En cuanto al aspecto lógico, conceptualmente, es similar a como menciona eduardo. Ahora bien, hay que analizar en que medida se puede garantizar la integridad y consistencia de los datos.
Por lo que entiendo, se reinicia la cuenta de factura con el inicio del año... si es así:
if AnioActual <> UltimoAnio then begin reiniciarNumeracionFacturas; UltimoAño := AnioActual;
Esta lógica se puede llevar dentro del sistema o la base de datos, o bien de forma conjunta entre sistema y base de datos. Tal vez el uso de triggers, procedimientos almacenados y otros elementos puedan ser últiles.
Saludos,
#6
Escrito 21 marzo 2009 - 12:07
Antes que nada pregunto: ¿Es buena idea reiniciar la secuencia autonumérica? Se supone que el autonumérico es único.
Hola Delphius, no, no es el campo autoincremental la que se reiniciará sino el otro campo que mencioné para esos fines.
En tu descripción nos comentas que tienes un campo autoincremental para las facturas, y luego tienes otro destinado para una tabla ¿Que tabla? Si estos mismos campos actuan de clave primaria y/o foráneas veo una practica peligrosa la de reiniciar el contador.
No amigo, creo que leíste mal, dije que tengo UNA tabla con esos dos campos uno incremental y el otro para generar la numeración de la factura.
Si no es mucha molestia para comprender mejor el tema... ¿podríamos conocer un poco más del tema? ¿Es posible ver una diseño del DER o MER?
Me vas a perdonar, pero desconozco lo que es DER o MER :$.
Saludos.
#8
Escrito 21 marzo 2009 - 03:03
Tal como lo hizo Fernando no debe dar mucho problema, ya que la clave real si es correlativa, ese lo toma como un campo mas para satisfacer al cliente.
#9
Escrito 21 marzo 2009 - 04:00
Tal vez sea el "cliente quien lo pide" un motivo, pero creo que se puede ofrecerle un diseño y una solución que sea compatible con lo que necesita sin necesidad de recurrir a un reinicio.
Como dices, es un campo más. Y si, tal vez no le cause problemas y es una solución económica.
Disculpen si yo antes he entendido algo mal.
Saludos,
#10
Escrito 21 marzo 2009 - 04:40
Es más, no es necesario disponer de un auto-incremental. Veamos... la información ya está ¿o no? El asunto es que al cliente no es la representación más adecuada. Entonces que hacemos, se la damos.
Se puede disponer de un trigger after insert que "calcule" el campo:
1) Lanzamos una consulta para saber la cantidad de registros del año en curso
2) Guardamos el valor en una variable, a falta de imaginación la llamo N.
3) Operamos:
3.1. El numero de registro de factura es N+1. Nro = N + 1.
3.2. Para el año tomamos los dos caracteres finales y lo almacenamos en Año.
3.3. Guardamos el valor del campo en cuestión con el formato Nro/Año.
Y como ven, nada de campos autoincrementales, reseteos, un simple trigger se encarga de "calcular" el campo a medida que se van ingresando. Luego tras una consulta uno puede mostrar el campo sin problemas.
No se si se me entiende. Tengo otras ideas, pero son un poquito más complicadas.
Saludos,
#11
Escrito 21 marzo 2009 - 08:16
#12
Escrito 23 marzo 2009 - 08:27
ID.- Integer de llave primaria.
Fecha.- TimeStamp para fecha y hora de la factura.
Numero.- SmallInt para número consecutivo por año.
NumeroFormato.- Computado, concatenación del año del campo Fecha con el campo Numero bajo el formato que sugiera el cliente.
Con un disparador (trigger) Before Insert, para establecer el campo Numero en base al año del campo Fecha (último número de ese año más uno).
Dentro del disparador, la sentencia de asignación sería algo como:
-- Obtener el siguiente número de factura del año SELECT COALESCE (MAX (Numero), 0) + 1 FROM Factura WHERE EXTRACT (YEAR FROM Fecha) = EXTRACT (YEAR FROM NEW.Fecha) INTO NEW.Numero;
Esto lo analicé con Firebird, sólo habría que adaptarlo a las características de MySQL.
Espero te sea de utilidad, Fernando.
Saludos.
Al González.
#13
Escrito 24 marzo 2009 - 09:13
Saludos.