Empêcher l'ouverture d'une BD après un certain nombre de fois?
3 réponses
Butch
Bonjour,
Est-il possible d'empêcher l'ouverture d'une base de données lorsque après
que celle-ci aurait été ouverte un certain nombre de fois. Ex: Il serait
impossible d'ouvrir la BD plus de 5 fois.
Existe-il une fonction pour cette situation sans qu'il ne soit nécessaire
d'utiliser le processus de sécurisation d'une BD?
Si oui, est-ce que cette "protection" peut elle-même être "cachée" afin
qu'un usager ayant certaines connaissances en programmation ne puisse pas la
désactiver?
P.-S: Je ne possède pas la version "Développeur" de Office.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
3stone
Salut,
| Est-il possible d'empêcher l'ouverture d'une base de données lorsque après | que celle-ci aurait été ouverte un certain nombre de fois. Ex: Il serait | impossible d'ouvrir la BD plus de 5 fois. | Existe-il une fonction pour cette situation sans qu'il ne soit nécessaire | d'utiliser le processus de sécurisation d'une BD? | Si oui, est-ce que cette "protection" peut elle-même être "cachée" afin | qu'un usager ayant certaines connaissances en programmation ne puisse pas la | désactiver? | | P.-S: Je ne possède pas la version "Développeur" de Office.
Le plus simple, est de créer et distribuer une base .MDE
Il suffit alors d'écrire une petite fonction qui vérifie la date, le nombre d'enregistrements dans la table principale ou une autre valeur. Si la condition de fonctionnement n'est plus remplie, un simple
Application.Quit
Un nombre d'ouvertures demanderait le stockage du compteur dans une table ou dans la base des régistres, donc accessible.
-- A+ Pierre (3stone) Access MVP ------------------------------------------------------- Bien démarrer ? c'est ici http://users.skynet.be/mpfa/ ( Je ne réponds pas aux emails qui concernent Access ) -------------------------------------------------------
Salut,
| Est-il possible d'empêcher l'ouverture d'une base de données lorsque après
| que celle-ci aurait été ouverte un certain nombre de fois. Ex: Il serait
| impossible d'ouvrir la BD plus de 5 fois.
| Existe-il une fonction pour cette situation sans qu'il ne soit nécessaire
| d'utiliser le processus de sécurisation d'une BD?
| Si oui, est-ce que cette "protection" peut elle-même être "cachée" afin
| qu'un usager ayant certaines connaissances en programmation ne puisse pas la
| désactiver?
|
| P.-S: Je ne possède pas la version "Développeur" de Office.
Le plus simple, est de créer et distribuer une base .MDE
Il suffit alors d'écrire une petite fonction qui vérifie la date,
le nombre d'enregistrements dans la table principale ou une autre valeur.
Si la condition de fonctionnement n'est plus remplie, un simple
Application.Quit
Un nombre d'ouvertures demanderait le stockage du compteur
dans une table ou dans la base des régistres, donc accessible.
--
A+
Pierre (3stone) Access MVP
-------------------------------------------------------
Bien démarrer ? c'est ici http://users.skynet.be/mpfa/
( Je ne réponds pas aux emails qui concernent Access )
-------------------------------------------------------
| Est-il possible d'empêcher l'ouverture d'une base de données lorsque après | que celle-ci aurait été ouverte un certain nombre de fois. Ex: Il serait | impossible d'ouvrir la BD plus de 5 fois. | Existe-il une fonction pour cette situation sans qu'il ne soit nécessaire | d'utiliser le processus de sécurisation d'une BD? | Si oui, est-ce que cette "protection" peut elle-même être "cachée" afin | qu'un usager ayant certaines connaissances en programmation ne puisse pas la | désactiver? | | P.-S: Je ne possède pas la version "Développeur" de Office.
Le plus simple, est de créer et distribuer une base .MDE
Il suffit alors d'écrire une petite fonction qui vérifie la date, le nombre d'enregistrements dans la table principale ou une autre valeur. Si la condition de fonctionnement n'est plus remplie, un simple
Application.Quit
Un nombre d'ouvertures demanderait le stockage du compteur dans une table ou dans la base des régistres, donc accessible.
-- A+ Pierre (3stone) Access MVP ------------------------------------------------------- Bien démarrer ? c'est ici http://users.skynet.be/mpfa/ ( Je ne réponds pas aux emails qui concernent Access ) -------------------------------------------------------
Butch
Bonjour Pierre,
Merci pour tes suggestions. Je connais un peu les principes de base d'un fichier *.MDE. Cependant je crois qu'il est tout de même possible, avec ce type de fichier, de manipuler les tables et requêtes, dont la possibilité de les exporter vers une autre BD. Je crois cependant qu'il n'est toutefois pas possible de modifier les codes (les modules ???)... c'est probablement pour cela que tu suggères un fichier .MDE???
Cependant, je ne connais pas beaucoup l'utilisation de VBA. Je comprends ce que pourrais faire Application.Quit. Toutefois, je ne sais pas comment l'utiliser. Alors...
En supposant que ma BD en fichier *.MDE doive cesser de fonctionner après une date quelconque, peux-tu me donner un exemple de la procédure à créer? Je suppose (évidemment) qu'il faudra que je crée un nouveau module dans ma BD?
J'ai aussi une autre interrogation...? Si, après avoir créé la procédure, l'usager modifie la date système de son pc à une date antérieure à la date limite de la procédure, pourrait-il alors ouvrir de façon "indéfinie" la BD?
Merci pour le temps accordé et tes suggestions,
Butch
Le plus simple, est de créer et distribuer une base .MDE
Il suffit alors d'écrire une petite fonction qui vérifie la date, le nombre d'enregistrements dans la table principale ou une autre valeur. Si la condition de fonctionnement n'est plus remplie, un simple
Application.Quit
Un nombre d'ouvertures demanderait le stockage du compteur dans une table ou dans la base des régistres, donc accessible.
-- A+ Pierre (3stone) Access MVP ------------------------------------------------------- Bien démarrer ? c'est ici http://users.skynet.be/mpfa/ ( Je ne réponds pas aux emails qui concernent Access ) -------------------------------------------------------
Le plus simple, est de créer et distribuer une base .MDE
Il suffit alors d'écrire une petite fonction qui vérifie la date, le nombre d'enregistrements dans la table principale ou une autre valeur. Si la condition de fonctionnement n'est plus remplie, un simple
Application.Quit
Un nombre d'ouvertures demanderait le stockage du compteur dans une table ou dans la base des régistres, donc accessible.
-- A+ Pierre (3stone) Access MVP ------------------------------------------------------- Bien démarrer ? c'est ici http://users.skynet.be/mpfa/ ( Je ne réponds pas aux emails qui concernent Access ) -------------------------------------------------------
Bonjour Pierre,
Merci pour tes suggestions. Je connais un peu les principes de base d'un
fichier *.MDE. Cependant je crois qu'il est tout de même possible, avec ce
type de fichier, de manipuler les tables et requêtes, dont la possibilité de
les exporter vers une autre BD. Je crois cependant qu'il n'est toutefois pas
possible de modifier les codes (les modules ???)... c'est probablement pour
cela que tu suggères un fichier .MDE???
Cependant, je ne connais pas beaucoup l'utilisation de VBA. Je comprends ce
que pourrais faire Application.Quit. Toutefois, je ne sais pas comment
l'utiliser. Alors...
En supposant que ma BD en fichier *.MDE doive cesser de fonctionner après
une date quelconque, peux-tu me donner un exemple de la procédure à créer?
Je suppose (évidemment) qu'il faudra que je crée un nouveau module dans ma
BD?
J'ai aussi une autre interrogation...? Si, après avoir créé la procédure,
l'usager modifie la date système de son pc à une date antérieure à la date
limite de la procédure, pourrait-il alors ouvrir de façon "indéfinie" la BD?
Merci pour le temps accordé et tes suggestions,
Butch
Le plus simple, est de créer et distribuer une base .MDE
Il suffit alors d'écrire une petite fonction qui vérifie la date,
le nombre d'enregistrements dans la table principale ou une autre valeur.
Si la condition de fonctionnement n'est plus remplie, un simple
Application.Quit
Un nombre d'ouvertures demanderait le stockage du compteur
dans une table ou dans la base des régistres, donc accessible.
--
A+
Pierre (3stone) Access MVP
-------------------------------------------------------
Bien démarrer ? c'est ici http://users.skynet.be/mpfa/
( Je ne réponds pas aux emails qui concernent Access )
-------------------------------------------------------
Le plus simple, est de créer et distribuer une base .MDE
Il suffit alors d'écrire une petite fonction qui vérifie la date,
le nombre d'enregistrements dans la table principale ou une autre valeur.
Si la condition de fonctionnement n'est plus remplie, un simple
Application.Quit
Un nombre d'ouvertures demanderait le stockage du compteur
dans une table ou dans la base des régistres, donc accessible.
--
A+
Pierre (3stone) Access MVP
-------------------------------------------------------
Bien démarrer ? c'est ici http://users.skynet.be/mpfa/
( Je ne réponds pas aux emails qui concernent Access )
-------------------------------------------------------
Merci pour tes suggestions. Je connais un peu les principes de base d'un fichier *.MDE. Cependant je crois qu'il est tout de même possible, avec ce type de fichier, de manipuler les tables et requêtes, dont la possibilité de les exporter vers une autre BD. Je crois cependant qu'il n'est toutefois pas possible de modifier les codes (les modules ???)... c'est probablement pour cela que tu suggères un fichier .MDE???
Cependant, je ne connais pas beaucoup l'utilisation de VBA. Je comprends ce que pourrais faire Application.Quit. Toutefois, je ne sais pas comment l'utiliser. Alors...
En supposant que ma BD en fichier *.MDE doive cesser de fonctionner après une date quelconque, peux-tu me donner un exemple de la procédure à créer? Je suppose (évidemment) qu'il faudra que je crée un nouveau module dans ma BD?
J'ai aussi une autre interrogation...? Si, après avoir créé la procédure, l'usager modifie la date système de son pc à une date antérieure à la date limite de la procédure, pourrait-il alors ouvrir de façon "indéfinie" la BD?
Merci pour le temps accordé et tes suggestions,
Butch
Le plus simple, est de créer et distribuer une base .MDE
Il suffit alors d'écrire une petite fonction qui vérifie la date, le nombre d'enregistrements dans la table principale ou une autre valeur. Si la condition de fonctionnement n'est plus remplie, un simple
Application.Quit
Un nombre d'ouvertures demanderait le stockage du compteur dans une table ou dans la base des régistres, donc accessible.
-- A+ Pierre (3stone) Access MVP ------------------------------------------------------- Bien démarrer ? c'est ici http://users.skynet.be/mpfa/ ( Je ne réponds pas aux emails qui concernent Access ) -------------------------------------------------------
Le plus simple, est de créer et distribuer une base .MDE
Il suffit alors d'écrire une petite fonction qui vérifie la date, le nombre d'enregistrements dans la table principale ou une autre valeur. Si la condition de fonctionnement n'est plus remplie, un simple
Application.Quit
Un nombre d'ouvertures demanderait le stockage du compteur dans une table ou dans la base des régistres, donc accessible.
-- A+ Pierre (3stone) Access MVP ------------------------------------------------------- Bien démarrer ? c'est ici http://users.skynet.be/mpfa/ ( Je ne réponds pas aux emails qui concernent Access ) -------------------------------------------------------
3stone
Salut,
"Butch" | Merci pour tes suggestions. Je connais un peu les principes de base d'un | fichier *.MDE. Cependant je crois qu'il est tout de même possible, avec ce | type de fichier, de manipuler les tables et requêtes, dont la possibilité de | les exporter vers une autre BD. Je crois cependant qu'il n'est toutefois pas | possible de modifier les codes (les modules ???)... c'est probablement pour | cela que tu suggères un fichier .MDE???
Exact. On ne peut ni modifier le code des modules, ni celui se trouvant dans les formulaires. Ni même modifier les formulaires. Quant aux tables et les requêtes, tu t'en moque... Les données appartiennent à l'utilisateur et les requêtes "importantes" peuvent être créent de toutes pièces dans un module de formulaire...
| Cependant, je ne connais pas beaucoup l'utilisation de VBA. Je comprends ce | que pourrais faire Application.Quit. Toutefois, je ne sais pas comment | l'utiliser. Alors...
Si tu n'utilise pas intensément le VBA, il ne reste pas grand chose à protéger, si ce n'est les formulaires.
| En supposant que ma BD en fichier *.MDE doive cesser de fonctionner après | une date quelconque, peux-tu me donner un exemple de la procédure à créer? | Je suppose (évidemment) qu'il faudra que je crée un nouveau module dans ma | BD?
Dans le formulaire principal, tu ajoute un module appellé dans son événement d'ouverture... un simple test de la date et du nombre d'enregistrements dans la table principale devrait suffire.
| J'ai aussi une autre interrogation...? Si, après avoir créé la procédure, | l'usager modifie la date système de son pc à une date antérieure à la date | limite de la procédure, pourrait-il alors ouvrir de façon "indéfinie" la BD?
Si tu utilise (mais cela dépend de la destination de ta base) la date système dans les enregistrements, il sera bien ennuyé s'il la modifie.
Tu peux également compter le nombre d'ouvertures... mais pour utiliser du code qui écrit, modifie et vérifie la base des régistres, il faut mieux ne pas être faché avec VBA ;-)
-- A+ Pierre (3stone) Access MVP ------------------------------------------------------- Bien démarrer ? c'est ici http://users.skynet.be/mpfa/ ( Je ne réponds pas aux emails qui concernent Access ) -------------------------------------------------------
Salut,
"Butch"
| Merci pour tes suggestions. Je connais un peu les principes de base d'un
| fichier *.MDE. Cependant je crois qu'il est tout de même possible, avec ce
| type de fichier, de manipuler les tables et requêtes, dont la possibilité de
| les exporter vers une autre BD. Je crois cependant qu'il n'est toutefois pas
| possible de modifier les codes (les modules ???)... c'est probablement pour
| cela que tu suggères un fichier .MDE???
Exact.
On ne peut ni modifier le code des modules, ni celui se trouvant dans les formulaires.
Ni même modifier les formulaires.
Quant aux tables et les requêtes, tu t'en moque... Les données appartiennent
à l'utilisateur et les requêtes "importantes" peuvent être créent de toutes pièces
dans un module de formulaire...
| Cependant, je ne connais pas beaucoup l'utilisation de VBA. Je comprends ce
| que pourrais faire Application.Quit. Toutefois, je ne sais pas comment
| l'utiliser. Alors...
Si tu n'utilise pas intensément le VBA, il ne reste pas grand chose à protéger,
si ce n'est les formulaires.
| En supposant que ma BD en fichier *.MDE doive cesser de fonctionner après
| une date quelconque, peux-tu me donner un exemple de la procédure à créer?
| Je suppose (évidemment) qu'il faudra que je crée un nouveau module dans ma
| BD?
Dans le formulaire principal, tu ajoute un module appellé dans son événement
d'ouverture... un simple test de la date et du nombre d'enregistrements
dans la table principale devrait suffire.
| J'ai aussi une autre interrogation...? Si, après avoir créé la procédure,
| l'usager modifie la date système de son pc à une date antérieure à la date
| limite de la procédure, pourrait-il alors ouvrir de façon "indéfinie" la BD?
Si tu utilise (mais cela dépend de la destination de ta base) la date système
dans les enregistrements, il sera bien ennuyé s'il la modifie.
Tu peux également compter le nombre d'ouvertures... mais pour utiliser
du code qui écrit, modifie et vérifie la base des régistres, il faut mieux
ne pas être faché avec VBA ;-)
--
A+
Pierre (3stone) Access MVP
-------------------------------------------------------
Bien démarrer ? c'est ici http://users.skynet.be/mpfa/
( Je ne réponds pas aux emails qui concernent Access )
-------------------------------------------------------
"Butch" | Merci pour tes suggestions. Je connais un peu les principes de base d'un | fichier *.MDE. Cependant je crois qu'il est tout de même possible, avec ce | type de fichier, de manipuler les tables et requêtes, dont la possibilité de | les exporter vers une autre BD. Je crois cependant qu'il n'est toutefois pas | possible de modifier les codes (les modules ???)... c'est probablement pour | cela que tu suggères un fichier .MDE???
Exact. On ne peut ni modifier le code des modules, ni celui se trouvant dans les formulaires. Ni même modifier les formulaires. Quant aux tables et les requêtes, tu t'en moque... Les données appartiennent à l'utilisateur et les requêtes "importantes" peuvent être créent de toutes pièces dans un module de formulaire...
| Cependant, je ne connais pas beaucoup l'utilisation de VBA. Je comprends ce | que pourrais faire Application.Quit. Toutefois, je ne sais pas comment | l'utiliser. Alors...
Si tu n'utilise pas intensément le VBA, il ne reste pas grand chose à protéger, si ce n'est les formulaires.
| En supposant que ma BD en fichier *.MDE doive cesser de fonctionner après | une date quelconque, peux-tu me donner un exemple de la procédure à créer? | Je suppose (évidemment) qu'il faudra que je crée un nouveau module dans ma | BD?
Dans le formulaire principal, tu ajoute un module appellé dans son événement d'ouverture... un simple test de la date et du nombre d'enregistrements dans la table principale devrait suffire.
| J'ai aussi une autre interrogation...? Si, après avoir créé la procédure, | l'usager modifie la date système de son pc à une date antérieure à la date | limite de la procédure, pourrait-il alors ouvrir de façon "indéfinie" la BD?
Si tu utilise (mais cela dépend de la destination de ta base) la date système dans les enregistrements, il sera bien ennuyé s'il la modifie.
Tu peux également compter le nombre d'ouvertures... mais pour utiliser du code qui écrit, modifie et vérifie la base des régistres, il faut mieux ne pas être faché avec VBA ;-)
-- A+ Pierre (3stone) Access MVP ------------------------------------------------------- Bien démarrer ? c'est ici http://users.skynet.be/mpfa/ ( Je ne réponds pas aux emails qui concernent Access ) -------------------------------------------------------
