BackEnd Question

[David W]

I need a way to keep people from opening the backend database files except
when they use the frontend.
I have a split system that works fine, the database are connected via mapped
drive from each pc(no server software here).
The issues is when someone opens the mapped drive from there pc, they can
open the backend files and do whatever.
I am going to ask a silly question<<<
Are you supposed to make the backend a mde or is there something that I
havent seen yet?

Thanks for responding
David W

 

[Guest]

You could apply security to the database. There is a simple way provided
your users don't know about holding the shift key down to bypass startup
options. That is to create a macro named Autoexec with one line to quit the
database. As soon as it opens, it closes again. It does not affect users
attaching from a front end.

 

[fredg]

I need a way to keep people from opening the backend database files except
when they use the frontend.
I have a split system that works fine, the database are connected via mapped
drive from each pc(no server software here).
The issues is when someone opens the mapped drive from there pc, they can
open the backend files and do whatever.
I am going to ask a silly question<<<
Are you supposed to make the backend a mde or is there something that I
havent seen yet?

Thanks for responding
David W

Why not just hide the tables.
What they can't see they can't fiddle with.

Select a table. Right-click properties. Check the Hidden check box.

Just don't tell them how to unhide the tables.
Tools + Options + View
Place a check mark in the Hidden objects box.

 

[David W]

If its hidden, is there an issue with the frontend connecting. or will the
frontend see the files on the mapped drive?

Next, if you select the hidden attribute on the pc where the data resides,
will all of the mapped networks hide the files as well?

 

[Roger Carlson]

This may or may not help you, but I want to rant here <grin>

I have a philosophical problem with using security to keep people from
mucking around in a database. If actual data confidentiality is involved,
sure, add security. But just to keep people from doing something you've
told them not to do -- no. If they do something they've been told not to
do, you fire them. Simple as that.

It is generally accepted that men are not to go into the women's restroom
except under controlled conditions (ie janitorial staff). We don't make
people badge into the restrooms and refuse to open the door if they are not
of the appropriate gender. If we discover a man who habitually enters the
women's restroom, we fire him.

In short, I believe this is a management issue, not a security issue. If
users habitually use your software in unapproved ways, you warn them once,
then the discipline escalates by whatever policy your company follows. Of
course, you have to catch them

To do this, I would use an AutoExec macro which runs code that records the
user's name in a log table. This will catch all but the most determined.
My experience has been when you make people aware that they could face
disciplinary action, they stop mucking around.

Just my opinion.

--
--Roger Carlson
Access Database Samples: www.rogersaccesslibrary.com
Want answers to your Access questions in your Email?
Free subscription:
http://peach.ease.lsoft.com/scripts/wa.exe?SUBED1=ACCESS-L

 

[Guest]

Roger,
I will not disagree with your philosophy regarding action against those who
transgress, but I cannot agree with expecting that threats will avoid misuse
of a database. Security has to be an issue that includes dependance on the
sensitivity of the data. I can name three cases where major loss of data
actually caused the business to go under. One was an insurance company where
two disiplined employees deleted all the company's data including backups.
One was a marine supply company where an inadvertant error by a user who was
not as competent as he though he was wiped out their data. They were also
lax about backups and could not reconstruct any data. The last I saw on
television, but I don't recall the details. The company eventually survived,
but at about 1/4 their original capacity.

Were security not important, there would not be so much attention to it.

 

[David W]

My feelings mutual.

People are always trying to belittle others.

But I have to have HARD PROOF.

Never have dealt with macros, only VBA.
======================================

A few Questions-
How do you create a macro to record the users/ pc name/ with a date stamp
when they open the database file?
Will the macro not trigger when the frontend opens the file?
Where do you put the log, and is there way to get my attention when it
happens?

======================================
As you can tell, I never have made a macro, so I might need a little help.

 

[Guest]

I never use macros. If I run across a database with macros, I convert them
to code. Macros are only for users who do not know VBA and want to set up
simple repetitive tasks. I consider them "training wheels"

 

[David W]

Alright, my kinda people.

I found some info on MS web sight about an Autoexec Marco.
I made my own function and called it with an autoexec macro, how do you call
the function through VB when the database opens?

I fiqured out the log and the prompt of a breach.
Thanks
David

 

[Guest]

There you have a valid use for a macro. For Startup, there are only two
options. A macro named Autoexec or a form or data access page. If you have
a form that you want to open on startup, put your function in the On Load
event.

 

[Douglas J Steele]

Just for the record, the other valid use for a macro is the AutoKeys macro,
which lets you remap the meaning of specific key strokes.

Other than that, I never use macros.

 

[Guest]

You are correct, but I have a mental block regarding remapping keystrokes. I
seem to get into trouble when I do that.

 

[Albert D.Kallal]

First, you should not be using mapped drives, but unc path names

\\servername\accessstuff\mydata.mdb

(drive mapping is flakey, and can change when some plugs in a usb devoice
such as a jump drive, or memory stick.).

Anyway, what I do to keep people out is simply put in a autoexec macro (or,
you could even use a startup form).

The macro runs, and simply states to the user that they don't have
permissions to run the file..they click ok, and the application quits.

I find that 99% of the time this message fools them..and makes them not try
end open the BE.

The AutoExec macro can look like:

Msgbox:
Options: Message "You do not have permissions to use this file"
Beep: Yes
Type: Critical
Title: Can not run

the 2nd command in the macro is:

Quit:
Options: Exit

Now, when users click on the database, the get the above message..and they
are then thrown out of the database.

Nothing could be more simple then the above...and it is easy.

Further, if users DO learn about using the shift by-pass key, then simply
turn off the shift key with my following shift key utility here:

(the above utility simply lets your browse to a access file, and enable, or
disable the shift key...)

As the old cereal commercial says...

try it....you will like it....

So, give the above a try......

 

[Roger Carlson]

Well, I don't insist upon it. And I DID mention confidentiality of data as
being a valid reason for security.

However, security measures just to stop people from doing stupid things or
deliberately doing things they know they're not suppose to? No. The
examples you site can be done by non-computer methods as well. A
disgruntled employee could set fire to your filing cabinets or throw files
in the dumpter. An incompent employee could wipe out all your records by
accidentally triggering the sprinkler system. These are risks any business
takes and the real solution is a current backup and an offsite copy, not
making sure everything is idiot/villian-proof.

You hire competent, honest people to do the job to the best of their
abilities. You let them go if they don't.

Another example. You don't require everyone to lock their desks in an
office just to make sure that employees don't steal from each other. If you
have confidential information in a desk drawer, sure. That makes sense.
But not just on the chance that you have a thief. You try to catch the
thief and then let him go. You set up hidden cameras and the like. The
code I suggested is similar. If they get around that, you could put spyware
on machines until the perpetrator is caught.

Still, as I said, this is just my philosophy. I believe it is ultimately a
management issue and not a security issue.

--
--Roger Carlson
Access Database Samples: www.rogersaccesslibrary.com
Want answers to your Access questions in your Email?
Free subscription:
http://peach.ease.lsoft.com/scripts/wa.exe?SUBED1=ACCESS-L

 

[Roger Carlson]

The only line in the AutoExec macro will be a RunCode action that will run
the VB function (it HAS to be a function, not a subroutine)

Here: http://www.mvps.org/access/api/api0008.htm you can find code that
will report the user name. I guess I would execute an Append query to a
table that wrote the user name and the date to a table. It needn't be in
that database either. You could append a record to a table in a separate
database. Something like this:

1) Create a table called tblUserLog with two fields UserLog (text) and
DateStamp (date/time)

2) Put the following in a module:
'****************************
Option Compare Database
Option Explicit
Private Declare Function GetUserName Lib "ADVAPI32.dll" Alias "GetUserNameA"
(ByVal lpBuffer As String, nSize As Long) As Long

Public Function LogUser()
CurrentDb.Execute "INSERT INTO tblUserLog (UserLog, DateStamp) VALUES
(GetCurrentUserName(), Now());"
End Function

Public Function GetCurrentUserName() As String
On Error GoTo Err_GetCurrentUserName
Dim lpBuff As String * 25
Dim ret As Long, Username As String
ret = GetUserName(lpBuff, 25)
Username = Left(lpBuff, InStr(lpBuff, Chr(0)) - 1)
GetCurrentUserName = Username & ""

Exit_GetCurrentUserName:
Exit Function

Err_GetCurrentUserName:
MsgBox Err.Description
Resume Exit_GetCurrentUserName
End Function
'****************************

3) Create a macro named AutoExec with one action:

RunCode
LogUser ()

That's about it. When anyone opens the database, it gets logged.

And no, opening the Front-End database will not trigger the macro.


--
--Roger Carlson
Access Database Samples: www.rogersaccesslibrary.com
Want answers to your Access questions in your Email?
Free subscription:
http://peach.ease.lsoft.com/scripts/wa.exe?SUBED1=ACCESS-L

 

[David W]

Having a little problem
What do I need to save as the modules name?
I tried

LogUser

I made a macro to run the module, LogUser and got an error, I tried to run
GetCurrentUserName with no prevail
Suggestions?
Is there a way to get the following

IP Address
User Name (if any)
PC Name

 

[Douglas J Steele]

The name of the module cannot be the same as any routines in it. Since Roger
named the function GetCurrentUserName, you cannot name the module that.

To avoid problems like this, I always prefix my Modules with mdl, so that
I'd use mdlGetCurrentUserName. (Others use mod or bas as a prefix)