"Jamey Shuemaker" <ca*********@yahoo.comwrote in message
news:11**********************@h48g2000cwc.googlegr oups.com...
Yah, I looked at that sort of thing, but couldn't get it to integrate
with the .mdw.
You don't have to. All you do is prompt the user for password, and logonID.
I'd like not to store login ids or pwds any place except
the .mdw,
Yes, that is exactly what I been suggesting.
but haven't been able to replace the login prompt with my
own.
Why will the launch pad ask for a logon if your launch pad program is not
secured? (answer: it will not, assuming you read, and followed my other
post - I suggested to NOT JOIN the secured workgroup file, and that way all
mdb's that you launch will NOT prompt for passwords or logons - I STRONGLY
suggest that you do this anyway. (why have ALL mdb files nag and prompt
users?). What happens if they place other mdb files on their machine that
are not secured??? No need to set the workgroup file. Stay attached to the
default one, and ONLY use the workgroup file via a shortcut. So, don't
join the secured workgroup file, but use a shortcut for those secured ones
(so, users don't get messed with when using toher mdb files - or, what
happens if they have antoher seucred mdb file with a differnt workgroup?
that "other" applcation will then mess up yours if they also need to be
set to a particlar workgroup. Using shorcuts ellmonates this problem.
Further, for our idea, will
simply *shell* out to that secured mdb file, and will provide the path name
to the security workgroup file AND ALSO THE COMMAND LINE switches with the
user name and password.
I suppose I could access the security structure in the .mdw via
DAO or ADOX, but that may be more overhead than it's worth.
NO not suggesting this at all...
You not storing the users logion in a table, but simply prompting the user
for their logon name, and logon password Once you done that prompting, you
have their logon name + password storing in variables in the program - Not
in a table.
You simple prompted the user for the password, and logon name. You can now
shell to any secured database, and supply the passwrod+logon that the user
just gave you.
From my last post:
<quote>
Then, to launch any, and all other databases, you simply shell out, and add
the user + password as the command line switches....
</quote>
Of course, the only *slight* problem with the above is that during the logon
process, if the user id/and or password typed in is WRONG, then they will
ONLY find this out when you actually try and shell out to those secured
databases, not during your "fake" logon process. However, once they do type
in a legitimate logon and userID, then the shelling out will work.
Further, you *could* add code to the logon process to actually open that
other secured database during the logon process, and verify if the password+
logon is legitimate (but, lets fry one fish at a time).
So, first, lets just get the shell code working (you likey have that now
anyway).
The code to do this (well, you would build a nice logon form), but the meat
is building a shortcut...:
"C:\Program Files\Microsoft Office\OFFICE11\MSACCESS.EXE"
"c:\program files\RidesXP\RidesXP.mdb"
/wrkgrp "c:\Program Files\RidesXP\Rides.mdw"
/User "RidesAdmin" /pwd "mypassword"
So, a shortcut that shells out to ms-access can supply that users name, and
logon. We don't nothing to actually verify that the logon and password is
legitimate.
q = chr$(34) ' a double quote (")
strLogOn = inputbox("Enter your logon")
strPassword = inputbox("Enter password")
Now, just build shell string with the above....
strCurrentDir = CurrentProject.Path & "\"
' path to msaccess is required here
strShellProg = q & SysCmd(acSysCmdAccessDir) & "msaccess.exe" & q & " "
' path to current dir...and upgrade...
strShellProg = strShellProg & q & strCurrentDir & "UpGrade.mde"
strShellProg = strShellProg & _
" /user " & q & strLogOn" & q & " /pwd " & q & strPassword & q
Shell strShellProg
The above is not 100% correct, but is quote close to teh idea here.
Above I am shelling out to mdb called upgrade, but it
could just as well been what you selected on your launch pad. You can see
that NOTHING is stopping you from prompting the user for logon+passwrod. You
then simply use that as part of the shell process. Note how the above does
not HARD code the path name to ms-access.exe, since it will OFTEN be
different on different pc's. (so, don't hard code path to the .exet).
Once you get the above working, then you can start adding code that actually
tries to *open* (not shell!!) that database on the password + logon given.
This is a *can* part, but is NOT required.
Here is another code snip that gives some ideas about opening a secured
database to actually verify what the user typed in:
to open a table in your current database, you go:
dim rstDataTable as dao.recordset
dim myDB as dao.database
set myDB = currentdb
setrstData = currentdb.OpenRecordSet("mytable")
normally, to open *another* database (not load, or run BUT SIMPLY OPEN!!!).
You take the above code, and go:
dim rstDataTable as dao.recordset
dim myDB as dao.database
set myDB = openDatabase("path name to any mdb file")
setrstData = currentdb.OpenRecordSet("mytable")
Right? You done the above two things many times (I mean, in code, how else
did you ever open other databases?????). The problem is that in our 2nd
example, we want to open a *secured* database, but how to some how supply
the user log on and password (but, low, and behold...we asked the user for
that!!!).
So, code to open a secured database is more complex, but we CAN do this...
eg:
Dim dbe As DAO.PrivDBEngine
Dim wrk As DAO.Workspace
Dim dbs As DAO.Database
Dim rstTables As DAO.Recordset
' setup new workgroup
' Return a reference to a new instance of the PrivDBEngine object.
' we have to do this to OPEN a file with a DIFFERNT workgroup
Set dbe = New PrivDBEngine
' Set the SystemDB property to specify the workgroup file.
dbe.SystemDB = "path name to workgroup file"
dbe.DefaultUser = Me.txtUser ' user logon
dbe.DefaultPassword = Me.txtPass ' user passowrd
Set wrk = dbe.Workspaces(0)
' Open the secured database.
Set dbs = wrk.OpenDatabase(Me.Text0)
' database open...now grab table list...
I don't think it needs explain that if the above code fails to open the
secured database, then obviously the user supplied password and name are
wrong!!! (so, again, do I really need to explain that if you can't open a
secured database with a username + password you prompted for, then obviously
that user name + password is wrong!!!..right?). So, simply "test" open one
of those several databases that you want to shell out to. (add this code to
your above logon procdure)
Certainly not a lot of code here, but just a question of realizing that if
we prompt the user for their name+password, we don't have to store it
anywhere, but simply use that in our code that shells out. As I said,
actually verifying if the supposed name+passowrd is actually optional,
but the above shows this is also possbile...
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com 
