Re: Login in dynamically

Nice!

What, Access or Me? If Me, Then Ta! :-))))

So what I do is to allow them to logon using Access logon at startup.

It is not realistic to do otherwise than log them into Access ONCE in a given
session. Well it's impossible but I don't like that word, it's not needed
anyway. You say you are playing with it (which means to me you're not really
experienced with it), which is great of course, but I'd suggest finding out
what can be done or how it works before trying to invent your own schemes. My
impression is that your scheme WILL NOT WORK, even if it was possible.

All the forms will have disable edits, until the user clicks on my "edit"
button and I'll prompt the user for a user name and password.

Yes, to the first part. I've done that where it's critical (not often). The
code to alter Enable/Locked is not very difficult, and fancier code can even
determine dynamically what fields there are on a form (no need to worry if you
add more fields).

No. Never a good idea to prompt again for a password. I might in some
Menu/System/End-Of-Year Rollover scheme (something unrecoverable, or something
only to be done with the Developer on the telephone) but not otherwise. This
sort of security (changing from RO to RW), In My Humble Opinion, is either
different from or nothing to do with the provisions of Access ULS.

Access ULS says, this particular user (actually you'd set permissions to a
Group they join) can either have RO or RW to something. If they do they do,
and if they dont they dont, and so far as I know everyone is happy with that.
I mean, there's enough damn security permissions to set, how many do you want
in ULS if they "can in these circumstances and cant in those".

Then through
some VB ADO code I verify the information and unlock the form (allow edits).
Sounds good (but I'm not totally clear about the code part, checking on
permission to an object through code...I'll have to research that).

Yes. I use DAO but that's just a detail. This doesn't involve any DAO or ADO.
Me!SomeField.Enabled = True
Me!SomeField.Locked = False (if only one set, you get Greyed)
....or vice versa...long list unless you use code to auto-find all the fields.

My manager was very concern about the application running on different
machines and left unattended by their users and he wanted to enforce
security as per transaction and not per application session.

Well, I've seen sites where they go to lunch, or home, probably in the middle
of a transaction too. Never mind security, they might corrupt Access if it's
rebooted overnight! Stick a label in the middle of the screen or something;
there's only so much one can do to teach operators good practise (Computers,
not just Access)

That's why he
insisted in opening it logged in as a read-only user, and updating it as a
user with write permissions (without having to close or reload Access).

His idea is reasonable. Insistence over what a developer can do and how to do
it may not be.
I said how to secure it. Make sure they only have access to Forms (that's
another subject, things like AllowBypassKeys), then you can control
dynamically the access provided by the form.

But this is surely one of many worries? I still have some apps which are
"Unbound Forms" (not bound to a table and I have to do all programming/control
myself). Now I only use Bound Forms (much less work), but Bound Forms do
standard Access things (like, if you move off a record it is saved with no
prompt). I say, get used to it, I don't have time to program Unbound Forms.

That's why I was thinking on something like braking the connection (some
how) and have Access re-establish it through a logon screen without
reloading Access. I was exploring options like:
Application.CurrentProject.AccessConnection.Close

I don't recall anyone successfully posting how to change a UserID in one
session. Even if they did, who are you gonna ascribe the CurrentUser who
changed the form to? (that's the best way to track who/when changed data)

I could write an entire application in VB, which would allow me to connect
and disconnect successfully different times with multiple dynamic logins,
but the Access platform is faster and less code consuming for this kind of
stuff.

what do you think?

You could, but I don't believe VB coding would be any less than Access coding
(overall, not this specific aspect). VB coding is more because it creates an
exe, gets rid of half the Access bugs, easier to install, might be more
"independent", things like that.

You are concerned about a security level (locking or unlocking forms) which to
my mind is UNRELATED to ULS. Or, 100,000 programmers can't be wrong.

Can they?

Cheers
Chris


.