FiveTech Support Forums

Julio:

Yo le agregaria un campo adicional (tipo caracter .. 100 o 150 ) en donde guarde el dato anterior del registro en caso de modificación y asi se podria comparar el dato modificado con el original.

Yo utilizo mucho ese control pero a diferencia tuya, no tengo un DBF aparte, si no que se le agrego a todas mis DBFs los campos de control de usuarios.

Saludos

Julio,

yo guardo en una dbf x dia 1 registro, y tengo un memo dnd voy escribiendo cada accion q hacen en ese dia, cada usuario, ahora estoy migrando a mysql y voy a convertir en 1 registro x operacion. cada renglon del memo tiene : hora, terminal, usuario, accion.

espero te sirva.

Salu2, Ariel.

Hola,

Gracias Mauro. Aún me parece mejor guardar todo en una tabla aparte, y no en la misma que se ha modificado.

Ariel: ¿Como obtengo la identificacion de la terminal que ejecutó la acción?

Abrazos,

Julio,

En cada estacion, yo tengo una dbf (estacion.dbf) con un solo registro y varios campos (path servidor, nombre maquina, codigo usuario,....)

Cuando un usuario entra en la aplicación y autentifica su codigo/clave en el servidor, cambio en la dbf local (que esta abierta en exclusive) el código del usuario.

Tengo una sola dbf para llevar el control del usuario. Uno de los campos es el codigo del usuario otro la máquina, ambas informaciones las saca del fichero estacion.dbf.-

En el fichero de control, incluso anoto los intentos de entrar en la aplicación, porque en alguna ocasión un usuario ha intentado entrar con la clave de otro.

Cambiando de tema. Me gustaria contactar directamente contigo para hablar del tema del GPRS. ¿Puedes enviarme un correo a valdenebro arroba mixmail.com ?

Hola,

como todos tengo algo similar, como siempre aqui en el trabajo tienden a decir que debe ser un error del sistema, entonces hice algo similar

usuario
ip
fecha
hora
operacion
tabla
id (odentificador del reg, llave primaria)
informacion

en la informacion se guarda, cierta informacion que es la mas critica del registro, esta informacion esta en un diccionario donde se definen los campos importantes para cada tabla, la forma de guardar la informacion es:

para una alta o eliminacion

campo1 : valor
campo2 : valor
....
campon : valor

para una modificacion

campo1 : valor_ant => valor_nuevo
campo2 : valor_ant => valor_nuevo
.....
campon : valor_ant => valor_nuevo

puede resultar redundante en el caso de las modificaciones, ya que se puede hilar toda la historia del registro y saber sus valores historicos
pero por ahora esta asi

Intente hacer algo mejor y automatico con ADS ya que maneja triggers incluso en modo local, pero el problema es como saber la informacion del usuario dentro el trigger, todo lo demas se tienes, el registro la fecha y hora, pero no supe como meter el nombre del usuario, si eso seria posible tendriamos un logging system sin hacer casi nada

bueno esta es mi experiencia

saludos

Marcelo

Hola Marcelo

Podrias explicar un poco de los triggers en ADS, me interesa saber como funcionan

desde ya muchas gracias...

jllinas wrote:Ariel: ¿Como obtengo la identificacion de la terminal que ejecutó la acción?

#pragma BEGINDUMP
#include <tchar.h>
#include <hbapi.h>
#include <windows.h>
#define MAX_USER_NAME 128

HB_FUNC( CCOMPUTERNAME )
{
   DWORD lwMax = MAX_COMPUTERNAME_LENGTH ;
   TCHAR hostname[ MAX_COMPUTERNAME_LENGTH + 1 ] ;
   GetComputerName( hostname, &lwMax ) ;
   hb_retc( hostname ) ;
}

HB_FUNC( CWINUSERNAME )
{
   TCHAR cusername[ MAX_USER_NAME + 1 ] ;
   DWORD wLen = MAX_USER_NAME ;
   GetUserName( cusername, &wLen ) ;
   hb_retc( cusername ) ;
}
#pragma ENDDUMP

Estimados,

Como dice William, simplemente con NETNAME() obtenemos el nombre de la pc, con esto me es + q suficiente.

Salu2, Ariel.

A trigger is a piece of code (similar to a stored procedure) that is executed on the server. Triggers differ from stored procedures because triggers are not called by the client, but instead are executed automatically in response to an insert, update, or delete operation.
Triggers are supported for both SQL and navigational update operations. Throughout this documentation the update operations will be specified using uppercase notation (for example, INSERT), but this does not imply an SQL-only limitation.

When a trigger is "fired" it contains some state information, which can be used inside the body of the trigger. Two in-memory tables are available inside a trigger; a __new table and an __old table. The __new table contains new field values that were, or are about to be, inserted into the table. The __old table contains old field values for the record in question.
Triggers can provide a very powerful means to maintain business rules inside of a database.
Triggers can be defined for any supported table type, and are not limited to the proprietary ADT format.

Both the Advantage Database Server and the Advantage Local Server support triggers. Implicit Transactions are the only trigger functionality that differ depending on server type.
Trigger support is a server-side feature. Any Advantage client version 6.0 or greater capable of opening a dictionary-bound table can utilize triggers. This can be beneficial if you want to add trigger support to your application, but don’t want to upgrade your client applications. Only the database server needs to be upgraded (to Advantage version 7.0 or greater) in order to start using triggers.

Bueno.... voy con lo mio:

• Gracias Maestro Mercado.

• Ya agregué los dos campos a la estructura de mas arriba: UAN (User Account Name) y CN (Computer name). Para los interesados, busque en Google, y para ambos está bien definirlos como campos Character de 20 (aunque CN puede ser de 15).

• Agregue el uso de estos valores con la función NetName() y NetName(.T.) de xharbour, a mi función de Auditoría Interna.

• Todo resultó perfectamente bien. Gracias a todo por su apoyo !

Abrazos,