Time bomb a DB

[Dave]

Access 2007

How difficult is it to time bomb a DB.

Can I do something as simple as the onload event of frmMain checks the date
and if the date is greater then some hard coded date then a message box pops
up saying "trial period is over" and then closes the program after 30
seconds?

comments on that approach or other suggestions appreciated

dave

 

[Al Campagna]

Dave,
I've coded (just 1 time) an application bomb using basically what you
suggested. My bomb disabled only those forms and reports that the client
hadn't paid for. It did not disable the whole application.
It never did trigger... as the client did pay up.

I think I used 60 or 90 days as the trigger... plenty of time to work it
out with the client before the bomb would trigger.

General consensus on "bombs" is "mixed" to say the least. Many pros,
many cons.

I'd be very wary about doing it, and certainly... never have your bomb
affect customer data.
--
hth
Al Campagna
Microsoft Access MVP
http://home.comcast.net/~cccsolutions/index.html

"Find a job that you love... and you'll never work a day in your life."

 

[Danny J. Lesandrini]

Someone once told me that if I did put such a "bomb" in the code, I'd
better not reveal that I did. The error message should not read ...

"Sorry, you didn't pay, and now I've disabled your app."

But more like this ...

"Hmmm. Something seems to be wrong in your application.
Please contact the developer immediately to get it resolved."

I did this once ... and it worked perfectly. The client, who hadn't paid
me, called to say that something was wrong and he needed it fixed. Oh,
and by the way, I've got a check for you.

 

[John W. Vinson]

I did this once ... and it worked perfectly. The client, who hadn't paid
me, called to say that something was wrong and he needed it fixed. Oh,
and by the way, I've got a check for you.

"Don't ask... don't tell" eh?

 

[Al Campagna]

Danny,
If I did use bombs... I'd use your "line."
Good idea...
--

Al Campagna
Microsoft Access MVP
http://home.comcast.net/~cccsolutions/index.html

"Find a job that you love... and you'll never work a day in your life."

 

[Larry Linson]

If I remember correctly, I've read that such "time bombs" are illegal in the
European Union, so if your application might be distributed there, or
downloaded to any EU jurisdiction, you should seek competent legal advice
before including one.

As a matter of fact, it would probably be a good idea to check with an
attorney before creating one, no matter where it will run.

And, as you've already been advised, do not damage the client's data, and be
sure they can extract their data from your application. That's not legal
advice, but if you tried to hold _my_ data hostage, I'd be tempted to take
legal action against you.

Larry Linson
Microsoft Office Access MVP

 

[Ron Weiner]

Oh Boy, I can see I am going to be the "Bad Boy" in this thread. I place
time out code in much of the software I write. This includes Access, VB6,
and VB.Net applications.

I develop applications that are designed to be used into a short term rental
situations. A typical scenario for us is to rent the software from 3 to 30
days. All of our contracts spell out exactly what we are providing,
including the time out dates. However at NO TIME do we hold any of the data
collected with our software hostage (even for non payment of the rental
fee). We provide either a pre-programmed user activated way to get the data
out, or a set of step by step instructions for the user to do it manually,
and in extreme cases where the user is a total ID10T we will actually do it
for them.

We use a combination of protective features (which I will not reveal for
obvious reasons) to insure that when the time out date has been exceeded the
application simply won't run. It displays a modal form with a message
stating that the application has timed out, and when the user dismisses that
form the application unloads itself.

I believe the most important thing here is that at no time is anyone
surprised when the application stops working. Our customers know that they
are renting the software, and not no rights to use it after the rental
period is over. My advise to you would be to make sure that your
customer(s) are likewise informed. Everybody hates surprises.

Rdub

 

[Danny J. Lesandrini]

Larry:

I believe we've had this conversation before <<deja vue>> and it was your
warning that made me obfuscate the "time bomb". I don't mean to give anyone
legal advice either and frankly, I'm not saying that what I did was legal.

What I'm saying is that it may *not* be legal, even though it may be just. That
being the case, whatever one decides to do, they shouldn't broadcast that they
are disabling the code on purpose.

In my case, it was a classic ASP application and though I routed the time bomb
through a number of functions and several pages, it was still in plain text, vieable
in Notepad. If the client had hired someone else to figure out the problem, it
could have come back to bite me.

Still, in my case, things worked out, so if I sensed a problem coming on with a
client, I'd be inclined to try it again.

 

[Dave]

I guess I was not expecting this to be this controversial. Because is it -
let me explain my reasoning.
My Proposals with this client have been "Final Payment due upon Delivery"
That is our standard proposal.
However that is more to cover my ass.
My policy has always been to ask the client when the relationship first
starts - what is their payment practices?
With this client they said if I invoice before a Wed then the invoice will
be processed on Wed and Check will be mailed on Friday.
We have worked on those terms for about a year now.
I presented an invoice on Monday Jan 12th for work done in Dec.
Should have gotten a check the following week.
On Tue the 27th she emailed me that she would like me to come in and train
her staff on Fri the 30th.
I email back saying I would be glad to and - Oh By the way, I have not
received my check yet can I just pick it up when I am at her office.
She replied that they had changed venders for the new year and that all
checks would take 30 days to process.
I believe she is completely with in her right to change payment policies
(and 30 days is a not un common practice)
However a change in policy should have been mentioned before requesting new
work and at least when presenting the invoice.
I went in to her office as I agreed on the 27th and trained her staff but
she continentally did not have time to talk with me. I also learned on the
27th from one of her staff members that my invoice had not even been
presented to the vendor yet - so the 30 day clock is not yet ticking.

That's my story.

I did time bomb the frmMain navigation form) and set it at 60 days
I do like Danny's suggestion and I am using his verbiage word for word.
I was going to say something like (Your Trial Period has expired.blah, blah,
blah)

also I am not damaging/deleting their data. Only closing the application
after the message box pops up.

She has been shown (Although probably does not remember) to use the Shift
key to get to the tables. This also means they could bypass the opening form
and do everything the DB is designed for. I doubt they will realize that.

Thanks for all the replies and insight

dave

 

[Jeff Conrad [MSFT]]

Hi Dave,

See this page on my site for some options:
http://www.accessmvp.com/JConrad/accessjunkie/demodatabase.html

--
Jeff Conrad - Access Junkie - MVP Alumnus
SDET - XAS Services - Microsoft Corporation

Co-author - Microsoft Office Access 2007 Inside Out
Presenter - Microsoft Access 2007 Essentials
http://www.accessmvp.com/JConrad/accessjunkie.html
Access 2007 Info: http://www.AccessJunkie.com