What is this all about??

[sondriven]

I just made my database "secure" with the User Level Security Wizard.

I am listed in the Admins Group. Everything is working okay. I can access all the areas.

But when I went to make a new macro and save it, I received this:

"The search key was not found in any record."

And I cant save the new macro or a query now for that matter. I was wondering what is turned off or on now after the security update.

Thanks.

 

[ElsVanMiert]

I do not think that the security system is responsible for this behaviour but the weaknesses of the macros. Try to make the same operation with VBA and everything will be perfect.

Here some arguments why macros are evil (from www.unsoftwareag.com ) :
ACCESS ONLINE ENCYCLOPEDIA Article Code: G2

Why should you avoid MACROS ?
Macros have been a great invention back in 1987. In simply recording the operations on the screen any user could create his own little programs and modify them later on.
They are ideal if you just need one functionality and if you do not want to create a real application.
Nethertheless the creation of macros requires time and effort and there is a great chance that all this investment will be lost very soon.
The reasons are multiple:

Macros do not allow any error trapping
Macros can not be debugged
Macros are inflexible
Macros are not protected in MDE files
Related topics in the USA ACCESS ENCYCLOPEDIA:
All articles in the MODULES AND VBA section.

Exceptions from the rule

The AUTOEXEC macro will be executed automatically on opening your application
The AUTOKEYS macro can check the function keys throughout the whole application

 

[sondriven]

But its not just when Im creating a macro, its happening when i go to build a query. The same exact message.

Its not Access itself because I can go to another program and add a macro or query to them with no problems.

Any insight on this would be appreciated.


Thanks.

 

[ghudson]

Check this thread out for some help with Access security...

http://www.access-programmers.co.uk/forums/showthread.php?s=&threadid=31442

HTH

 

[sondriven]

Thanks that thread had a ton of great information. I cleared up my issue with the Search Key message. But now I have a couple of things to clear up.

When the shortcut for the database was made this address is giving me a error. "The command line you used to open Access contains an option that Microsoft Access doesnt recogonize."

Heres my address:

"C:\Program Files\Microsoft Office 2000\Office\MSACCESS.EXE" "C:\Pedmic Quality Program\Pedmic Quality Program.mdb" / wrkgrp "C:\Windows\System\Secure.mdw"

I also tried this one:

"C:\Program Files\Microsoft Office 2000\Office\MSACCESS.EXE" /wrkgrp "C:\Windows\System\Secure.mdw" "C:\Pedmic Quality Program\Pedmic Quality Program.mdb"

When I try the second one, which seems like it should work gives me an error that I dont have permission to open the database.

I am set up as the Administrator.



Also, is there a faster way to enter in permissions?? Is there a SELECT ALL function or something? Just a thought.

Thanks

 

[ghudson]

I advise against putting your security file in the Windows directory. It should go in the same location as the db.

Your command line looks okay. Does it give you the logon prompt?

I take mine a step further and have the logon group name filled in like this...

"C:\Program Files\Microsoft Office\Office\msaccess.exe" /wrkgrp "C:\Databases\Test.mdw" "C:\Databases\Test.mdb" /user TestUser

I have yet to find a faster way to set up persmissions. Lot's of clicking involved.

HTH

 

[sondriven]

When the error message pops up, it gives the option to select "Ok" or "Help". Help doesnt do anything, but when I keep clicking "Ok" the database eventually opens up Normally with the password thing.

Kinda stumped on why this is. I now moved the *.MDW file into the Database Directory on the server.

I have the database set up like this. Every computer gets a copy of the Front End. That is linked to the Back End on the Server. Then on the shortcut for everyones computer,

"C:\Program Files\Microsoft Office 2000\Office\MSACCESS.EXE" "C:\Pedmic Quality Program\Pedmic Quality Program.mdb" / wrkgrp "F:\PQP\Database\Secure.mdw"

Some computers may differ depending on where their Access is located.



This is an okay way to do things right?


Thanks

 

[ghudson]

I noticed that your workgroup switch has a space after the forward slash. It should not. Try this...

"C:\Program Files\Microsoft Office 2000\Office\MSACCESS.EXE" /wrkgrp "F:\PQP\Database\Secure.mdw" "C:\Pedmic Quality Program\Pedmic Quality Program.mdb"

Ensure everything is spelled correctly.

 

[sondriven]

Thanks for the replies and sticking with me on this.

I took out the space and now I dont get the error box, but it wont let me in. "You do not have permission to view C:\Pedmic Quality Program\"

Why would this be? Im set up as the Administrator.


I do have a question about Joining Workgroups. If I join a specific group shouldnt only certain people set up for that Wrkgrp be in it?

I have two Wrkgrps now. The secure.mdw and system.mdw

When I join the System one, all the settings from Secure.mdw are there and Access still wants a password. Im kinda confused on why this is.

 

[ghudson]

You do not want to join a group. You need to rejoin the System.mdw file to get things back to normal. This assumes that you have not altered your System.mdw file. If so, I suggest that you rename your current System.mdw file and grab a clean one from another computer. The System.mdw is the default workgroup Admin. You will want to remove all permissions for the Admin group in your custom security workgroup file. Ensure you verify who the owner is for the db and all objects.

The purpose of the custom shortcuts is to give the user the security info they need to open your secured db.

If you still can not get in, then you have not given the correct permissions to the objects each group (including yourself) needs. You want to have one group for you the Programmer and any other groups and permissions you need for your users to only access and use what they need.

HTH