Self Destruct Code

[fenhow]

Hello,

I have created a very useful database and distribute it to our staff. Is there any way I can buy, find or create a method that will force the user of the database to contact me for a security code that will allow continued use of the database or it will self destruct?

Thanks!

Fen

 

[Banana]

I don't have the particulars, but I understand that you can't destroy a database while you're logged in.

If you have split the database, then you could use the backend to destroy the frontend, but I don't think this is a very effective security.

What you want to do that current Access security can't do for you?

 

[fenhow]

Serial Key Generator

Thanks,

I have been looking online and I have no problem paying for such a solution. It looks like there are several options to create serial keys etc to protect your application.

If anyone has expierence with this and has some proven solutions I would greatly apprecaiate it.

Thanks Banana for your input.
Fen

 

[raskew]

Hi -

The following sub will remove all records from a current database, while retaining the structure.

Be careful if testing. Once you run it, there's no turning back.

Sub EmptyTables2()
' This procedure allows the developer to remove records
' from all tables while retaining the structure.
' It is EXTREMELY DESTRUCTIVE!, since once the
' records are deleted, there's no getting them back!

Dim db     As Database
Dim td     As Variant
Dim strsql As String
Dim tname  As String
Dim i      As Integer

    Set db = CurrentDb
    Set td = db.TableDefs
    ' Trap for any errors.
        On Error Resume Next
    Beep
    If MsgBox("Warning!  You are about to delete all records in this database.", vbOKCancel, "Are you sure you want to continue?") = vbCancel Then Exit Sub
        For i = 0 To td.Count - 1
           If Left(td(i).Name, 4) <> "MSys" Then
              tname = td(i).Name
              strsql = "DELETE [" & tname & "].*" _
                    & " FROM [" & tname & "];"
              Debug.Print strsql
              'commented out for safety
              'db.Execute strSQL
           End If
    Next i

End Sub

HTH - Bob

 

[Banana]

Now that raskew mentions it, it occurs to me it's possible to destroy all tables structures (and all other objects if you so desire) by looping through the database's collection, leaving the user with a blank database. My previous post was based on the assumption you wanted to delete the database file itself, which would require shelling out to another application to do that.

 

[fenhow]

Thanks, that sub will work great for testing purposes when I want to clean out a database. If you want take a look at this site, this is what I am looking for.

http://www.peterssoftware.com/ka.htm

The problem at this point is I am running Vista and cannnot open the help files to learn what it is I am suppose to do with the application. The download demo works great however. I am thinking about buying it.

Fen

 

[The_Doc_Man]

The more logical way to do this is to distribute the files in an encrypted ZIP container and make someone pay for the password. You keep the password in a separate database and just don't make it something too simple - like the customer number for that customer.

Unless of course you have a license that is yearly rather than one-time.

The problem is, of course, once the DB has been decrypted one time, the files are out there in the clear.

Since there IS such a thing as doing a GetParameter or SetParameter (i.e. write to the registry, read from the registry), you COULD do something like build a database that has a startup form. In this startup form, run some code to check for a specific registry key that is computed in some way based on the customer's machine ID or the disk volume number. If the key is in the registry, set some global variable in a global module. If not, don't do so. Instead, cause a dialog box to pop up that asks for the key.

Read up on how to disable the SHIFT and F11 key startup options. If the user tries to open the DB bypassing the startup form, that global variable and the registry entry will be absent.

Then, if the user tries to run ANY form or ANY report, put a little something in each of the xxx_Open routines to sanity-check the registry and the global variable. If it is not "right", cause that form or report to do an Application.Quit without giving anyone a chance to proceed.

Now, there is nothing that can be done about the data and queries because no event routine protects them. It is Windows security or nothing. But if you take the approach of securing the database (Search this forum for that topic) then you could at least make life difficult for the deadbeats.