copy prevention and time limiting

[Jo Davis]

access fe and access be. later the be might be sql server

I don't want people to pass this application around. And I want control over
usage. I want it to 'expire' after a while.

I have fairly good control over the install.

I have (probably?) prevented unauthorised distribution thus:

I have a module which checks the HD partition volume number. If it isn't the
one I installed it on then application.qui t. I call this function in the
open of several key forms. It gives an 'error message' before the quit which
is the actual vol number. Just in case the client formats the HD or installs
a new one or something. Makes it easy for me to create another working
version.

Time limiting so far isn't really time limiting. Checks the autonumber PK of
a few key tables. When it get's to n issues warning, but works. When it gets
to n+50 app.quit.

This is all in the FE. The BE is his data obviously. Can do what they want
with that.

I distribute it as an encrypted MDE.

I imagining how people might try to get round it:

A clever programmer could work out what's happening, back up the data, empty
the tables, re-import some of the data and they're off again. A lot of the
data is historical and it wouldn't be a big deal if it was lost. So maybe if
reaching n+50 sets an invisible control on a form to 'outahere' which is the
thing which fires the app.quit. So once that number of records has been
reached any amount of resetting of PKs won't help. I thought of doing the
same thing with real time values. So that resetting the system clock won't
help them.

Of course this all assumes that they client can find an access developer who
is prepared to work out what is going on and attempt to get round it.

Opinions? I mean on the technical merits of this. I know some people think
just to not bother and trust clients. That's up to me.

Jo

[Arno R]

Is this for a demo-application?

Why not just limit the time ?
If Date > xxx then Application.qui t (with an appropriate warning that the demo has
expired)
IME my apps always are date-dependent, so resetting the system clock would bother them
more than it would bother me ....

Resetting the systemclock would affect almost *everything* they do with their PC.
If they just want to 'play' some longer with your app, well let them be.
If this is to deliver a time-limited demo then maybe I would also count the records in
some tables, and deny adding more.
If this is *not* a demo but a real application the client pays for, then I wonder if *you*
really have the right to quit their application ..

--
Hope this helps
Arno R
"Jo Davis" <[e-mail]> schreef in bericht
news:42******** *************** @news.aaisp.net .uk...

access fe and access be. later the be might be sql server

I don't want people to pass this application around. And I want control over usage. I
want it to 'expire' after a while.

I have fairly good control over the install.

I have (probably?) prevented unauthorised distribution thus:

I have a module which checks the HD partition volume number. If it isn't the one I
installed it on then application.qui t. I call this function in the open of several key
forms. It gives an 'error message' before the quit which is the actual vol number. Just
in case the client formats the HD or installs a new one or something. Makes it easy for
me to create another working version.

Time limiting so far isn't really time limiting. Checks the autonumber PK of a few key
tables. When it get's to n issues warning, but works. When it gets to n+50 app.quit.

This is all in the FE. The BE is his data obviously. Can do what they want with that.

I distribute it as an encrypted MDE.

I imagining how people might try to get round it:

A clever programmer could work out what's happening, back up the data, empty the tables,
re-import some of the data and they're off again. A lot of the data is historical and it
wouldn't be a big deal if it was lost. So maybe if reaching n+50 sets an invisible
control on a form to 'outahere' which is the thing which fires the app.quit. So once
that number of records has been reached any amount of resetting of PKs won't help. I
thought of doing the same thing with real time values. So that resetting the system
clock won't help them.

Of course this all assumes that they client can find an access developer who is prepared
to work out what is going on and attempt to get round it.

Opinions? I mean on the technical merits of this. I know some people think just to not
bother and trust clients. That's up to me.

Jo

[Jo Davis]

"Arno R" <ar************ ****@tiscali.nl > wrote in message
news:42223d15$0 $44098

If this is *not* a demo but a real application the client pays for, then I
wonder if *you* really have the right to quit their application ..

It's an application the client rents from me.

Jo