Codice di attivazione con durata un anno!

[book]

...ad una data fissa (non esplicitata) l'interfaccia scade e non permette più la riapertura (mediante flag).

ciao Giulio, questa non l'ho capita.
...la data fissa non esplicitata con quale data la confronti?

Riccardo

[andreuccio]

Supponiamo che la data calcolata che restituisce sia quella di ieri
Prima di aprire il programma cambio la data del PC in quella di ieri.
Il controllo viene eluso poi una volta dentro modifico di nuovo la data rimettendola in data di oggi.

Chi utilizza ill programma dovrebbe sapere che esiste il campo, e comunque era una idea veloce che mi era venuta. Valutala nell'insieme, e sicuramente ne verranno fuori altre.

[Pirata]

la data di 1ª installazione +1 sino ad arrivare a 365 giorni? (chiaramente creando un campo calcolato). E' una idea malsana

Nel sel che se lo si usa ogni giorno andrà bene, altrimenti... ???

[stregatto]

...ad una data fissa (non esplicitata) l'interfaccia scade e non permette più la riapertura (mediante flag).

ciao Giulio, questa non l'ho capita.
...la data fissa non esplicitata con quale data la confronti?

Riccardo

dunque: segui il mio ragionamento, e dimmi se dico una boiata:

- premessa. lo scopo è più dissuasivo che impenetrabile
- dati noti. abbiamo due dati noti: la data per come risulta al pc e la data di scadenza. Abbiamo un dato ulteriore variable che è la data dei record/documenti nel programma.

È ovvio che mancando il dato variabile il ragionamento non può essere applicato.
È altrettanto ovvio che nel caso di un programma che fa molto uso del dato variabile (fatture, ddt…), è molto semplice "legare" il dato variabile al fisso: qualcosa come: se la data del documento è successiva alla data del pc non la accettare, se la data del pc viene spostata da quella memorizzata in apertura programma, fai piangere l'utente… eccosivvia.

il ragionamento che facevo si regge se i dati interni sono più del secondo che del primo tipo… in quanto vuole rendere talmente scomodo l'eventuale uso da preferire il pagamento.

.g.

[book]

descritto in questi termini il tuo ragionamento, ove applicabile, non fa una grinza.

ciao
Riccardo

[marianasu]

Scusate se rispondo solo ora....
Grazie Giulio, avevo capito già il tuo ragionamento e lo condivido fino in fondo lo applicherò di sicuro, dato che esistono delle date che andranno messe in fase di stampa e che devono essere le date corrette, e quindi il gioco di modificare la data lo posso controllare con questi valori.
Prima dei tuoi messaggi in effetti non ci avevo pensato di poter fare dei controlli anche all'interno.
Nel frattempo ho visto il file di creazione dei codici di attivazione di
http://www.lifescope.net/

E con il loro programma posso legare i codici di attivazione a
Intestazione_Delle_Stampe (per cui il programma non può essere passato ad altri) e ad un altro campo dove posso mettere la data di scadenza, per cui se modificano il codice di attivazione posso modificare la data di scadenza della licenza.
Adesso provo a farmi il programma di lifescope da solo con un altra logica di generazione e decrptazione dei codici

GRAZIE MILLE M

[stregatto]

ove applicabile.

appunto…

.g.

[Pirata]

...e se, per assurdo, il nostro db non possiede campi data (per l'utente), ogni qualvolta sarà creato un nuovo record, provvederemo in maniera nascosta, di "segnarci" la data corrente al fine di applicare i controlli di cui sopra!
Giusto?

[stregatto]

non proprio. in quel caso dipende dalla struttura e dai dati.

.g.

[book]

Ciao Boys,
potete fare tutto quello che volete...l'importante è che non archiviate date in campi che non siano calcolati.

saluti
Riccardo