Dear Gurus,



My company needs help!!



Our tech department is slowly transitioning our company from 

Win95/Office97 to Win2000/Office2000.  



We've got a couple of Access databases that have a lot of heavy traffic, 

and are part of our day-to-day routine.



How best to share an Access 97 database with multiple Access 2000 users, 

until everyone has Access 2000 (4Q 2002, argh!)???



We've been having lots of problems.



Someone tried this idea for me, but said it didn't work:

* Opened a blank Access 2000 database

* Linked Access 97 tables into it

* Imported the queries, forms, reports, modules from Access 97 into Access 

2000



My coworker said it didn't work because Access 2000 kept trying to open 

the '97 tables exclusively, locking everyone else out.



I also noticed in my own test that if I could get an Access 2000 user to 

open up a 97 database without converting it ONE time, that subsequently, 

she could get into the database on a shared basis.



What is UP with this, and why is it so darned difficult?!



This has become such a problem that we are now turning it into a Project 

Management task.  



So, I was wondering if anyone had any experience with this, and could 

offer any suggestions??



Tonight, I am going to try the linked 97 tables into an Access 2000 

database for a couple of employees who have volunteered to be my guinea 

pigs.  I figure if we can open up the database exclusively for just this 

evening, it'll work fine.



BUT is there a way around opening up a multi-user database exclusive for 

the one, first time??



Suggestions, anyone?



Stumped,

Susan

Hmmm...  The two version front-end both pointing at a single A97 back-end

solution has worked for me--can you give some more details on your efforts

along these lines?



If I understand you correctly, you're creating a new A2K front-end file, and

linking to the tables in the A97 back-end.  But as soon as the first A2K

user opens the A2K front-end file, that action seems to lock the A97

*back-end*, with the result that if your A97 users try to open the A97

version of the front-end file, they get error messages saying something like

the data are read-only, or that the back-end file is opened exclusively by

user <x>.  Can you say exactly what the error messages are & when they

occur?



After you convert your FE to A2K (or import all the objects), does it

compile?



Do you get a locking file (.ldb) for either or both files when the first A2K

user opens the front-end?



I know one thing that's bitten me in the past is that once you open an .mdb

exclusively in A2K, if you thereafter close & reopen Access & then reopen

the .mdb using the 'most-recently-used files' entry on the File menu, then

A2K will open the .mdb exclusively again.  To open it non-exclusively you've

got to go through File -> Open.



Let us know more about what's going on & hopefully we can help.



Cheers,



-Roy



-----Original Message-----

From: Susan Henesy [mailto:susan.henesy@w...]

Sent: Thursday, August 23, 2001 8:54 AM

To: Access

Subject: [access] Access 97/2000 Incompatibility Issues





Dear Gurus,



My company needs help!!



Our tech department is slowly transitioning our company from 

Win95/Office97 to Win2000/Office2000.  



We've got a couple of Access databases that have a lot of heavy traffic, 

and are part of our day-to-day routine.



How best to share an Access 97 database with multiple Access 2000 users, 

until everyone has Access 2000 (4Q 2002, argh!)???



We've been having lots of problems.



Someone tried this idea for me, but said it didn't work:

* Opened a blank Access 2000 database

* Linked Access 97 tables into it

* Imported the queries, forms, reports, modules from Access 97 into Access 

2000



My coworker said it didn't work because Access 2000 kept trying to open 

the '97 tables exclusively, locking everyone else out.



I also noticed in my own test that if I could get an Access 2000 user to 

open up a 97 database without converting it ONE time, that subsequently, 

she could get into the database on a shared basis.



What is UP with this, and why is it so darned difficult?!



This has become such a problem that we are now turning it into a Project 

Management task.  



So, I was wondering if anyone had any experience with this, and could 

offer any suggestions??



Tonight, I am going to try the linked 97 tables into an Access 2000 

database for a couple of employees who have volunteered to be my guinea 

pigs.  I figure if we can open up the database exclusively for just this 

evening, it'll work fine.



BUT is there a way around opening up a multi-user database exclusive for 

the one, first time??



Suggestions, anyone?



Stumped,

Susan

Hi Susan,



I am not sure why your company finds it hard to link to Access97 back-end. 

 We are using Access 20000 and Access97 front-ends connected to Access97 

and Access2.0 back-ends.  Works for us without problems.  Could you check 

to ensure that you haven't set "Default Open Mode" to Exclusive in your 

new Access2000 fron-end options.



JohnF



>>> susan.henesy@w... 24/08/2001 1:53:46 >>>

Dear Gurus,



My company needs help!!



Our tech department is slowly transitioning our company from

Win95/Office97 to Win2000/Office2000. 



We've got a couple of Access databases that have a lot of heavy traffic,=20



and are part of our day-to-day routine.



How best to share an Access 97 database with multiple Access 2000 

users,

until everyone has Access 2000 (4Q 2002, argh!)???



We've been having lots of problems.



Someone tried this idea for me, but said it didn't work:

* Opened a blank Access 2000 database

* Linked Access 97 tables into it

* Imported the queries, forms, reports, modules from Access 97 into 

Access

2000



My coworker said it didn't work because Access 2000 kept trying to open

the '97 tables exclusively, locking everyone else out.



I also noticed in my own test that if I could get an Access 2000 user 

to

open up a 97 database without converting it ONE time, that subsequently,=20



she could get into the database on a shared basis.



What is UP with this, and why is it so darned difficult?!



This has become such a problem that we are now turning it into a Project=20



Management task. 



So, I was wondering if anyone had any experience with this, and could

offer any suggestions??



Tonight, I am going to try the linked 97 tables into an Access 2000

database for a couple of employees who have volunteered to be my guinea

pigs.  I figure if we can open up the database exclusively for just 

this

evening, it'll work fine.



BUT is there a way around opening up a multi-user database exclusive 

for

the one, first time??



Suggestions, anyone?



Stumped,

Susan

Hi everyone,



Great news!  I have no problems!



I think the only problem I had was not personally having access to Access 

2000 during this whole time.  As THE Access/ASP/VB developer here, you'd 

think they'd let me get a lot more hands-on, eh?  Instead, everyone was 

calling me with their problems, to which I could only offer hypothetical 

solutions.



During the past 2 days, I had the good fortune of having a coworker attend 

an Access 2000 class, during which, he emailed advice from the instructor 

to me.  I quickly got hip to the "Convert Database/Database Splitter/Old 

Database as Back-End" methodology.



Another coworker with Access 2000 let me monopolize his computer 

yesterday.  We went through the recommended steps without a hitch.



So!  Ha!  BUH-BYE, Project Management!  :)



For me, anyway.  I know another developer who is having MAJOR headaches.  

She designed an Access '97 program complete with Security and some 

other "features" (such as hiding the database window, built-in menus, etc 

etc etc), and according to some people who've been working with her, she 

CAN'T convert the thing to 2000 AND everyone is convinced that the whole 

program will have to be redesigned from scratch.



Sorry, but I just ain't buying that.



Now, as a rule, I eschew Access Security.  I haven't got all day to 

maintain Admin/User lists, which would be a full-time job in and of 

itself.  Since I avoid such complications, my problem had a simple 

solution.



But does anyone know how to advise this developer?  



All input is great appreciated!  Considering that discussion of this topic 

has actuallyb resulted in raised voices. Them: "We CAN'T convert the 

database!! It HAS to be redesigned! From SCRATCH!!!"  Me:  "That's 

LUDICROUS!"  etc.



Fun, fun, fun, with the dysfunctionals! :)





Susan

Susan,



What problem does she get when trying to convert the DB?



Yehuda



-----Original Message-----

From: Susan Henesy [mailto:susan.henesy@w...]

Sent: Friday, August 24, 2001 1:00 PM

To: Access

Subject: [access] Re: Access 97/2000 Incompatibility Issues





Hi everyone,



Great news!  I have no problems!



I think the only problem I had was not personally having access to

Access

2000 during this whole time.  As THE Access/ASP/VB developer here, you'd



think they'd let me get a lot more hands-on, eh?  Instead, everyone was

calling me with their problems, to which I could only offer hypothetical



solutions.



During the past 2 days, I had the good fortune of having a coworker

attend

an Access 2000 class, during which, he emailed advice from the

instructor

to me.  I quickly got hip to the "Convert Database/Database Splitter/Old



Database as Back-End" methodology.



Another coworker with Access 2000 let me monopolize his computer

yesterday.  We went through the recommended steps without a hitch.



So!  Ha!  BUH-BYE, Project Management!  :)



For me, anyway.  I know another developer who is having MAJOR headaches.



She designed an Access '97 program complete with Security and some

other "features" (such as hiding the database window, built-in menus,

etc

etc etc), and according to some people who've been working with her, she



CAN'T convert the thing to 2000 AND everyone is convinced that the whole



program will have to be redesigned from scratch.



Sorry, but I just ain't buying that.



Now, as a rule, I eschew Access Security.  I haven't got all day to

maintain Admin/User lists, which would be a full-time job in and of

itself.  Since I avoid such complications, my problem had a simple

solution.



But does anyone know how to advise this developer? 



All input is great appreciated!  Considering that discussion of this

topic

has actuallyb resulted in raised voices. Them: "We CAN'T convert the

database!! It HAS to be redesigned! From SCRATCH!!!"  Me:  "That's

LUDICROUS!"  etc.



Fun, fun, fun, with the dysfunctionals! :)





Susan

Hey Susan,



Glad to hear your problems are solved.



As for your collegue, I believe you can create an un-secured version of a

secured mdb by



1) Starting access using the same .mdw file where 

   the secured mdb accounts live, logging in under

   an account w/admin perms on the mdb and all its 

   objects.

2) Rather than open the secured .mdb, create a new 

   blank database (File->New).

3) Import all objects from the secured .mdb into the

   new .mdb.



I'm going from memory there, but I believe it will work--give it a whirl.



Assuming that is the reason for her conversion difficulty, she should be

set.  If not, hit us w/more details on the trouble & maybe we can be of

help.



The only reason I can think of off the top of my head for absolutely needing

to redevelop an app from scratch would be if she compiled to an .mde file

and then discarded the corresponding .mdb.



BTW, access security isn't so bad--especially with A2K's wizard.  And

sometimes it's the only way to control those pesky users... 8^)



Cheers,



-Roy





-----Original Message-----

From: Susan Henesy [mailto:susan.henesy@w...]

Sent: Friday, August 24, 2001 10:00 AM

To: Access

Subject: [access] Re: Access 97/2000 Incompatibility Issues





Hi everyone,



Great news!  I have no problems!



I think the only problem I had was not personally having access to Access 

2000 during this whole time.  As THE Access/ASP/VB developer here, you'd 

think they'd let me get a lot more hands-on, eh?  Instead, everyone was 

calling me with their problems, to which I could only offer hypothetical 

solutions.



During the past 2 days, I had the good fortune of having a coworker attend 

an Access 2000 class, during which, he emailed advice from the instructor 

to me.  I quickly got hip to the "Convert Database/Database Splitter/Old 

Database as Back-End" methodology.



Another coworker with Access 2000 let me monopolize his computer 

yesterday.  We went through the recommended steps without a hitch.



So!  Ha!  BUH-BYE, Project Management!  :)



For me, anyway.  I know another developer who is having MAJOR headaches.  

She designed an Access '97 program complete with Security and some 

other "features" (such as hiding the database window, built-in menus, etc 

etc etc), and according to some people who've been working with her, she 

CAN'T convert the thing to 2000 AND everyone is convinced that the whole 

program will have to be redesigned from scratch.



Sorry, but I just ain't buying that.



Now, as a rule, I eschew Access Security.  I haven't got all day to 

maintain Admin/User lists, which would be a full-time job in and of 

itself.  Since I avoid such complications, my problem had a simple 

solution.



But does anyone know how to advise this developer?  



All input is great appreciated!  Considering that discussion of this topic 

has actuallyb resulted in raised voices. Them: "We CAN'T convert the 

database!! It HAS to be redesigned! From SCRATCH!!!"  Me:  "That's 

LUDICROUS!"  etc.



Fun, fun, fun, with the dysfunctionals! :)





Susan

Hi Yehuda,

 

> What problem does she get when trying to convert the DB?



I don't know yet.  They haven't adequately explained that part yet.  What 

I can try to do is get more information at our next meeting, though.  I'll 

make sure I get a list of all the things they've tried (if they'll tell 

me!).  I'll suggest the Convert/Split/Back-end method (and provide them 

with the Help file), and see what happens then.  My coworker's instructor 

did mention that Access Security might hamper some of this, but I didn't 

get specifics out of him on that.



I'll write more when I have more!



Susan

Dear Roy,



This sounds like very good advice:

> 1) Starting access using the same .mdw file where 

>    the secured mdb accounts live, logging in under

>    an account w/admin perms on the mdb and all its 

>    objects.

> 2) Rather than open the secured .mdb, create a new 

>    blank database (File->New).

> 3) Import all objects from the secured .mdb into the

>    new .mdb.



Now I have just one question for you.  How to reapply Security after the 

two front-ends have been created?  Just point both the '97 and 2000 front-

ends to the same *.mdw file, I hope?  That way Security might not have to 

be redone from scratch.



Would it be complicated to do that in '97 and 2000?  And I wonder what the 

differences would be like to set each database to the correct *.mdw file.  

Oh, complexities, complexities!  I STILL dislike Security (though my newly 

educated coworker did just tell me that A2K has a feature that lets other 

people handle the User Group lists -- nice!  But I still think it's icky, 

will only use when absolutely necessary.)



Susan

Ah, I didn't realize you needed to support multiple versions & still

maintain security.  That's likely more complicated (I've never had to do it

myself).  There's some stuff in A2K help--search for "About converting or

enabling a secured database from a previous version of Microsoft Access".  



See also the whitepaper at:



http://support.microsoft.com/directory/article.asp?id=kb;en-us;Q237313



If my cursory read of the help topic "Share a previous-version secured

database across several versions of Microsoft Access" can be trusted, it

seems that A2K can use an A97 version .mdw file.  So you may not want to

bother un-securing the database...



Good luck,



-Roy



-----Original Message-----

From: Susan Henesy [mailto:susan.henesy@w...]

Sent: Friday, August 24, 2001 12:25 PM

To: Access

Subject: [access] Re: Access 97/2000 Incompatibility Issues





Dear Roy,



This sounds like very good advice:

> 1) Starting access using the same .mdw file where 

>    the secured mdb accounts live, logging in under

>    an account w/admin perms on the mdb and all its 

>    objects.

> 2) Rather than open the secured .mdb, create a new 

>    blank database (File->New).

> 3) Import all objects from the secured .mdb into the

>    new .mdb.



Now I have just one question for you.  How to reapply Security after the 

two front-ends have been created?  Just point both the '97 and 2000 front-

ends to the same *.mdw file, I hope?  That way Security might not have to 

be redone from scratch.



Would it be complicated to do that in '97 and 2000?  And I wonder what the 

differences would be like to set each database to the correct *.mdw file.  

Oh, complexities, complexities!  I STILL dislike Security (though my newly 

educated coworker did just tell me that A2K has a feature that lets other 

people handle the User Group lists -- nice!  But I still think it's icky, 

will only use when absolutely necessary.)



Susan

Hi again Roy,



You can nix the question about Security!  I spoke to the developer and she 

didn't use Security -- she just used a table, made up of numbers and 

passwords.  Then used the STARTUP menu to hide all of Access's features.  

Like me, she hates Security and will do anything not to use it, lol!



It is not she who's had problems with conversion -- she hasn't had time to 

futz with it, and wasn't even aware there was an issue.  Looks like it was 

a bunch of non-techies who panicked and decided to conduct their own 

experiments.  Poor things, they were desperate!  I hope to advise them of 

doing "The Database Split", per the Access 2000 Help Files, which ought to 

be the answer to their prayers.



Thanks again to everyone for your help!  I don't know what I'd do without 

P2P :).



Susan

A year or two ago, I decided I didn't like Access's security features.



Generally, this is what I do now: (I am by no means an authority, this is

free, so take it for what it's worth)



I work with whoever the network guy/girl is for the company and write a VB

script that will make a call to NT or Novell (network) and tells me the

identity of who is currently trying access the DB.



This is done in the front-end's splash screen.



If that user exists in the table I have built keeping track of who has

access, then it will proceed to link the DB to it's various back-ends.



At that time, I also load who they are, and what security level the are up

on Public variables. That way I can test throughout the rest of the

application with out having to re-initialize.



Another feature to this approach is that it is one less login password your

users will need to remember. If they got onto your network, you should be

fairly confident they belong there.



Having a table and then having my user id's carried on a public variable

allows me to write rules at the individual control level on my forms,

without having to drag an .mda around with the app.



I can have one person that logs into a form and sees X number of buttons,

and another that goes to the same form and sees something completely

different.



It can be a nice little (rough example)(I use SELECT CASE on a lot of these

too)



On Load ()



IF strSECVar = "Administrator"



me.cmdSelfdestruct.enabled = true



ELSE



me.cmdSelfDestruct.enabled = false



EndIf



This is a really nice feature because now your letting the network handle

security for you as opposed to MS Access. It's also a nice way to CYA, if

there is a break-in, the powers that be will not be lookin' at you with

your cryptic MS Access security routine complete with multiple conflicting

mdw's.



They'll need to talk to Op's instead.



I can also use the variables I have to insert their id's into recordsets

when they make changes almost the same as using the CurrentUser() function

by substituting my public var I set at start-up.



If the user does not exist in your table, you just "DoCmd.Quit" end of

story.



When you have your final build ready, make the front end a .mde so that

someone can't interrupt/modify the code. The only table in that front end

is the security table, even that I would have as a database passworded

link.



There are ways to beat it, but whoever is trying to crack it will have to

be pretty darn tech savvy.



Depending on the network security you have, this may not be an attractive

option.



As far as protecting the back-ends, you can set up a database password on

them all. The front-end can pass the password as it's linking up.



The first couple of times using this approach were difficult, but now it's

no sweat, I wouldn't do it any other way.



Good luck,

Dear BPulliam,



My goodness, what an ingenious, nifty workaround!  It comes in very 

timely, too -- my favorite instructor has just confessed that she is 

uneasy about Access 2000's security features.  Something about it being 

difficult to override once it's been setup (I believe this has something 

to do with the whole Control Freak Method of Microsoft 2000 in general -- 

it isn't truly recognizing ADMIN as ADMIN, but as just another ADMIN in a 

big ADMINS Group in MySystem.mdw, NOT SYSTEM.MDW.)



I've just circulated your note to all my fellow developers.  DEFINITELY 

something to think about for the next project that warrants it!  



Much obliged,

Susan

For my money, the main reason not to use Access security is that it's too

easy to crack (or so I am told anyway).  There's probably a decent argument

to be made against using Access for security sensitive applications in

general (since you've got to give users access to the actual .mdb file, and

it's typically not hard to just walk away with the whole shebang on some

sort of removable media).  Compare a server database, where users typically

don't have physical access to the machine where the data files are located,

and they can be very locked down since only the server process needs to have

access.



I don't think you need to roll your own security scheme to achieve the

advantages described below (w/the possible exception of the single sign-on

bit--I'm not sure how you would do that w/Access' native security routines).

You can programmatically determine the currently logged in user with the

CurrentUser() function, and the DAO model offers good programmatic access to

group membership and group permissions.  So, if you need to do things like

show or hide controls on the basis of who the current user is, you can do

it.  If you don't need to get that granular, you can do quite a bit of

access controlling without having to code (and document and maintain) your

own scheme...



Anyway, just my $.02.



Cheers,



-Roy





-----Original Message-----

From: BPulliam@B... [mailto:BPulliam@B...]

Sent: Friday, August 24, 2001 1:55 PM

To: Access

Subject: [access] Re: Access 97/2000 Incompatibility Issues





A year or two ago, I decided I didn't like Access's security features.



Generally, this is what I do now: (I am by no means an authority, this is

free, so take it for what it's worth)



I work with whoever the network guy/girl is for the company and write a VB

script that will make a call to NT or Novell (network) and tells me the

identity of who is currently trying access the DB.



This is done in the front-end's splash screen.



If that user exists in the table I have built keeping track of who has

access, then it will proceed to link the DB to it's various back-ends.



At that time, I also load who they are, and what security level the are up

on Public variables. That way I can test throughout the rest of the

application with out having to re-initialize.



Another feature to this approach is that it is one less login password your

users will need to remember. If they got onto your network, you should be

fairly confident they belong there.



Having a table and then having my user id's carried on a public variable

allows me to write rules at the individual control level on my forms,

without having to drag an .mda around with the app.



I can have one person that logs into a form and sees X number of buttons,

and another that goes to the same form and sees something completely

different.



It can be a nice little (rough example)(I use SELECT CASE on a lot of these

too)



On Load ()



IF strSECVar = "Administrator"



me.cmdSelfdestruct.enabled = true



ELSE



me.cmdSelfDestruct.enabled = false



EndIf



This is a really nice feature because now your letting the network handle

security for you as opposed to MS Access. It's also a nice way to CYA, if

there is a break-in, the powers that be will not be lookin' at you with

your cryptic MS Access security routine complete with multiple conflicting

mdw's.



They'll need to talk to Op's instead.



I can also use the variables I have to insert their id's into recordsets

when they make changes almost the same as using the CurrentUser() function

by substituting my public var I set at start-up.



If the user does not exist in your table, you just "DoCmd.Quit" end of

story.



When you have your final build ready, make the front end a .mde so that

someone can't interrupt/modify the code. The only table in that front end

is the security table, even that I would have as a database passworded

link.



There are ways to beat it, but whoever is trying to crack it will have to

be pretty darn tech savvy.



Depending on the network security you have, this may not be an attractive

option.



As far as protecting the back-ends, you can set up a database password on

them all. The front-end can pass the password as it's linking up.



The first couple of times using this approach were difficult, but now it's

no sweat, I wouldn't do it any other way.



Good luck,

 

  Dear Sir or Madam,

Problem - If table is erased from main table, and in form why am I 

recieving a message "Enter Parameter Value" - how do I locate SQL Language 

triggering this mistake.

and how do I avoid this problem in the future?

Access security is very easy to crack.  I have written a small program in 

Authorware (just for fun) that will break any Access secured database.  It 

took me few minutes to write the program (one function)  once I found out 

the method used by Microsoft to inforce security.  Using Novell security 

and .mde files is a hell of a better option.



>>> roy.e.pardee@l... 28/08/2001 4:06:22 >>>

For my money, the main reason not to use Access security is that it's too

easy to crack (or so I am told anyway).  There's probably a decent argument

to be made against using Access for security sensitive applications in

general (since you've got to give users access to the actual .mdb file, and

it's typically not hard to just walk away with the whole shebang on some

sort of removable media).  Compare a server database, where users typically

don't have physical access to the machine where the data files are located,

and they can be very locked down since only the server process needs to 

have access.



I don't think you need to roll your own security scheme to achieve the

advantages described below (w/the possible exception of the single sign-on

bit--I'm not sure how you would do that w/Access' native security 

routines).

You can programmatically determine the currently logged in user with the

CurrentUser() function, and the DAO model offers good programmatic access 

to group membership and group permissions.  So, if you need to do things 

like show or hide controls on the basis of who the current user is, you 

can do it.  If you don't need to get that granular, you can do quite a bit 

of access controlling without having to code (and document and maintain) 

your own scheme...



Anyway, just my $.02.



Cheers,



-Roy





-----Original Message-----

From: BPulliam@B... [mailto:BPulliam@B...]

Sent: Friday, August 24, 2001 1:55 PM

To: Access

Subject: [access] Re: Access 97/2000 Incompatibility Issues





A year or two ago, I decided I didn't like Access's security features.



Generally, this is what I do now: (I am by no means an authority, this is

free, so take it for what it's worth)



I work with whoever the network guy/girl is for the company and write a VB

script that will make a call to NT or Novell (network) and tells me the

identity of who is currently trying access the DB.



This is done in the front-end's splash screen.



If that user exists in the table I have built keeping track of who has

access, then it will proceed to link the DB to it's various back-ends.



At that time, I also load who they are, and what security level the are up

on Public variables. That way I can test throughout the rest of the

application with out having to re-initialize.



Another feature to this approach is that it is one less login password your

users will need to remember. If they got onto your network, you should be

fairly confident they belong there.



Having a table and then having my user id's carried on a public variable

allows me to write rules at the individual control level on my forms,

without having to drag an .mda around with the app.



I can have one person that logs into a form and sees X number of buttons,

and another that goes to the same form and sees something completely

different.



It can be a nice little (rough example)(I use SELECT CASE on a lot of these

too)



On Load ()



IF strSECVar = "Administrator"



me.cmdSelfdestruct.enabled = true



ELSE



me.cmdSelfDestruct.enabled = false



EndIf



This is a really nice feature because now your letting the network handle

security for you as opposed to MS Access. It's also a nice way to CYA, if

there is a break-in, the powers that be will not be lookin' at you with

your cryptic MS Access security routine complete with multiple conflicting

mdw's.



They'll need to talk to Op's instead.



I can also use the variables I have to insert their id's into recordsets

when they make changes almost the same as using the CurrentUser() function

by substituting my public var I set at start-up.



If the user does not exist in your table, you just "DoCmd.Quit" end of

story.



When you have your final build ready, make the front end a .mde so that

someone can't interrupt/modify the code. The only table in that front end

is the security table, even that I would have as a database passworded

link.



There are ways to beat it, but whoever is trying to crack it will have to

be pretty darn tech savvy.



Depending on the network security you have, this may not be an attractive

option.



As far as protecting the back-ends, you can set up a database password on

them all. The front-end can pass the password as it's linking up.



The first couple of times using this approach were difficult, but now it's

no sweat, I wouldn't do it any other way.



Good luck,

Hi Roy,



> For my money, the main reason not to use Access security is that it's too

> easy to crack (or so I am told anyway).  There's probably a decent 

argument

> to be made against using Access for security sensitive applications in

> general (since you've got to give users access to the actual .mdb file, 

and

> it's typically not hard to just walk away with the whole shebang on some

> sort of removable media



It's funny you should say this.  I discovered today that the database that 

was supposedly secure via disablement of various Access features (no 

shortcut menus, no built-in menus, etc.) is actually extremely easy to get 

into.  All I had to do was create a blank database and import all the 

objects from the "secure" database into mine.  Bingo, I've got access to 

all the tables, queries, forms, reports, etc.!  I haven't told the 

managers about this -- they'll freak out, and it's *possibly* not an 

issue.  Besides, I wanted to let the developer know about it first.   



So, this topic of conversation came up this evening, and my S.O. said that 

Access Security can probably be cracked into as well.  Since I've done my 

best to avoid it, that hadn't occurred to me. You'd hope that your 

employees would have better things to do than devise ways to crack 

Security, but at times of low morale, anything's possible.



I tend to develop databases that don't contain sensitive data.  When they 

do, I find other ways of avoiding leaks in confidentiality (probably out 

of sheer laziness more than anything else).  One of my early employee 

databases just had a password on it, and only a handful of people with the 

proper authority were given the password (one manager and two assistants, 

actually).  A financial database that gets monthly updates is zipped up 

and distributed to Financial Analysts, who use their copies of the 

database to do some independent studies, then distribute hardcopies of 

reports to appropriate parties.



A newer employee database that I am still developing sits on a server, and 

will be updated via a combination monthly PeopleSoft reports and Active 

Server Pages.  Nothing in this database is sensitive, it just contains 

current public info about an employee -- what team they're on, who they 

report to, what location they exist in, etc.  Any employee can visit the 

web site and download a dynamic Excel spreadsheet that can then be used 

for other projects.  Or they can just use the ASP pages to see who works 

on what team.  I have the core tables from this database linked into 

several of my confidential databases kept on my C drive.  This then makes 

the "public" employee database modular, a non-sensitive tool that can be 

inserted into other more sensitive projects.



If I were to develop a database that required Security, I think you're 

right -- the best way to go would be an ASP site with cookies.  

The "secure" database that I've now discovered is not-so-secure was 

already slated as a perfect candidate for ASP, as its scope is going to be 

broader than one location.  Little do the managers know how much they NEED 

this developed in ASP!



I'm really glad I started this thread -- the advice I've gotten has been 

terrific!



Susan

Either the form itself, or some recordsource of a control on the form (maybe

a combo box?) is probably based on a query that has a missing field or

parameter.



How to avoid it? Go to www.rickworld.com and get Find and Replace. It should

help a lot as you could search the entire database schema for any value.



Peter



> -----Original Message-----

> From: Kenneth Mungwira [mailto:kennethmungwira@y...]

> Sent: August 28, 2001 12:47 AM

> To: Access

> Subject: [access] Re: Access 97/2000 Incompatibility Issues

>

>

>

>   Dear Sir or Madam,

> Problem - If table is erased from main table, and in form why am I

> recieving a message "Enter Parameter Value" - how do I locate SQL

> Language

> triggering this mistake.

> and how do I avoid this problem in the future?

>

>

Kenneth,



Enter Parameter Value means you have a name in there it does not

recognize.  Probably you have to remove then names of fields from the

deleted table.  Remove the references to these fields from the form.

This will happen any time you are referencing fields from a table and

the table is deleted or some of the fieldnames change.



Yehuda



-----Original Message-----

From: Kenneth Mungwira [mailto:kennethmungwira@y...]

Sent: Monday, August 27, 2001 1:47 PM

To: Access

Subject: [access] Re: Access 97/2000 Incompatibility Issues







  Dear Sir or Madam,

Problem - If table is erased from main table, and in form why am I

recieving a message "Enter Parameter Value" - how do I locate SQL

Language

triggering this mistake.

and how do I avoid this problem in the future?