Reputation: 26993

Building an auditing system; MS Access frontend on SQL Server backend

So basically I'm building an app for my company and it NEEDS to be built using MS Access and it needs to be built on SQL Server.

I've drawn up most of the plans but am having a hard time figuring out a way to handle the auditing system.

Since it is being used internally only and you won't even be able to touch the db from outside the building we are not using a login system as the program will only be used once a user has already logged in to our internal network via Active Directory. Knowing this, we're using a system to detect automatically the name of the Active Directory user and with their permissions in one of the DB tables, deciding what they can or cannot do.

So the actual audit table will have 3 columns (this design may change but for this question it doesn't matter); who (Active Directory User), when (time of addition/deletion/edit), what (what was changed)

My question is how should I be handling this. Ideally I know I should be using a trigger so that it is impossible for the database to be updated without an audit being logged, however I don't know how I could grab the Active Directory User that way. An alternate would be to code it directly into the Access source so that whenever something changes I run an INSERT statement. Obviously that is flawed because if something happens to Access or the database is touched by something else then it will not log the audit.

Any advice, examples or articles that may help me would be greatly appreciated!

Upvotes: 4

Answers (11)

Ricardo C

Reputation: 2244

My solution would be not to let Access modify the data with linked tables.

I would only create the UI in Access and create an ADO connection to the server using windows authenticated in the connection string. Compile you Access application as dbe to protect the VB code.

I would not issue SQL statement, but I would call stored procedures to perform the changes in the database, and create the audit log entry in an atomic transaction.

The UI (Access) does not need to know the inner works on the server. All it needs to do is request and update/insert/delete using the stored procedures you would create for this purpose. The server should handle the work.

Retrieve a record set with ADO using a view with the hint NOLOCK implemented in the server and cache this data in Access for local display. Or retrieve a single record and lock only that row for editing.

Using linked tables your users will be locking each other.

With ADO connections you will not have the trouble to set ODBCs on every single client.

Create a table to set the server status. You application will check it before any action. you can use it to close the server to the application in case that you need to perform changes or maintenance.

Access is a great tool. But it should only handle its local data and not be allowed to mess with the precious server.

Upvotes: 0

Mark Plumpton

Reputation: 557

We also have a database system that is used exclusively within the organisation and use Window NT logins. This function returns the current users login name:

CREATE FUNCTION dbo.UserName() RETURNS varchar(50)
AS
    BEGIN
    RETURN  (SELECT nt_username FROM master.dbo.sysprocesses WHERE spid = @@SPID)
    END

You can use this function in your triggers.

Upvotes: 1

Kev

Reputation: 119826

How many users of the app will there be? Is there possibility of using windows integrated authentication for SQL authentication?

Updated: If you can give each user a SQL login (windows integrated) then you can pickup the logged on user using the SYSTEM_USER function.

Upvotes: 0

Jay Mooney

Reputation: 2256

Ok, it's working here. I'm seeing my windows credentials when I update my tables. So, I bet we missed a step. Let me put together a 1,2,3 sequence of what I did and maybe we can track down where this is breaking for you.

Create a new MSAccess database (empty)
Click on the tables section
Select external data
Pick ODBC database
Pick Link to the datasource by creating a linked table
Select Machine datasource
Pick New...
System Datasource
Pick SQL Server from the list and click Next, Finish.
Give the new datasource a name and description, and select (local) for the server. Click Next.
Pick "With Windows NT authentication using the network login ID". Click Next.
Check Change the default database to, and pick the DB. Click Next. Click Finish.
Test the datasource.
Pick the table that the Trigger is associated with and click OK.
Open the table in Access and modify one of the entries (the trigger doesn't fire on Insert, just Update)
Select * from your audit table

Upvotes: 2

Andrew G. Johnson

Reputation: 26993

CREATE TRIGGER testtrigger1
ON testdatatable
AFTER update
AS 
BEGIN
    INSERT INTO testtable (datecol,usercol1,usercol2) VALUES (getdate(),user_name(),suser_sname());
END
GO

Upvotes: 1

Jay Mooney

Reputation: 2256

Sure :)

There should be a section in Access called "External Data" (I'm running a new version of Access, so the menu choice might be different).

Form this there should be an option to specify an ODBC connection.

I get an option to Link to the datasource by creating a linked table.

I then created a Machine datasource. I selected SqlServer from the drop down list. Then when I click Next, I'm prompted for how I want to authenticate.

Upvotes: 1

Jay Mooney

Reputation: 2256

I tried playing with Access a bit to see if I could find a way for you. I think you can specify a new datasource to your SQL table, and select Windows NT Authentication as your connection type.

Upvotes: 1