From: "Lesniak, Steven" <Steven.Lesniak@ShepherdCasters.com>
> We've go a small number of people that can access the 1.1.18 Location
> Maintenance and one of them is entering Bogus locations into the system. Of
> course everyone is pointing at one of the other two and as Sys Admin, I need
> to find a way to prove who is actually doing it. I'm getting the feeling
> there is no way....
Then,... From: "Loope, Debi" <DLoope@PI-INC.com>
Well, I am the ONLY one that can access location maintenance. We
occasionally get 'bogus' locations. I am absolutely POSITIVE that I
did not add them myself. I know that there is another way a location
record can get added without going through the location maintenance
screen. Nevertheless, I have not been able to duplicate this.
All my sites are setup with automatic locations = no. These weird
locations get setup with permanent = no, single lot/ref = yes, a blank
status, no description, and a location name that is setup in another
site. I, too, blamed this on the one other soul who had access. So I
took his access away. And months later, another one appeared.
I was gonna suggest falling back on an old favorite, creating a front-end
procedure with a trigger. Something like:
<BLOCKQUOTE><font size="1" face="Arial, Verdana">code:</font><HR><pre>
/* xxiclomt.p */
{mfdeclre.i}
on create of loc_mstr
do:
assign loc_user1 = global_userid + " " + string(today).
end.
on update of loc_mstr
do:
assign loc_user2 = loc_user2 + global_userid + " " + string(today) + ",".
end.
{gprun.i ""iclomt.p""}
[/code]
But from what Debi said, this won't help. Looks like you're gonna have to set up
database triggers for this. I'd trap global_userid, the program-name() stack, date,
possibly time, etc..
---------------
Paul T. O'Leary
Evco Plastics, a leader in plastics injection molding
DeForest, WI USA