How to add the security back to the normal database?

[Guest]

Hi,

I got a Access 97 databases which was linked to a Security database that is
an .mdw. i tried to open the database in Access 2003 but i failed to do that.

for this i exported all the objects from old 97 database to the new Access
97 blank database which contains no security, and tried to open the database
in Access 2003 i am able to open.

Now the problem is how to set back the security file which was linking to
the Old 97 Access database. Here the main thing is we cant create a new mdw
with new ID's and passwords.

 

[Joan Wild]

Hi,

I got a Access 97 databases which was linked to a Security database
that is an .mdw. i tried to open the database in Access 2003 but i
failed to do that.

You should have been able to do this, by opening in 2003, using the 97 mdw
file. You could use a desktop shortcut with the following in the target:

"path to 2003 msaccess.exe" "path to secure 97.mdb" /wrkgrp "path to secure
97.mdw"

2003 is quite capable of using a 97 mdw file.

for this i exported all the objects from old 97 database to the new
Access 97 blank database which contains no security, and tried to
open the database in Access 2003 i am able to open.
OK

Now the problem is how to set back the security file which was
linking to the Old 97 Access database. Here the main thing is we cant
create a new mdw with new ID's and passwords.

Why not? Since you now have an unsecured 2003 mdb, you could just go ahead
and secure it using 2003.

Or do you mean, you still want the 97 mdb secured? Why do you want the 97
mdb at all?

 

[Peter Yang [MSFT]]

Hello Raghuram,

I understand that you have exported Access 97 database to 2003 but you
cannot add security back to this new database. I'd like to know if you
encounter any problem when creating a new 2003 mdw file? How did you try to
create new mdw file? As Joan mentioned, you shall be able to create new
workgroup file for a unsecured mdb file.

You could try to click Tools->Security->Workgroup administrator->Create.

A workgroup is a group of users who share data in a multiuser environment.
When security is implemented on a database, the user and group accounts are
recorded in the workgroup information file. User passwords are also stored
in the workgroup information file.

When you install Microsoft Access and open a database for the first time, a
file named System.mdw is created. This is the default workgroup information
file.
By default, on computers that are running Microsoft Windows 2000, the
System.mdw file is created in the user profile in the following path.

Permissions and the ownership of the database objects are stored in the
database. Because permissions and ownership are always associated with the
user and group accounts that are stored in the workgroup information file,
the secured application must always be able to point to the specific
workgroup information file that it was secured with. You may want to check
the following articles for more details:

305542 Understanding the role of workgroup information files in Access
security
http://support.microsoft.com/default.aspx?scid=kb;EN-US;305542

Q289885 ACC2002: Overview of How to Secure a Microsoft Access Database
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q289885

289885 Description of how to help protect a Microsoft Access database
http://support.microsoft.com/?id=289885

304315 ACC2000: How to Simulate Column-Level Security in Microsoft Access
http://support.microsoft.com/?id=304315

If anything is unclear, please feel free to let's know. We look forward to
your reply.

Best Regards,

Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications
<http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx>.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
<http://msdn.microsoft.com/subscriptions/support/default.aspx>.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Thankyou very much for your time. . . .
Can you please answer me following questions

I have a Security.mdw which was created in Access 97 version, for this do we
need to convert into latest version
if yes how to do it. . .
If no why is that.

other than providing the shortcut for accessing database is there any other
way to retain back the security.

 

[Joan Wild]

Thankyou very much for your time. . . .
Can you please answer me following questions

I have a Security.mdw which was created in Access 97 version, for
this do we need to convert into latest version
if yes how to do it. . .

You can convert the mdw file (it's just a mdb file), using the Convert menu
item, but I wouldn't advise it. You are better off, unsecuring it in 97,
converting to 2003 and then applying security again. You'll find a couple
of utilities at www.daiglenet.com you can use to help you.
Use the following tool to document the security in 97 before you desecure.:
dbUtilities 1.1 at http://www.daiglenet.com/MSAccess.htm

Then you can use the following tool to assign permissions in 2003 after you
have created a new workgroup file, and set up groups.
dbUtilities 1.0 at http://www.daiglenet.com/MSAccess.htm

If no why is that.

There are plenty of reports of folks using a 97 version mdw file in a 2003
version mdb. The format of the mdw file didn't really change between the
versions. Furthermore, this allows you to handle the situation where you
might have some users on 2003 and some on 2003, and on 97. They can each
have a version of the frontend that they need - all of which would link to a
97 backend and use a 97 mdw.

other than providing the shortcut for accessing database is there any
other way to retain back the security.

The shortcut is the easiest. Otherwise, go through the process of
converting. Even after you convert and secure, you'd want to use a desktop
shortcut to launch your secure 2003 mdb. This is so you can keep the
standard system.mdw workgroup file as the default. If you join your secure
mdw as the default, then every mdb you open will require a login, not just
the secure one.that are.

 

[Peter Yang [MSFT]]

Hello Raghuram,

I fully agree with Joan's comments. Using shortcut might be the most
efficient method to manage different mdbs in different workgroup unless you
only have one Access database to run.

Usually it is not suggested that yu convert 97 version of mdw by using
Convert Database utility since there is some know issues, and you may want
to refer to the following article for more details:

824258 You receive error messages when you convert the workgroup
information (.mdw) file in Access 2003
http://support.microsoft.com/default.aspx?scid=kb;EN-US;824258

If you have any further questions or concerns, please feel free to let's
know. Thank you!

Best Regards,

Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Partner Support


=====================================================

This posting is provided "AS IS" with no warranties, and confers no rights.
======================================================

 

[Chris Mills]

Hi Peter,

Have you ever considered, as one of PSS remits, to report to the Dev Team that
converting mdw's is a standard feature of the Conversion Menu, and you say has
bugs?

Bugs are for reporting and fixing, aren't they?

An article notifying a bug, is not a bug fix is it? This bug has been around
for enough time for someone to actually do something.

Background:
It is known that converting mdw's is mentioned as "dicey" by the SecFAQ. It
seems to actually work however, unless one is converting from A2.0 mda's where
it's fatal.

Since the article suggests the bug is known, why couldn't anyone at MS get off
their FA to fix it?

The other part of the background, is that re-creating mdw's anew is often
impossible, for a variety of historic reasons related to the complexity of ULS
(or slackness of programmers documenting PID's/WID's), and there is NO
technical reason why the purported "convert mdw files" is not supported.

(except that MS couldn't seem to be bothered fixing it)

Thankyou. I feel much better now!
(I personally have all my PID's, but it's still a major to re-create an mdw.
And I don't know whether those error messages matter, because in trying the
resulting converted mdw it seems to work. /would be better if it just
Fell-Over)
Regards,
Chris

 

[Peter Yang [MSFT]]

Hello Chris,

Thank you for taking time to post your feedback on this known issue. This
will be taken seriously and routed to product team. I did sent feedback on
this known issue to proper channel so that they may consider a fix other
than a workaround since this may have big business impact of customers.

I do understand your concern in this scenario, I highly suggest you can
also submit this feedback to our product feedback center:
http://www.microsoft.com/office/community/en-us/wizard.mspx?type=suggestion&
lang=en&cr=US&cat=en-us-office&pt=3a4e9862-cdce-4bdc-8664-91038e3eb1e9

Though it is not suggested to converted 97 version of mdw file to
2000/2003 format, I had experience to converted it successfully and and
upgraded and/or new Access mdb databases to this converted mdw file.
Sometimes you may want to try this before you use the workarounds in
824258. Thank you.

Best Regards,

Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Partner Support


=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
======================================================

 

[Guest]

Hi Peter,

As you said i will accept the shortcut way, here the problem is all the
information relating to the MDB and mdw will be displayed once the user tries
to find the properties of the shortcut. Here how can we solve the issue.

As i was telling you that my databases can be accessed without any security
so if the user is aware of the paths then any user can access the
information.

Can you please provide with the information. . . .and a solution.

 

[Guest]

Hi Peter,

As you said i agree to go with the Shortcut way, i feel that's a better
idea. Here i see a problem, user can get the complete information of the MDB
and the MDW file path location as every thing will be listed.

As i was telling you that my database which is converted is not an Secured
one so If this is the case any user can use the database.

Can you please provide with the solution. . . .

 

[Guest]

Hi Peter,

As you said i agree to go with the Shortcut way, i feel that's a better
idea. Here i see a problem, user can get the complete information of the MDB
and the MDW file path location as every thing will be listed.

As i was telling you that my database which is converted is not an Secured
one so If this is the case any user can use the database.

Can you please provide with the solution. . . .

 

[Joan Wild]

As you said i agree to go with the Shortcut way, i feel that's a
better idea. Here i see a problem, user can get the complete
information of the MDB and the MDW file path location as every thing
will be listed.

Usually one splits a database. The backend would be on the server. The
path would therefore only show the path to the frontend mdb.

But why is knowing the location of the mdb/mdw an evil thing? They must
have always known the location of the mdb in order to use it in the past.

As i was telling you that my database which is converted is not an
Secured one so If this is the case any user can use the database.

If it's not secure, you don't need to use a desktop shortcut; just let the
users open the mdb directly using their standard system.mdw.

 

[Peter Yang [MSFT]]

Hello Raghuram,

As Joan mentioned, you could split the database to work around the issue.
Also, as I explained before, if client only uses one Access database, they
can join the default workgroup file (system.mdw) and not use shortcut as
suggested.

304932.KB.EN-US How to Manually Split a Microsoft Access Database
http://support.microsoft.com/default.aspx?scid=KB;EN-US;304932

http://www.granite.ab.ca/access/splitapp/index.htm

If you do not want normal users to be able to access the database, please
refer to the following article:

Description of how to help protect a Microsoft Access database
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q289885

Hope this is helpful. Please feel free to let's know if you have any
questions. Thank you!

Best Regards,

Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Partner Support


=====================================================

This posting is provided "AS IS" with no warranties, and confers no rights.
======================================================

 

[Chris Mills]

Many Thanks for your response, Peter.

I appreciate that you seemed to understand my concerns. And I appreciate that
you seemed to be asking for corroborating support on the issue (as though
reporting by PSS was not enough).

I have decided not to raise this issue with Microsoft now, because it applies
to what is now "obsolete versions" of Access (everything so far) and the
latest Access only supports ULS as a legacy.

Could I have done more a few years ago, whilst this issue was "active"? NO. It
is reasonable to assume someone from PSS occasionally monitors recurring
newsgroup problems, and I was the "expert" (based on nbr posts!) in notifying
the reason for "No Permission on MSysAccounts". Check it out for yourself.

I appreciate whining about ULS is rather too late now. What's gonna happen
with the next "whine", where MS notifies there's a bug and confuses that with
actually fixing it?

Thanks anyway for your considered response (I do appreciate that you read and
considered it/or me)
Chris

(I have never directly fed-back to MS via your suggested channel, but more
through the newsgroups. Thankyou for the suggestion, for what it is worth(?))

(Many of us need to know that MS or PSS takes developer feedback
seriously/even if they reject it!)