How can I programmatically make the system remove itself? Is this possible?

[accesser2003]

Is it possible to programmatically write a code in a form to fully make the system remove itself?

Thanks,

 

[odin1701]

What do you mean by "make the system remove itself"?

 

[accesser2003]

I mean I want to write a code inside my access database(MDB) that remove the project itself from the PC. This is because I no longer need this database.

Is there API that can I can call which will remove the caller application .

Thanks,

 

[odin1701]

You wouldn't be able to remove it while it's open. I use an actual installer package for my DB's so you can remove them from control panel's add/remove programs.

I think the only way would be to include a VB Script in an update and have the database call that VB Script, then exit, while the VB Script removed the database files.

 

[The_Doc_Man]

You have to create an independent process whose context doesn't depend on the context of the database. While that file is open, it is locked against deletion. Further, if you implemented Access security, you have to overcome your own protection scheme because this process has to run as the data owner or as the administrator, who can take over ownership of the data.

The trick is of course to have the process do what you want while assuring that it does NOT take out the rest of your operating system. Further, if you have any anti-virus code running that has heuristics or "suspicious behavior detection" features, it might stop you.

On top of that, even if this is shared code, you will have the issue of assuring that no one else is in the code when this "remover" is trying to run. I have to say, this is not a trivial thing to assure. Search this forum for the topic of "Kicking Out" or "Ejecting" unwanted users at a selected maintenance time. I won't try to reinvent that wheel.

I might take the approach of writing a "poison pill' routine that runs perhaps via a macro.

Have the macro do a RUNCODE on something in a module that contains nothing else. Then in that module, have a series of loops that visits every collection: Tabledefs, QueryDefs, Documents, Modules, Forms, and Reports.

Do this more or less as:

Take whatever steps you find suitable from the search for assuring that no one else is in the database but you.

For every open form, close the form.

For every open report, close the report.

For every document (which includes closed forms and reports), delete the document.

For every querydef, delete the querydef.

For every table that isn't a system table, delete the table.

Now have the code do an automatic Compact and Repair on Exit. Then QUIT the application.

While it might not be totally gone, it will never run again. There is, however, this additional catch. If the application exists on backup tapes and is restored, you cannot stop it from running again unless it has a way to know that it shouldn't be running - like a registry entry with an obscure name, meaning, or format. Look up the xxxxSettings functions, which allow you to interact with the registry. The Help files will tell you about them.

I'm sure I've forgotten something, but maybe this little voyage through the mine field of automated product de-installation will help you realize just what you asked to do.

 

[gemma-the-husky]

if you just want to disable it from running, it would be easier to implement some date check, or times used, or maximum data size setting etc etc

 

[The_Doc_Man]

Gemma is right. Actually removing something is hard - the point I was making earlier. Making it brain-dead is far easier.

A thought that comes to mind is that if the app is set up that it has code modules - i.e. you DIDN'T convert it to an MDE - you can insert a line of code in your modules like a QUIT action or method. DoCmd.QUIT peppered among your code would stop things pretty quickly.

Another idea that might help is to compute a date and use the _Settings functions to set that date in a key - but NOT in date format. Maybe as an integer or as a HEX integer. Then when you start the program check that setting. If today's date, when converted to an integer, exceeds the HEX integer value, execute your QUIT. Of course, you would have to figure out when it would be right to load that HEX integer as a product enabler key. There are a thousand ways to do this, but I'm sure you will figure out what you need to do.

Just remember, LONG( Date() ) is valid and is an integer that you CAN use in math. It is the number of days since the Winxx reference date of 31-Dec-1899 (day 0). So if you give your customer a key and fix it so your code won't run without that key, and if the key contains its own date of death, you are good.