Relationship based on Get(Accountname)

[Jason Goldsmith]

Is using Get(AccountName) an advisable key field? I have indexing checked on "All" in both tables. Lookups then function and are a useful part of the solution.

Should I anticipate that users will need to change their account name in the future?

Also, my users login to create content. The content that they create is modifiable by them, and readable by others per calculation in Manage Accounts and Privileges (Get(AccountName) = Get(AccountName)).

So, there are two reasons why the account name should never change.

Is this a poor approach?

Thanks,

Jason

[Don_Macaroni]

I think in a commercial environment an Account name is not important to a user. It's just a method of ID-ing somebody, it's not MSN or Yahoo where people pick a nice name.

You as admin are the boss here, so unless the Account name of a divorced female employee still includes her ex-husband's name, I don't think Account names have to change...

Good luck!

[Steven H. Blackwell]

Basically, it is [color:red]not a good idea to use the Account Name or any other "meaningful" value as the key. A primary key, and that's where you're starting here, should be unique, persistent, existent, non-modifiable, and meaningless.

Should there be some future change in the construct of your OS or of your authentication processes, all Accounts could change. You'll have enough of a challenge with the Record Level Access items in such an instance, much less the relationships.

Finally, for RLA tests I would recommend not using the = operator. Use a text comaprison operator such as the Exact function.

Steven