Hello, all;

Basically what I want to do is have my database have two password-protected
users: One that can see everything and one that I just show the forms to.
I am having conceptual problems with the whole security scheme + Access
thing.

In an ideal world, I'd like to be able to hand the Access file (by itself)
to the client, plus the two user names & passwords, and have the user in
question be able to open the database in the appropriate view. Sounds
simple enough, but when I crack open the help, it seems that all the
password protection stuff wants this workgroup definition file thing. Isn't
there any way to just set up users with passwords that are saved with the db
itself?

Barring that, I'd like to have the database look for its workgroup file in
the same directory as itself. How would I specify a relative path for the
workgroup file for the "b" option, assuming the "a" option isn't possible?

TIA;

Amy

"Amy Blankenship" <(E-Mail Removed)> wrote in message
news:ec$(E-Mail Removed)...
> Hello, all;
>
> Basically what I want to do is have my database have two
> password-protected users: One that can see everything and one that I just
> show the forms to. I am having conceptual problems with the whole security
> scheme + Access thing.
>
> In an ideal world, I'd like to be able to hand the Access file (by itself)
> to the client, plus the two user names & passwords, and have the user in
> question be able to open the database in the appropriate view. Sounds
> simple enough, but when I crack open the help, it seems that all the
> password protection stuff wants this workgroup definition file thing.
> Isn't there any way to just set up users with passwords that are saved
> with the db itself?

You want an admin account (to see the database window, "everything") and a
user account? That is fairly simple and implies that one of your clients
users is experienced enough to set up the necessary shortcuts depending on
drive mappings. The online help is woefully inadequate and you need to
reference the MS FAQ - link on my website. Be warned though, the FAQ is
"all killer, no filler" and you must follow all the steps. My step-by-step
example may help too, but always work on copies of you files in case you
lock yourself out.

>
> Barring that, I'd like to have the database look for its workgroup file in
> the same directory as itself. How would I specify a relative path for the
> workgroup file for the "b" option, assuming the "a" option isn't possible?
>
The path to the workgroup file is defined in a shortcut in the format:

"Full path to MSACCESS.exe" "Full path to your app.mdb" wrkgrp/"Full path to
workgroup file.mdw"

HTH - Keith.
www.keithwilby.com

Amy Blankenship wrote:

(snip)

> Barring that, I'd like to have the database look for its workgroup file in
> the same directory as itself.

You misunderstand how it works. Access selects a workgroup file before
it even /opens/ your database. The database itself plays /no part
whatever/ in Access'es decision on which workgroup file to use.

If you double-click an mdb file, the sequence of actions is as follows.

1. Windows determines that mdb files, should be opened with MS Access;
2. Windows starts MS Access, passing the mdb file name as a parameter;
3. MS Access opens the default workgroup file for that PC;
4. MS Access /then/ opens the specified mdb file, then
5, The mdb file works, or doesn't work, depending on whether it is or
is not usable with the PC's default workgroup file.

When you secure an mdb correctly, you create a new workgroup file, and
the mdb file will /not/ work with the default workgroup file. So if you
double-click that mdb file, it will fail, because Access will use the
defauilt workgroup file, exactly as described above.

When you start an mdb file using a shortcut of the standard form, shown
below, Access starts, then opens the /specified/ workgroup file
(regardless of the PC's default workgroup file), then opens the mdb
file. You must use the shortcut approach when opening a
properly-secured mdb file.

"full path to MSACCESS.EXE"
"full path to MDB file"
/wrkgrp "full path to MDW file"

In summary, there is no situation where "the database looks for the
workgroup file". It simply does not work like that.

HTH,
TC

So if I put the file on A UNIX server, for instance, and I wanted to pass a
user name and password from an ASP page and windows isn't actually involved,
what would the process look like then?

And I've also gotten password-protected databases from people in the past
where I didn't change any files on my computer, but somehow when I
double-clicked on the file it asked for a password and let me in when I
provided it. What was the mechanism for this series of events?

Thanks;

Amy

"TC" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> Amy Blankenship wrote:
>
> (snip)
>
>> Barring that, I'd like to have the database look for its workgroup file
>> in
>> the same directory as itself.
>
> You misunderstand how it works. Access selects a workgroup file before
> it even /opens/ your database. The database itself plays /no part
> whatever/ in Access'es decision on which workgroup file to use.
>
> If you double-click an mdb file, the sequence of actions is as follows.
>
> 1. Windows determines that mdb files, should be opened with MS Access;
> 2. Windows starts MS Access, passing the mdb file name as a parameter;
> 3. MS Access opens the default workgroup file for that PC;
> 4. MS Access /then/ opens the specified mdb file, then
> 5, The mdb file works, or doesn't work, depending on whether it is or
> is not usable with the PC's default workgroup file.
>
> When you secure an mdb correctly, you create a new workgroup file, and
> the mdb file will /not/ work with the default workgroup file. So if you
> double-click that mdb file, it will fail, because Access will use the
> defauilt workgroup file, exactly as described above.
>
> When you start an mdb file using a shortcut of the standard form, shown
> below, Access starts, then opens the /specified/ workgroup file
> (regardless of the PC's default workgroup file), then opens the mdb
> file. You must use the shortcut approach when opening a
> properly-secured mdb file.
>
> "full path to MSACCESS.EXE"
> "full path to MDB file"
> /wrkgrp "full path to MDW file"
>
> In summary, there is no situation where "the database looks for the
> workgroup file". It simply does not work like that.
>
> HTH,
> TC
>

Your ASP page would "connect" to the file on the Unix box via ADO or ADO.NET
.... I'm not familiar with .NET, but with ADO your connect string would look
something like this:

oConn.Open "Provider=Microsoft.Jet.OLEDB.4.0;" & _
"Data Source=c:\somepath\mydb.mdb;" & _
"Jet OLEDB:System Database=MySystem.mdw", _
"myUsername", "myPassword"

Connect string from here:
http://www.carlprothman.net/Default....orMicrosoftJet

Your connection would actually use the .mdw file (probably on the Unix box
as well) to "open" the database ... your ASP server would handle the rest.

Password protected databases are different from database protected by ULS
.... password protection travels with the database and requires no external
files. ULS protected databases require the use of the .mdw workgroup file
(which stores Users, Groups, GroupMemberships, and Passwords) and the
database itself ... the .mdw file simply authenticates the user and tells
the db which groups the current user belongs to ... the acutal object
permissions are stored in the database itself.

--
Scott McDaniel
InfoTrakker Software
"Amy Blankenship" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> So if I put the file on A UNIX server, for instance, and I wanted to pass
> a user name and password from an ASP page and windows isn't actually
> involved, what would the process look like then?
>
> And I've also gotten password-protected databases from people in the past
> where I didn't change any files on my computer, but somehow when I
> double-clicked on the file it asked for a password and let me in when I
> provided it. What was the mechanism for this series of events?
>
> Thanks;
>
> Amy
>
> "TC" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>>
>> Amy Blankenship wrote:
>>
>> (snip)
>>
>>> Barring that, I'd like to have the database look for its workgroup file
>>> in
>>> the same directory as itself.
>>
>> You misunderstand how it works. Access selects a workgroup file before
>> it even /opens/ your database. The database itself plays /no part
>> whatever/ in Access'es decision on which workgroup file to use.
>>
>> If you double-click an mdb file, the sequence of actions is as follows.
>>
>> 1. Windows determines that mdb files, should be opened with MS Access;
>> 2. Windows starts MS Access, passing the mdb file name as a parameter;
>> 3. MS Access opens the default workgroup file for that PC;
>> 4. MS Access /then/ opens the specified mdb file, then
>> 5, The mdb file works, or doesn't work, depending on whether it is or
>> is not usable with the PC's default workgroup file.
>>
>> When you secure an mdb correctly, you create a new workgroup file, and
>> the mdb file will /not/ work with the default workgroup file. So if you
>> double-click that mdb file, it will fail, because Access will use the
>> defauilt workgroup file, exactly as described above.
>>
>> When you start an mdb file using a shortcut of the standard form, shown
>> below, Access starts, then opens the /specified/ workgroup file
>> (regardless of the PC's default workgroup file), then opens the mdb
>> file. You must use the shortcut approach when opening a
>> properly-secured mdb file.
>>
>> "full path to MSACCESS.EXE"
>> "full path to MDB file"
>> /wrkgrp "full path to MDW file"
>>
>> In summary, there is no situation where "the database looks for the
>> workgroup file". It simply does not work like that.
>>
>> HTH,
>> TC
>>
>
>

Amy Blankenship wrote:

> So if I put the file on A UNIX server, for instance, and I wanted to pass a
> user name and password from an ASP page and windows isn't actually involved,
> what would the process look like then?

Sorry, I have no idea.


> And I've also gotten password-protected databases from people in the past
> where I didn't change any files on my computer, but somehow when I
> double-clicked on the file it asked for a password and let me in when I
> provided it. What was the mechanism for this series of events?

It was a database password, not a "user level" (username/password) one.

HTH,
TC

So you have to provide the mdw in the connection string for this to work.
Why don't you have to give the full path to the mdw, but you do with the
database?

Thanks;

Amy

"Scott McDaniel" <(E-Mail Removed)> wrote in message
news:WPOdnWXCa4QeYpneRVn-(E-Mail Removed)...
> Your ASP page would "connect" to the file on the Unix box via ADO or
> ADO.NET ... I'm not familiar with .NET, but with ADO your connect string
> would look something like this:
>
> oConn.Open "Provider=Microsoft.Jet.OLEDB.4.0;" & _
> "Data Source=c:\somepath\mydb.mdb;" & _
> "Jet OLEDB:System Database=MySystem.mdw", _
> "myUsername", "myPassword"
>
> Connect string from here:
> http://www.carlprothman.net/Default....orMicrosoftJet
>
> Your connection would actually use the .mdw file (probably on the Unix box
> as well) to "open" the database ... your ASP server would handle the rest.
>
> Password protected databases are different from database protected by ULS
> ... password protection travels with the database and requires no external
> files. ULS protected databases require the use of the .mdw workgroup file
> (which stores Users, Groups, GroupMemberships, and Passwords) and the
> database itself ... the .mdw file simply authenticates the user and tells
> the db which groups the current user belongs to ... the acutal object
> permissions are stored in the database itself.
>
> --
> Scott McDaniel
> InfoTrakker Software
> "Amy Blankenship" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> So if I put the file on A UNIX server, for instance, and I wanted to pass
>> a user name and password from an ASP page and windows isn't actually
>> involved, what would the process look like then?
>>
>> And I've also gotten password-protected databases from people in the past
>> where I didn't change any files on my computer, but somehow when I
>> double-clicked on the file it asked for a password and let me in when I
>> provided it. What was the mechanism for this series of events?
>>
>> Thanks;
>>
>> Amy
>>
>> "TC" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>>
>>> Amy Blankenship wrote:
>>>
>>> (snip)
>>>
>>>> Barring that, I'd like to have the database look for its workgroup file
>>>> in
>>>> the same directory as itself.
>>>
>>> You misunderstand how it works. Access selects a workgroup file before
>>> it even /opens/ your database. The database itself plays /no part
>>> whatever/ in Access'es decision on which workgroup file to use.
>>>
>>> If you double-click an mdb file, the sequence of actions is as follows.
>>>
>>> 1. Windows determines that mdb files, should be opened with MS Access;
>>> 2. Windows starts MS Access, passing the mdb file name as a parameter;
>>> 3. MS Access opens the default workgroup file for that PC;
>>> 4. MS Access /then/ opens the specified mdb file, then
>>> 5, The mdb file works, or doesn't work, depending on whether it is or
>>> is not usable with the PC's default workgroup file.
>>>
>>> When you secure an mdb correctly, you create a new workgroup file, and
>>> the mdb file will /not/ work with the default workgroup file. So if you
>>> double-click that mdb file, it will fail, because Access will use the
>>> defauilt workgroup file, exactly as described above.
>>>
>>> When you start an mdb file using a shortcut of the standard form, shown
>>> below, Access starts, then opens the /specified/ workgroup file
>>> (regardless of the PC's default workgroup file), then opens the mdb
>>> file. You must use the shortcut approach when opening a
>>> properly-secured mdb file.
>>>
>>> "full path to MSACCESS.EXE"
>>> "full path to MDB file"
>>> /wrkgrp "full path to MDW file"
>>>
>>> In summary, there is no situation where "the database looks for the
>>> workgroup file". It simply does not work like that.
>>>
>>> HTH,
>>> TC
>>>
>>
>>
>
>

PS Do you have to use the Jet provider? I use stored queries, and I found
that the * in a stored query that works fine when tested internally will
fail when you call it from outside the DB with the Jet provider, because Jet
wants %. Therefore, I prefer not to have to go back and change all my
queries (and not be able to test internally).

Thanks;

Amy

"Scott McDaniel" <(E-Mail Removed)> wrote in message
news:WPOdnWXCa4QeYpneRVn-(E-Mail Removed)...
> Your ASP page would "connect" to the file on the Unix box via ADO or
> ADO.NET ... I'm not familiar with .NET, but with ADO your connect string
> would look something like this:
>
> oConn.Open "Provider=Microsoft.Jet.OLEDB.4.0;" & _
> "Data Source=c:\somepath\mydb.mdb;" & _
> "Jet OLEDB:System Database=MySystem.mdw", _
> "myUsername", "myPassword"
>
> Connect string from here:
> http://www.carlprothman.net/Default....orMicrosoftJet
>
> Your connection would actually use the .mdw file (probably on the Unix box
> as well) to "open" the database ... your ASP server would handle the rest.
>
> Password protected databases are different from database protected by ULS
> ... password protection travels with the database and requires no external
> files. ULS protected databases require the use of the .mdw workgroup file
> (which stores Users, Groups, GroupMemberships, and Passwords) and the
> database itself ... the .mdw file simply authenticates the user and tells
> the db which groups the current user belongs to ... the acutal object
> permissions are stored in the database itself.
>
> --
> Scott McDaniel
> InfoTrakker Software
> "Amy Blankenship" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> So if I put the file on A UNIX server, for instance, and I wanted to pass
>> a user name and password from an ASP page and windows isn't actually
>> involved, what would the process look like then?
>>
>> And I've also gotten password-protected databases from people in the past
>> where I didn't change any files on my computer, but somehow when I
>> double-clicked on the file it asked for a password and let me in when I
>> provided it. What was the mechanism for this series of events?
>>
>> Thanks;
>>
>> Amy
>>
>> "TC" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>>
>>> Amy Blankenship wrote:
>>>
>>> (snip)
>>>
>>>> Barring that, I'd like to have the database look for its workgroup file
>>>> in
>>>> the same directory as itself.
>>>
>>> You misunderstand how it works. Access selects a workgroup file before
>>> it even /opens/ your database. The database itself plays /no part
>>> whatever/ in Access'es decision on which workgroup file to use.
>>>
>>> If you double-click an mdb file, the sequence of actions is as follows.
>>>
>>> 1. Windows determines that mdb files, should be opened with MS Access;
>>> 2. Windows starts MS Access, passing the mdb file name as a parameter;
>>> 3. MS Access opens the default workgroup file for that PC;
>>> 4. MS Access /then/ opens the specified mdb file, then
>>> 5, The mdb file works, or doesn't work, depending on whether it is or
>>> is not usable with the PC's default workgroup file.
>>>
>>> When you secure an mdb correctly, you create a new workgroup file, and
>>> the mdb file will /not/ work with the default workgroup file. So if you
>>> double-click that mdb file, it will fail, because Access will use the
>>> defauilt workgroup file, exactly as described above.
>>>
>>> When you start an mdb file using a shortcut of the standard form, shown
>>> below, Access starts, then opens the /specified/ workgroup file
>>> (regardless of the PC's default workgroup file), then opens the mdb
>>> file. You must use the shortcut approach when opening a
>>> properly-secured mdb file.
>>>
>>> "full path to MSACCESS.EXE"
>>> "full path to MDB file"
>>> /wrkgrp "full path to MDW file"
>>>
>>> In summary, there is no situation where "the database looks for the
>>> workgroup file". It simply does not work like that.
>>>
>>> HTH,
>>> TC
>>>
>>
>>
>
>

I'm guessing that you /do/ need the full path to the workgroup file. I
can't see how it would otherwise work. It's sure not going to scan the
whole hard disk to find that file :-)

HTH,
TC