On New Current Record

Guía de Diccionario de Datos
On new current Record
“On new current Record” puede considerarse como un evento Post-Find/Clear/Save/Delete, puesto
que se llama después de cada Find, Clear, Save y Delete. Ocurre siempre que CurrentRowId
cambie.
A “On new current Record” se pasan dos parámetros de RowId: el RowId del registro viejo y el
RowId del registro nuevo. Observando estos dos parámetros, puede decir si el DDO ha encontrado
un registro o si está creando uno nuevo (si el nuevo RowId es nulo).
No puede usar este procedimiento para cambiar el RowId en curso ya que este mensaje se envía
para notificar un cambio que va a ocurrir. No puede abortar el cambio.
“On new current Record” se envía cuando el registro en curso está cambiando, con dos
excepciones: si se inicia un DDO y el registro que está establecido es nulo, se llamará “On new
current Record” (el registro antiguo = nuevo registro nulo= nulo). Después de una grabación, se
llama a “On new current Record” de todos los DDOs que participaron en la grabación, incluso si el
registro no cambió. Si lo necesita podrá comprobar esta condición con “Operation_Mode” y ver si
es “Mode_Saving”.
Procedure OnNewCurrentRecord RowId riOldRec RowId riNewRec
Forward Send OnNewCurrentRecord riOldRec riNewRec
// Asumiendo que deseamos atrapar grabaciones de registros nuevos
If (Operation_Mode = Mode_Saving AND ;
IsSameRowId (riOldRec, riNewRec)) Begin
:
End
Else....
End_Procedure
Notas especiales
Este mensaje debe ser reenviado (Forward Send).
Este evento no existe en la versión 10.1 de Visual DataFlex. En vez de dicha versión se emplea
el New_Current_Record. A este evento se le pasan los números de registro (Integers) en
lugar de RowIds. El evento de New_Current_Record todavía se convoca pero se considera
obsoleto. “On new current Record” es su sustituido preferido.
Consulte lo siguiente
Definir eventos de Diccionario de Datos.
www.VisualDataflex.es
Página 3 de 5
Guía de Diccionario de Datos
Relate_Main_File
Por defecto, Relate_Main_File no hace nada. Ocurre después de que el “Relate” normal se haya
ejecutado. Es un evento que permite ejecutar relaciones personalizadas después de que su
registro principal se haya encontrado y relacionado.
Si va a encontrar registros nuevos en Relate_Main_File, debe notificar que el DDO ha encontrado
este nuevo registro. Esto se hace enviando el mensaje de Request_Relate (si se encuentra el
registro) o Request_Clear_File (si el registro no se encontró). Request_Relate también ejecutará
un Relate el registro recién encontrado.
Esto es particularmente verdadero si el DDO está actualizando el “DDO padre” del registro que ha
encontrado. El siguiente código que mostramos a continuación encuentra un “Registro padre” y
notifica al DDO que lo ha encontrado. (Nota: esta es lo que habitualmente se llama “Sofi Find” y
no debe confundirse con “Sofi Relate”)
Procedure Relate_Main_File
Boolean bMustFind
Integer iFile iStatus
Get Main_File to iFile
Get_Attribute DF_FILE_STATUS of iFile to iStatus
Forward Send Relate_Main_File
If (iStatus = DF_FILE_INACTIVE) begin
Move True to bMustFind
end
Else if (Vndr.Soft_id <>SoftFile.Soft_id) begin
Move True to bMustFind
end
If bMustFind Begin / / Solamente relaciona SoftFile si es necesario
Clear SoftFile
Move Vndr.Soft_ID to SoftFile.Soft_Id
Find eq.SoftFile.Soft_Id
End
Get_Attribute DF_FILE_STATUS of SoftFile.File_Number to iStatus
If (iStatus<>DF_FILE_INACTIVE) begin
Send Request_Relate SoftFile.File_Number
End
Else begin
Send Request_Clear_File SoftFile.File_Number
End
End_Procedure
Note la optimización de este procedimiento. La búsqueda en SoftFile se lleva a cabo sólo si: el
Buffer de SoftFile está vacío o si el registro en el Buffer no es el que queremos (los valores
relacionados no son los mismos).
www.VisualDataflex.es
Página 4 de 5
Guía de Diccionario de Datos
Se recomienda optimizar sus búsquedas dentro de Relate_Main_File. Debido a que los DDOs no
pueden saber qué está haciendo este procedimiento, no hay, tampoco, ninguna manera de
optimizar estas búsquedas. En el momento en que un DDO piense que la relación personalizada
de un registro pudiese ser incorrecta, enviará Relate_Main_File. Esto sucede a menudo. Por eso es
importante que optimice sus búsquedas (un proceso sencillo) para no ralentizar sus operaciones
de base de datos.
Preste atención pues Relate_Main_File no siempre encuentra registros que se relacionan con el
registro actual. Cuando se cambia el “registro padre” de un “registro hijo”, Relate_Main_File se
llamará durante el proceso de grabación para encontrar registros relacionados con el “padre
nuevo” y el “padre antiguo”. Debido a esto, CurrentRowId (o el obsoleto Current_Record) no debe
usarse en los procedimientos de Relate_Main_File. Dentro de Relate_Main_File debe de hacerse
referencia al valor real del Buffer del fichero o el RowId (usar la función de GetRowId) de la tabla.
Se puede usar OnNewCurrentRecord para hacer el seguimiento de cambios en CurrentRowId.
Cuando acceda a los valores de la tabla debe acceder al Buffer global y no al Buffer local de DDO
(debe usar la sintaxis del tipo “Move File.File to Var). Para más información consulte
“Comprendiendo Buffers globales y Buffers locales de DDO”.
Consulte lo siguiente
Definir eventos de Diccionario de Datos.
Save_Main_File
Save_Main_File sirve para grabar el fichero principal. Puede usar Save_Main_File para tablas
adicionales no relacionadas o para procesar cambios adicionales en su tabla.
Save_Main_File se llama para cada tabla que se graba en una operación del Diccionario de Datos.
Este método puede llamarse incluso si no hay ningún cambio para grabar. En tal caso, la
grabación física en la base de datos no ocurrirá aunque se llame el evento.
En este ejemplo, queremos grabar la fecha y hora en cada registro grabado. Puesto que fijar la
fecha y la hora en un campo puede causar que un registro no modificado se grabe, únicamente
cambiaremos dicho valor si se modifica el registro. Si se modifica el Buffer del fichero,
marcaremos el registro con la fecha y hora.
Procedure Save_Main_File
Boolean bChanged
Interger iFile
Get Main_File to iFile
Get_Attribute DF_FILE_CHANGED of iFile to bChanged
// Solamente marcamos el registro si este se ha modificado. Esto asume
// que las funciones Crnt_Date y Crnt_Time ya existen.
If (bChanged) Begin / / if record is changed at all
Get Crnt_Date to Vndr.Date_Stamp
Get Crnt_Time to Vndr.Time_Stamp
End
// now do the normal save behavior
Forward Send Save_Main_File
End_Procedure
www.VisualDataflex.es
Página 5 de 5
Guía de Diccionario de Datos
Normalmente, siempre haremos un Forward Send de este mensaje. Si el mensaje no se envía, la
grabación no tendrá lugar.
Este mensaje se convoca en un estado de bloqueo. No lleve a cabo ninguna actuación por parte
del usuario en este evento.
Si declara un error, la transacción se deshará (Roll back). Los errores deben generarse usando el
comando de error. Para más información consulte “Manejo de error en las transacciones”.
Cuando acceda a los valores de la tabla debe acceder al Buffer global y no al Buffer local de DDO
(debe usar la sintaxis del tipo “Move File.File to Var). Para más información consulte
“Comprendiendo Buffers globales y Buffers locales de DDO”.
Consulte lo siguiente
Definir eventos de Diccionario de Datos.
Update y Backout
Los eventos de Update y Backout se usan para mantener balances de relación entre tablas.
Update es llamado en las modificaciones y altas de registros, mientras que Backout es llamado en
las modificaciones y borrados de registros. Update y Backout se emplean generalmente para
ajustar las “tablas padre”. Backout, concretamente, se emplea para eliminar el efecto de una
grabación mientras que la Update se usa para añadir el efecto de una grabación.
Los siguientes Update y Backout en un Diccionario de Datos ajustarían los totales de su padre, la
tabla vndr.
Procedure Update
Forward Send Update
Move (Checks.Total.+ Vndr.Total_Paid) to Vndr.Total_Paid
End_Procedure
Procedure Backout
Forward Send Backout
Move (Checks.Total- Vndr.Total_Paid) to Vndr.Total_Paid
End_Procedure
Cuando se graba un registro Nuevo (Alta) se llama Update (y no a Backout).
Cuando se borra un registro (Elimina) se llama a Backout (y no a Update).
Cuando se modifica un registro existente se llama a ambos (Update y Backout).
La mayoría de las veces los contenidos de Update y Backout serán el inverso de sí mismos. Si no
lo son, deberá revisar su lógica de forma cuidadosa. La mayoría de las veces lo que Update
añada a un total, Backout se encargará de restarlo.
www.VisualDataflex.es
Página 6 de 5
Guía de Diccionario de Datos
Es posible que Backout y Update puedan ajustar totales de diferentes “tablas padre” durante una
edición. Esto ocurriría si la edición causase que el “Registro padre” cambie. Los DDOs soportan
esto.
No asuma que los eventos de Update y Backout solamente se envían una vez durante una
grabación. Si el “Registro padre” de un “Registro hijo” no se cambia, entonces Backout y Update
se llaman una sola vez. En caso de que se cambie el “Registro padre” de un “Registro hijo”,
entonces Backout y Update se llaman más de una vez. Por ejemplo: supongamos que nuestra
tabla de clientes está relacionada con una tabla de zonas geográficas de forma que un cliente
pertenece a una zona y una zona tiene múltiples clientes. En este caso, nuestra “tabla hijo” es la
tabla de clientes y la “tabla padre” es la de zonas. Supongamos que en la tabla de zonas
llevamos un total de ventas de cada zona que es la suma de las ventas de cada uno de los
clientes de esa zona. Si a un cliente le cambiamos de zona (a un “Registro hijo” le cambiamos el
padre) entonces Update y Backout se llaman más de una vez. El proceso de mantener integridad
relacional cuando se cambia el registro padre de un hijo es bastante complejo y ambos eventos
pueden ser llamados múltiples veces para la misma tabla (para diferentes registros).
Si un cambio en un registro debe ajustar totales en un “Registro padre” y “abuelo” (Ejemplo: el
importe de una línea ajusta los totales de la factura, y esta a su vez el crédito consumido del
cliente), es mejor dejar que un Diccionario de Datos actúe sobre su padre(s) inmediato(s) (líneas
sobre factura y factura sobre cliente).
Este mensaje se convoca en un estado de bloqueo. No lleve a cabo ninguna actuación por parte
del usuario en este evento.
Si declara un error, la transacción se deshará (Roll back). Los errores deben generarse usando el
comando de error. Para más información consulte “Manejo de error en las transacciones”.
Cuando acceda a los valores de la tabla debe acceder al Buffer global y no al Buffer local de DDO
(debe usar la sintaxis del tipo “Move File.File to Var). Para más información consulte
“Comprendiendo Buffers globales y Buffers locales de DDO”.
Consulte lo siguiente
Definir eventos de Diccionario de Datos
www.VisualDataflex.es
Página 7 de 5