Limiter l'ouverture d'une BD à un nombre de fois...
16 réponses
Butch
Bonjour,
Version Access XP:
Est-il possible de faire en sorte d'empêcher l'ouverture d'une base de
données après que celle-ci fut ouverte un certain nombre de fois ?
Exemple: Après 5 ouvertures de la base, empêcher que l'usager puisse
l'ouvrir une sixième fois et faire afficher un message indiquant que le
nombre d'utilisations a été atteint?
De plus, est-il aussi possible, lors de la fermeture de la base au moment de
la dernière utilisation, de supprimer toutes les données qui auraient été
inscrites dans les tables (par l'entremise de formulaires) par l'usager ?
Pourquoi cela ? J'aimerais offrir à de futurs usagers, la possibilité
d'utiliser une base de données afin qu'ils déterminent leurs besoins futurs
sans pour autant leur laisser l'usage définitif de la base.
Merci à qui pourrait me fournir de l'information à ce sujet, du moins en ce
qui concerne le nombre de fois où la base pourrait être ouverte.
Avec la méthode suggérée, l'usager peut probablement ouvrir de nouveau la base de données s'il modifie la date de son système pour une date antérieure à la date limite. Ai-je raison?
Oui c'est exact!
Tu peux soit supprimer une table (située dans la base frontale) qui empèchera le fonctionnement normal de l'appli ou bien dans une table tu coches un champ DateExpiration (oui/non) une fois la date d'expiration atteinte et tu contrôles ce champ à chaque ouverture de la base.
je reconnais que ce n'est pas très sophistiqué, mais bon!!!!
Voilà
Cordialement
Codial
"Butch" a écrit dans le message de news: iFNTd.54380$
Bonjour Codial,
Merci pour le lien... cela fonctionne très bien. Mais, une question supplémentaire:
Avec la méthode suggérée, l'usager peut probablement ouvrir de nouveau la base de données s'il modifie la date de son système pour une date antérieure à la date limite. Ai-je raison? Alors, est-il possible d'ajouter au code, une fonction empêchant cela ou, de façon plus "drastique", de faire supprimer automatiquement tous les objets (ou les tables, par exemple) lorsque la BD est ouverte après la date d'expiration? Je sais qu'il y aurait probabablement pour un usager de contourner cette disposition mais quand même...
Merci, Butch
"Codial" a écrit dans le message de news:
Bonsoir,
Sinon s'il s'agit de créer une date d'expiration pour une application voir
Avec la méthode suggérée, l'usager peut probablement ouvrir de nouveau la
base de données s'il modifie la date de son système pour une date antérieure
à la date limite. Ai-je raison?
Oui c'est exact!
Tu peux soit supprimer une table (située dans la base frontale) qui
empèchera le fonctionnement normal de l'appli ou bien dans une table tu
coches un champ DateExpiration (oui/non) une fois la date d'expiration
atteinte et tu contrôles ce champ à chaque ouverture de la base.
je reconnais que ce n'est pas très sophistiqué, mais bon!!!!
Voilà
Cordialement
Codial
"Butch" <butch@untel.net> a écrit dans le message de news:
iFNTd.54380$6U2.1183620@weber.videotron.net...
Bonjour Codial,
Merci pour le lien... cela fonctionne très bien. Mais, une question
supplémentaire:
Avec la méthode suggérée, l'usager peut probablement ouvrir de nouveau la
base de données s'il modifie la date de son système pour une date
antérieure
à la date limite. Ai-je raison?
Alors, est-il possible d'ajouter au code, une fonction empêchant cela ou,
de
façon plus "drastique", de faire supprimer automatiquement tous les objets
(ou les tables, par exemple) lorsque la BD est ouverte après la date
d'expiration?
Je sais qu'il y aurait probabablement pour un usager de contourner cette
disposition mais quand même...
Merci,
Butch
"Codial" <aCodial@tiscali.fr> a écrit dans le message de
news:ev2JEE2GFHA.1528@TK2MSFTNGP09.phx.gbl...
Bonsoir,
Sinon s'il s'agit de créer une date d'expiration pour une application
voir
Avec la méthode suggérée, l'usager peut probablement ouvrir de nouveau la base de données s'il modifie la date de son système pour une date antérieure à la date limite. Ai-je raison?
Oui c'est exact!
Tu peux soit supprimer une table (située dans la base frontale) qui empèchera le fonctionnement normal de l'appli ou bien dans une table tu coches un champ DateExpiration (oui/non) une fois la date d'expiration atteinte et tu contrôles ce champ à chaque ouverture de la base.
je reconnais que ce n'est pas très sophistiqué, mais bon!!!!
Voilà
Cordialement
Codial
"Butch" a écrit dans le message de news: iFNTd.54380$
Bonjour Codial,
Merci pour le lien... cela fonctionne très bien. Mais, une question supplémentaire:
Avec la méthode suggérée, l'usager peut probablement ouvrir de nouveau la base de données s'il modifie la date de son système pour une date antérieure à la date limite. Ai-je raison? Alors, est-il possible d'ajouter au code, une fonction empêchant cela ou, de façon plus "drastique", de faire supprimer automatiquement tous les objets (ou les tables, par exemple) lorsque la BD est ouverte après la date d'expiration? Je sais qu'il y aurait probabablement pour un usager de contourner cette disposition mais quand même...
Merci, Butch
"Codial" a écrit dans le message de news:
Bonsoir,
Sinon s'il s'agit de créer une date d'expiration pour une application voir
"Butch" [...] | Avec la méthode suggérée, l'usager peut probablement ouvrir de nouveau la | base de données s'il modifie la date de son système pour une date antérieure | à la date limite. Ai-je raison? [...]
Selon la destination de la base... base client, facturation... ou même une simple gestion d'association... l'important est qu'elle un champ du genre date d'inscription ou date d'achat ou de facturation... enfin là ou il faut obligatoirement la date du jour courant.
C'est ce champ là qu'il faut "surveiller"...
S'il modifie la date système, cela rend *de toute facon* la base inutilisable.
"Butch"
[...]
| Avec la méthode suggérée, l'usager peut probablement ouvrir de nouveau la
| base de données s'il modifie la date de son système pour une date antérieure
| à la date limite. Ai-je raison?
[...]
Selon la destination de la base... base client, facturation... ou même une simple
gestion d'association... l'important est qu'elle un champ du genre date d'inscription
ou date d'achat ou de facturation... enfin là ou il faut obligatoirement la date du
jour courant.
C'est ce champ là qu'il faut "surveiller"...
S'il modifie la date système, cela rend *de toute facon* la base inutilisable.
"Butch" [...] | Avec la méthode suggérée, l'usager peut probablement ouvrir de nouveau la | base de données s'il modifie la date de son système pour une date antérieure | à la date limite. Ai-je raison? [...]
Selon la destination de la base... base client, facturation... ou même une simple gestion d'association... l'important est qu'elle un champ du genre date d'inscription ou date d'achat ou de facturation... enfin là ou il faut obligatoirement la date du jour courant.
C'est ce champ là qu'il faut "surveiller"...
S'il modifie la date système, cela rend *de toute facon* la base inutilisable.
dans une table tu coches un champ DateExpiration (oui/non) une fois la date d'expiration
atteinte et tu contrôles ce champ à chaque ouverture de la base.
Cela me semble très intéressant. Je comprend que la table doit contenir un champ OUI/NON.. ça je sais comment faire. Cependant, peux-tu me donner un exemple pour la façon de contrôler ce champ à chaque ouverture de la base? Je suppose aussi que la table doit contenir un champ type date, dans lequel la date d'expiration est inscrite! Comment le champ OUI/NON et le champ Date peuvent-ils être contrôlés à l'ouverture de la BD en fonction de la date limite atteinte?
Merci encore, Butch
Bonjour Codial,
dans une table tu coches un champ DateExpiration (oui/non) une fois la date
d'expiration
atteinte et tu contrôles ce champ à chaque ouverture de la base.
Cela me semble très intéressant. Je comprend que la table doit contenir un
champ OUI/NON.. ça je sais comment faire. Cependant, peux-tu me donner un
exemple pour la façon de contrôler ce champ à chaque ouverture de la base?
Je suppose aussi que la table doit contenir un champ type date, dans lequel
la date d'expiration est inscrite! Comment le champ OUI/NON et le champ
Date peuvent-ils être contrôlés à l'ouverture de la BD en fonction de la
date limite atteinte?
dans une table tu coches un champ DateExpiration (oui/non) une fois la date d'expiration
atteinte et tu contrôles ce champ à chaque ouverture de la base.
Cela me semble très intéressant. Je comprend que la table doit contenir un champ OUI/NON.. ça je sais comment faire. Cependant, peux-tu me donner un exemple pour la façon de contrôler ce champ à chaque ouverture de la base? Je suppose aussi que la table doit contenir un champ type date, dans lequel la date d'expiration est inscrite! Comment le champ OUI/NON et le champ Date peuvent-ils être contrôlés à l'ouverture de la BD en fonction de la date limite atteinte?
Merci encore, Butch
Codial
Bonjour,
Cependant, peux-tu me donner un exemple pour la façon de contrôler ce champ à chaque ouverture de la base?
Par exemple, cette table n'ayant qu'un enregistrement:
If DFirst("DateExpiration", "Table1") = False Then MsgBox "Date Expiration Ok" Else MsgBox "Date Expiration dépassée. Veuillez contacter votre fournisseur" Application.Quit End If
En fait l'idée, à mon sens, c'est qu'il n'y a pas besoin d'un champ date puisqu'elle est en dur dans la fonction DateExpirationApplication(). Seulement quand cette date est atteinte cocher la case DateExpiration d'une table et tester ce champ au lancement de l'appli.
Cordialement
Codial
"Butch" a écrit dans le message de news: IU_Td.69401$
Bonjour Codial,
dans une table tu coches un champ DateExpiration (oui/non) une fois la date d'expiration
atteinte et tu contrôles ce champ à chaque ouverture de la base.
Cela me semble très intéressant. Je comprend que la table doit contenir un champ OUI/NON.. ça je sais comment faire. Cependant, peux-tu me donner un exemple pour la façon de contrôler ce champ à chaque ouverture de la base? Je suppose aussi que la table doit contenir un champ type date, dans lequel la date d'expiration est inscrite! Comment le champ OUI/NON et le champ Date peuvent-ils être contrôlés à l'ouverture de la BD en fonction de la date limite atteinte?
Merci encore, Butch
Bonjour,
Cependant, peux-tu me donner un exemple pour la façon de contrôler ce champ
à chaque ouverture de la base?
Par exemple, cette table n'ayant qu'un enregistrement:
If DFirst("DateExpiration", "Table1") = False Then
MsgBox "Date Expiration Ok"
Else
MsgBox "Date Expiration dépassée. Veuillez contacter votre
fournisseur"
Application.Quit
End If
En fait l'idée, à mon sens, c'est qu'il n'y a pas besoin d'un champ date
puisqu'elle est en dur dans la fonction DateExpirationApplication().
Seulement quand cette date est atteinte cocher la case DateExpiration d'une
table et tester ce champ au lancement de l'appli.
Cordialement
Codial
"Butch" <butch@untel.net> a écrit dans le message de news:
IU_Td.69401$6U2.1609359@weber.videotron.net...
Bonjour Codial,
dans une table tu coches un champ DateExpiration (oui/non) une fois la
date
d'expiration
atteinte et tu contrôles ce champ à chaque ouverture de la base.
Cela me semble très intéressant. Je comprend que la table doit contenir
un
champ OUI/NON.. ça je sais comment faire. Cependant, peux-tu me donner un
exemple pour la façon de contrôler ce champ à chaque ouverture de la base?
Je suppose aussi que la table doit contenir un champ type date, dans
lequel
la date d'expiration est inscrite! Comment le champ OUI/NON et le champ
Date peuvent-ils être contrôlés à l'ouverture de la BD en fonction de la
date limite atteinte?
Cependant, peux-tu me donner un exemple pour la façon de contrôler ce champ à chaque ouverture de la base?
Par exemple, cette table n'ayant qu'un enregistrement:
If DFirst("DateExpiration", "Table1") = False Then MsgBox "Date Expiration Ok" Else MsgBox "Date Expiration dépassée. Veuillez contacter votre fournisseur" Application.Quit End If
En fait l'idée, à mon sens, c'est qu'il n'y a pas besoin d'un champ date puisqu'elle est en dur dans la fonction DateExpirationApplication(). Seulement quand cette date est atteinte cocher la case DateExpiration d'une table et tester ce champ au lancement de l'appli.
Cordialement
Codial
"Butch" a écrit dans le message de news: IU_Td.69401$
Bonjour Codial,
dans une table tu coches un champ DateExpiration (oui/non) une fois la date d'expiration
atteinte et tu contrôles ce champ à chaque ouverture de la base.
Cela me semble très intéressant. Je comprend que la table doit contenir un champ OUI/NON.. ça je sais comment faire. Cependant, peux-tu me donner un exemple pour la façon de contrôler ce champ à chaque ouverture de la base? Je suppose aussi que la table doit contenir un champ type date, dans lequel la date d'expiration est inscrite! Comment le champ OUI/NON et le champ Date peuvent-ils être contrôlés à l'ouverture de la BD en fonction de la date limite atteinte?
Merci encore, Butch
Butch
Bonjour à tous,
Eh oui... un très Gros Merci à Raymond, Codial et 3Stone. Grâce à vos explications et quelques recherches supplémentaires sur Internet j'ai réussi à atteindre mon objectif soit "Limiter l'ouverture d'une BD".
En ce qui me concerne, j'ai appliqué la solution utilisant un compteur qui s'incrémente automatiquement à chaque ouverture de la BD (suggestion: Codial) sans toutefois tenir compte d'une date limite. Je ne sais pas si cela est parfait mais ça fait le travail! Étant donné qu'il n'est plus nécessaire de vérifier une date, le fait que l'usager puisse changer la date de son système n'a plus d'impact.
Encore une fois, Messieurs, MERCI ! Butch
Bonjour à tous,
Eh oui... un très Gros Merci à Raymond, Codial et 3Stone.
Grâce à vos explications et quelques recherches supplémentaires sur Internet
j'ai réussi à atteindre mon objectif soit "Limiter l'ouverture d'une BD".
En ce qui me concerne, j'ai appliqué la solution utilisant un compteur qui
s'incrémente automatiquement à chaque ouverture de la BD (suggestion:
Codial) sans toutefois tenir compte d'une date limite. Je ne sais pas si
cela est parfait mais ça fait le travail! Étant donné qu'il n'est plus
nécessaire de vérifier une date, le fait que l'usager puisse changer la date
de son système n'a plus d'impact.
Eh oui... un très Gros Merci à Raymond, Codial et 3Stone. Grâce à vos explications et quelques recherches supplémentaires sur Internet j'ai réussi à atteindre mon objectif soit "Limiter l'ouverture d'une BD".
En ce qui me concerne, j'ai appliqué la solution utilisant un compteur qui s'incrémente automatiquement à chaque ouverture de la BD (suggestion: Codial) sans toutefois tenir compte d'une date limite. Je ne sais pas si cela est parfait mais ça fait le travail! Étant donné qu'il n'est plus nécessaire de vérifier une date, le fait que l'usager puisse changer la date de son système n'a plus d'impact.
Encore une fois, Messieurs, MERCI ! Butch
Codial
Bonjour,
en fait c'était soit soit, si tu as choisi le compteur effectivement il n'y a pas besoin de date limite!
Codialement
Codial
"Butch" a écrit dans le message de news: HNqUd.11377$
Bonjour à tous,
Eh oui... un très Gros Merci à Raymond, Codial et 3Stone. Grâce à vos explications et quelques recherches supplémentaires sur Internet j'ai réussi à atteindre mon objectif soit "Limiter l'ouverture d'une BD".
En ce qui me concerne, j'ai appliqué la solution utilisant un compteur qui s'incrémente automatiquement à chaque ouverture de la BD (suggestion: Codial) sans toutefois tenir compte d'une date limite. Je ne sais pas si cela est parfait mais ça fait le travail! Étant donné qu'il n'est plus nécessaire de vérifier une date, le fait que l'usager puisse changer la date de son système n'a plus d'impact.
Encore une fois, Messieurs, MERCI ! Butch
Bonjour,
en fait c'était soit soit, si tu as choisi le compteur effectivement il n'y
a pas besoin de date limite!
Codialement
Codial
"Butch" <butch@untel.net> a écrit dans le message de news:
HNqUd.11377$044.422648@wagner.videotron.net...
Bonjour à tous,
Eh oui... un très Gros Merci à Raymond, Codial et 3Stone.
Grâce à vos explications et quelques recherches supplémentaires sur
Internet
j'ai réussi à atteindre mon objectif soit "Limiter l'ouverture d'une BD".
En ce qui me concerne, j'ai appliqué la solution utilisant un compteur qui
s'incrémente automatiquement à chaque ouverture de la BD (suggestion:
Codial) sans toutefois tenir compte d'une date limite. Je ne sais pas si
cela est parfait mais ça fait le travail! Étant donné qu'il n'est plus
nécessaire de vérifier une date, le fait que l'usager puisse changer la
date
de son système n'a plus d'impact.
en fait c'était soit soit, si tu as choisi le compteur effectivement il n'y a pas besoin de date limite!
Codialement
Codial
"Butch" a écrit dans le message de news: HNqUd.11377$
Bonjour à tous,
Eh oui... un très Gros Merci à Raymond, Codial et 3Stone. Grâce à vos explications et quelques recherches supplémentaires sur Internet j'ai réussi à atteindre mon objectif soit "Limiter l'ouverture d'une BD".
En ce qui me concerne, j'ai appliqué la solution utilisant un compteur qui s'incrémente automatiquement à chaque ouverture de la BD (suggestion: Codial) sans toutefois tenir compte d'une date limite. Je ne sais pas si cela est parfait mais ça fait le travail! Étant donné qu'il n'est plus nécessaire de vérifier une date, le fait que l'usager puisse changer la date de son système n'a plus d'impact.
