Lock adp
-
Hi
I have always found the code below useful to lock an mdb - as long as the references are there.
I run it appropriately from a password form.
However, when I come to use it in an adp, it doesn't seem to work.
Has anybody any ideas - or a better solution?
Thanks
Paul
Public Sub Openme()
Dim dbs As Database, prp As Property
Const conPropNotFoundError = 3270
Set dbs = CurrentDb
On Error GoTo change_err
dbs.Properties("AllowBypassKey") = True
change_bye:
Exit Sub
change_err:
If Err = conPropNotFoundError Then
Set prp = dbs.CreateProperty("AllowBypassKey", dbBoolean, True)
dbs.Properties.Append prp
Resume Next
Else
Resume change_bye
End If
End Sub
Public Sub Closeme()
Dim dbs As Database, prp As Property
Const conPropNotFoundError = 3270
Set dbs = CurrentDb
On Error GoTo change_err
dbs.Properties("AllowBypassKey") = False
change_bye:
Exit Sub
change_err:
If Err = conPropNotFoundError Then
Set prp = dbs.CreateProperty("AllowBypassKey", dbBoolean, False)
dbs.Properties.Append prp
Resume Next
Else
Resume change_bye
End If
End Sub
-
Paul,
Welcome to the ever-confusing world of mdb vs adp.
You already know what an mdb is. You can make connections to sql server objects via an mdb with an odbc connection. However, Jet takes over and the processing happens on the local machine vs the server.
So, you switch to an ADP and look that similiarities and think ... Okay same world, slightly different interface, no problem. Therein lies the challenge.
Think of an adp as a direct, connected GUI to Sql Server. When your data is a .mdb you can execute your code above with no problems. When your data is a SQL server database then the rules change, but, for the better.
First, no more white papers on database security. Now, you are using both the network (NT Authentication) and the the database (groups / roles / users) for your security. There is no need to "Lock the MDB" but rather to use the permissions, combined with T-SQL to effective the end-result you are seeking... No one can change or alter data that you don't want them to. One easy way to start this is to not bind forms to tables or queries. Instead, build them unbound and in the "On Open" of the object, execute a strSQL statement and either pass the results to data fields or set the recordsource as the strSQL.
Then, on close, change, exit, (whatever), execute the T-SQL command that you want based on the parameters passed to variables (e.g. Update, delete, close without changing). Also, you can use the permissions to set the enabled and locked features of fields so that the user cannot make changes.
If you can get a good grasp on this concept, your development capabilities world will explode. This process reaches a more robust level of maturity and thinking. It is a lot more code, but code that you control, contain and optimize.
Hope it helps.
Mike
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply