On 2010-01-04 15:18:27 -0800, Bizouman <bizouman (AT) gmail (DOT) com> said:
Quote:
And i'm not into creating another zillions linked table to
username=employee_name and won't be accessible thru out the tables
since the table won't be linked everwhere
So with one script I can go: if login =jsmith, set user = Joe Smith |
A table is definitely the way to go translating jsmith to Joe Smith.
Reasons behind this?
1. A table is easy to edit for users. A script is not.
2. Changing a script every time an employee is hired or fired or
changes their name is really high administrative overhead. Unworkable
in practice.
3. The table does *not* have to "be linked everywhere." The opening
script grabs the data that jsmith=Joe Smith and puts it in a global
variable ($$username) and THAT is available everywhere for that
session. You don't have to link the table anywhere, in fact. Just go to
a layout based on the TO and do a find for the login name. If it's
found, grab the data. If it's not found, the login fails.
Then when a record is created, the $$username of the person who
performed the action can be grabbed into the "Created By" field. Same
with the modification field or audit log field, if you have those.
and
4. If you ever find yourself entering a whole range of data into a
script to do the above kinds of translations, You're Doing It Wrong.
That calls for a table. Unless it's three or fewer items and they will
never change. And even then, I'd opt for a table, as users will tell
you things will never change, right up to the instant they want to
change them.
--
Lynn Allen
--
www.semiotics.com
Member FBA
FM 10 Certified Developer