Accessing an Access .mdb file

[gnarlydude]

Hi,

I am trying to open a friends Microsoft Access database file but keep getting this message:

You do not have the neccessary permissions to use the C:/ blankity/blank object. Have your system administrator or the person who created this object establish the appropriate permissions for you.

There is no system admin as this is my friends laptop, nor did he create the database file. Here's the deal: the file was created by a client database management system which I assume is the culprit for setting the permissions. My friend no longer wants to use the database as is. He asked me to build him a Filemaker Pro data base and import all his data into that. I have done this before by opening up the .mdb files in Access and then exporting them to Excel and finally to Filemaker pro. With this permission problem, however, I can't even get the file to open up in Access.

Any ideas?

Thanks

Joe

[Kundinger]

Hi Joe,

It sounds like this file came from a Windows NT or Windows 2000 computer. Those operating systems have the ability of setting a diverse range of user privileges on folders and files. One user or group of users will have 'ownership' permissions, but 'everyone' can have 'none' permissions. There is a wide range of permissions between 'ownership' and 'none'.

Also, a file that is 'copy'd vs. 'move'd between two folders or volumes may have different permissions. This commonly happens with files transferred from CD's.

All of this hinges on how the permissions were setup in WINNT or WIN2K. Someone had to configure the computers... you just need to find that "someone".

Good Luck!

Bob Kundinger

[Vaughan]

Does the database have a built-in password that limits access and prevents import/export?

[gnarlydude]

Vaughan,

Not for my friend. But I do think that the program is doing something to the .mdb file to prevent it from being opened in Access. The program is a proprietary database/sales application for an insurance company. My friend is quiting this company (actually the company will be terminating his contract when they find out he also represents other insurance companies) but would like to keep his client information. And there is no exporting capability built into the application.

Any more ideas?

Joe

[Vaughan]

Errr, he'd better be very careful about "who" the client list belongs to. It could be considered theft.

[gnarlydude]

So, If this computer was set up at the home office of my friends insurance company (see other post for more info), it's possible that the .mdb files are set up to prevent any tampering? BTW, this machine is running Windows 98se.

[IdealData]

I think I'd sooner trust a second hand car delaer than this guy.

May be "gnarlydude" should reconsider his morals on this before asking the rest of us PROFESSIONALS to aid a crime !

[kraftyman]

Quite aside from the ethical/legal implications...

This is the blurb from the access help file as background

***********************

Securing database objects with user-level security

The most flexible and extensive method of securing a database is called user-level security. This form of security is similar to methods used in most network systems. The two main reasons to use user-level security are to:

Prevent users from inadvertently breaking an application by changing tables, queries, forms, reports, and macros on which the application depends.

Protect sensitive data in the database.

Under user-level security, users are required to identify themselves by an id, and then type a password when they start Microsoft Access. Within the workgroup information file, they are identified as members of a group. Microsoft Access provides two default groups: administrators (named the Admins group) and users (named the Users group), but you can define additional groups.

Although setting up user-level security on most databases can be a daunting task, the User-Level Security Wizard makes it easy to quickly secure your Access database in a one-step process. Furthermore by implementing common security schemes, the User-Level Security Wizard minimizes and even eliminates the need to use the Security command from the Tools menu.

After running the User-Level Security Wizard, you can assign or remove permissions for user and group accounts in your workgroup for a database and its existing tables, queries, forms, reports, and macros. You can also set the default permissions that Microsoft Access assigns for any new tables, queries, forms, reports, and macros that are created in a database.

Permissions are granted to groups and users to regulate how they are allowed to work with each table, query, form, report, and macro in a database. For example, members of the Users group might be allowed to view, enter, or modify data in a Customers table but not to change the design of that table. While the Users group might be allowed to only view data in a table containing order data, they might be totally denied any access to a Payroll table. Members of the Admins group have full permissions on all of a database's tables, queries, forms, reports, and macros . You can set up more fine-grained control by creating your own group accounts, assigning appropriate permissions to those groups, and then adding users to those groups.

If you only need an administrators group and users group for your security purposes, you don't need to create additional groups; you can use the default Admins and Users groups. In this case, you only need to assign the appropriate permissions to the default Users group, and add any additional administrators to the default Admins group. Any new users you add are automatically added to the Users group. Typical permissions for the Users group might include Read Data and Update Data for tables and queries, and Open/Run for forms and reports.

If you need more fine-grained control of different groups of users, you can create your own groups, assign different sets of permissions to those groups, and then add users to the appropriate groups. To simplify the management of permissions, it is recommended that you only assign permissions to groups (not users), and then add users to the appropriate groups.

Note For more information on the Microsoft Access security model, see the Microsoft Office 2000/Visual Basic Programmer's Guide.

***************

Hopefully this sheds some light. The error message has nothing to do with the operating system. If Win NT/2K/XP doesn't want to let you in, you simply get an "access denied" eror.

You are having problems because you do not have the correct information in your workgroup file ( system.mdw) to enable the .mdb to be opened by your MS Access application.

There is no simple way to remedy this, because the appropriate user name and password are not stored in the mdb file as such

You need to have the original workgroup file, which might be on your friend's computer somewhere ( look for system.mdw or other .mdw files), and then you have some hope.

On www.passware.com, you will find a legal product which will decrypt the system.mdw file and allow you to see the necessary passwords. (It is expensive, but having locked myself out of my access aplication permanantly just once, meant that I had no choice but to cough up the money....)

If you do not have the workgroup file, then methinks you are quite far up the creek. Then you might have to do some really serious binary stuff...

[gnarlydude]

Sorry, didn't mean to offend any "PROFESIONALS". As to "reconsidering my morals" I have and have come to the obvious conclusion that the clients in this database are my friends clients. He went out, worked hard and sold everyone of them without any marketing help from the insurance company in question. He placed this block of business with this company because at the time he felt this company best served the financial needs of his clients. He has since contracted with a couple of other companies which offer better rates and rate of returns and would like to be able to easily offer new products to his clients that could benefit from them. Morally this is the right thing to do because as an insurance agent he is obligated to provide access to products that best meet the financial needs of his clients.

As to who the client list belongs to, it belongs to my friend. The type of contract he has with this company does not preclude him selling for other companies only that if he does, and his production falls beneth a certain level his contract will likely be terminated and he will be required to return his laptop (which he does have the option to buy, after he returns it and the proprietary software is removed). This company has no legal claim over his client base. He is not a captive agent. They just want to make it as hard as possible for him to remove his client info because they know some of this business will be replaced. Therefore, helping me with this problem wouldn't be aiding in any crime.

Mark, if you think you would "sooner trust a second hand car delaer than this guy", you would be missing a great opportunity to do business with one of the most honest and trustworthy people I have ever known and whose integrity is, in my opinion, beyond reproach. He has over 5,000 clients who would agree with me.

Joe

[gnarlydude]

Thanks for the info, Kraftyman. I'll see if I can locate the mdw files you mentioned.

Joe

[IdealData]

It just goes to show that the way things are presented will get you all manner of presumptions.

May be he is a nice guy and deserves his rewards.

[gnarlydude]

The problem with presumptions is that they are based on incomplete information and often turn out to be incorrect. I try to stay away from presuming anything.

[janiebabes]

We had this same problem. someone else designed the db but we own it. I opened the tables with most of the information in them, exported them to excel and saved them that way for importing to FM. It's a bit fiddly but it gets you your data.

Now my problem is this - our original database is really badly designed, and I am looking at designing one in filemaker pro that gives us the information and reports I want, and allows the input I want. The trouble is, we have 13,000 files which have field names and information that are badly organised. I want to import all the information, but have different field names and probably many more fields ... I have exported our entire member base to an excel file and am renaming what field names I can but it is a complete disaster, really. I can see me having to update practically every single file in order to put the info in the right spots.

Has anyone done anything like this before, what time saving strategies did they employ and are there any hints you can give me to streamline this operation?

pax

Jane

[gnarlydude]

Jane,

What do you mean by this: " I can see me having to update practically every single file in order to put the info in the right spots."

Reanameing columns in Excel so that they match your fields in FMP doesn't seem like that big of a deal. Maybe I am missunderstanding what your haveing to do. I am writing this reply from the FileMaker developer conference and I have had a few beers so I'm probably a bit impaired. How come you have to update every single file? And what do you mean by file? I'd like to try to help but I need more info. Er, another beer?

Joe