"thebarefootnation" <th***************@googlemail.comwrote
As I have created a login form to get into the database
I'd prefer to bring back the User Name from this form,
not from the Windows login.
My login form is called "frmLogin" and the User
reference text box is "UserID".
Can anyone help me with the code to pull the UserID from
"frmLogin" into the textbox "CREATED_BY" in the form
"frmNewRecord".
Heh, heh... That kyle... he's always giving his brother Lyle a hard time.
If you want some guidance on Roll-Your-Own (RYO) security, you first have to
agree to read and understand the following: (1) The Access Security Wizard
is about as close to worthless as any feature of Access could be, because it
often misleads people into thinking that their databases are secure. (2)
Access own security, described in detail in the "Access Security FAQ" of 39
pages that you can download from Microsoft is also fallible (but, if you
carefully read, study, and follow the steps, it will be as secure as you are
going to make an Access database). Don't count on it if your application or
data is worth more than about US$140-150 because that is what it will cost
to obtain code to crack it. (3) This is the key item: Any RYO security you
create will be significantly less secure than either of these, crackable
without expense, without third-party tools, by Access developers with only
modest talent. If you have honest users who don't want to "get at"
information in your DB that they shouldn't, it can serve, at best, to keep
them from accidentally stumbling into objects where they have no need to be.
That said, presumably you are going to check the userid entered from your
form against a table of valid userids, and also the user's password? If
not, you'd better rethink the whole idea. Then you have to store, or save,
the current user's id somewhere where you can retrieve it. (1) One
convenient place would be a public variable in a standard module, but those
may be (at least usually are) lost if you have an unhandled error... thus,
if you choose this approach, you also need to shut down the application
immediately if the variable in which you have saved your userid turns up
empty or null. (2) Another way is to create a property of the database and
save it to and use it from there. (3) Perhaps even easier and somewhat
safer is to store it in a field on a form that you have hidden one way or
another.
Whichever way you choose, just remember that most any plain ol' everyday
Access developer with a medium level of knowledge, will be able to break
your security scheme in hardly any time at all.
And, by the time you get through with all the implementation and levels of
obfuscation that you (wrongly) convince yourself will actually make it
secure, you could have downloaded the Access Security FAQ, studied,
re-studied, and learned it, and applied it... so at least it might cost a
database thief or a data thief $150 to steal your stuff.
If you really need to protect your data, put it in a server DB and apply the
server DB's security. If you want to protect your database application, be
aware that, an experienced Access developer can watch it run, and re-create
it faster than you did in the first place, because you've already done all
the "heavy lifting" of determining and laying out for them what information
needs to be dealt with, where, and by whom, to solve the business problem.
Larry Linson
Microsoft Access MVP
