Discussion :

[Ric500]

Bonjour à tous,

J'ai une question qui peut paraître incongrue concernant les mises à jour.
J'ai l'intention de distribuer mon appli en version téléchargeable avec un package comprenant le runtime access: jusqu'ici pas de problème.
Mon appli continue d'évoluer et je me pose la question fatale: comment distribuer une version de mise à jour alors que certaines informations sont stockées dans le frontal (dans des tables) ?
J'espère avoir été assez clair, merci de vos réponses

[marot_r]

Bonjour.

Tu ne peux pas, du moins pas directement.

Quand tu copies une BD tu copies tout ce qu'elle contient.

Si tu veux garder certaines informations, il faut mettre en place un mécanisme supplémentaire.

Tu peux par exemple :

1. Exporter les données avant la mise à jour puis les réimporter après.
   Tu peux utiliser un fichier texte, un fichier Excel, une BD externe ...
2. Changer ton architecture et transférer les donnée qui sont dans la frontale vers la dorsale en "personnalisant" ces données par exemple ajout un identifiant d'utilisateur ou de machine.
   Personnellement c'est cette solution que je privilégierai. Il est assez facile d'ajoute un champ d'identifiant à une table existante et de sélectionner sur ce champ.
3. Faire les modifications par programme en ciblant seulement les éléments qui t'intéresse.
   Je le fais actuellement pour une de mes BD. J'ai du code qui récupère les données initiales, mouline ces données et pousse les données et change l'architecture de ma BD.

A+

[Ric500]

Merci Marot_r,

Je vois l'idée, mais il faudra que je l'adapte...
Penses-tu qu'un truc du genre ferait l'affaire: Si ma bdd s'appelle A, j'appelle la mise à jour A-New, par exemple et je l'envoie avec un outil tiers qui s'appelle disons ... A-tarte ( s'appelle à tarte :)
A-Tarte envoie les infos de A vers A-New , supprime A et renomme A-New en A (l'idéal serait qu'elle puisse se supprimer aussi)
Merci encore de ta réponse rapide,
Cordialement

PS: Cela dit je vais quand même vérifier que je peux l'envoyer vers la dorsale ... reste le renommage...

[marot_r]

Bonjour.

Penses-tu qu'un truc du genre ferait l'affaire: Si ma bdd s'appelle A, j'appelle la mise à jour A-New, par exemple et je l'envoie avec un outil tiers qui s'appelle disons ... A-tarte ( s'appelle à tarte
A-Tarte envoie les infos de A vers A-New , supprime A et renomme A-New en A (l'idéal serait qu'elle puisse se supprimer aussi)

Je pense que c'est un peu usine à gaz avec plein de pièces qui peuvent brisées et/ou ne pas fonctionner.
Quelles sont les informations que tu as besoin de conserver ?
À quoi sont-elles reliées ? À l'utilisateur ? À la machine ? À cette version du programme ?

A+

[Ric500]

En fait ce sont 3 tables:
. Chemins: contient des paramètres divers propres au poste, à l'utilisateur, options choisies par l'utilisateur
. MSysBook: table cachée, contient un décompte des heures d'assistance restantes (crédit d'assistance à distance)
. MSysTMP: table cachée, contient un numéro de licence qui peut être temporaire (le premier mois) ou définitive pour l'utilisation "légale" du logiciel

... Du coup tu me donnes une idée... la mise à jour (en accdr) peut-elle importer ces tables (après test d'existence au démarrage), supprimer l'ancienne bdd ?
L'idéal serait qu'elle se copie ensuite dans le bon dossier (j'ai une idée en tête)

[marot_r]

Bonjour.

Comme les accdr sont des accdb qui ne dise pas leur nom, je pense qu'elles peuvent faire tous ce qu'une Accdb peut faire.
Avec du code VBA tu devrais pouvoir faire tout ce que tu veux.
Contrairement au accde qui ne contienne que la partie exécutable du code et sont plus limitées.
Ceci dit c'est peut-être aussi possible avec un accde car tu n'alter pas la structure même de ta BD.
Il suffirait de créer des tables liées sur tes tables spéciales de ton ancienne version.

Cela donnerai :

1. Le script d'installation copie la version actuellement présente sur le PC en NomBD_Old
2. La BD s'ouvre est vérifie qu'il y a une BD Old sur le disque.
3. La BD ouvre les tables liées de Old.
4. La BD récupère les infos des tables spéciales.
5. La BD Supprime BD Old.

Attention : Que fais-tu si la personne fait 2 fois l'installation de suite ?

Là ce qu'on obtient c'est
Installation 1

BD Old vaut Version X (version précédente)
BD Version Y récupère les données de BD Version X
BD Version Y détruit BD Version X

Installation 2

BD Old vaut Version Y (version de la dernière installation)
BD Version Y récupère les données de BD Version Y
BD Version Y détruit BD Version Y

Bref elle se regarde le nombril et tes infos sont potentiellement perdues.

Personnellement je ferai plutôt cela :

Migrer tes tables spéciales dans la dorsale.
Dans toutes tes tables ajouter un champ IdUtilisateur/IdMachine ou tu stockes l'identifiant
Pour MSysBook et MSysTMP mais en plus tu encryptes tes champs de valeur (avec une petite fonction VBA).

Ou alors je stockerai ces informations dans un fichier texte externe (cryptés pour les MSys).

Ça va t'éviter des acrobaties.

Es-tu conscients que cela prend environ 5 mn à contourner tes protections actuelle si on a un "Vrai" Access ?
Surtout si tes données cachées ne sont pas encryptées.

Note que même M$ avec ses millions et tous ses employés n'a pas réussi à protéger ses produits de la copie.
Vois si l'effort en vaut le prix.

A+

[Ric500]

Attention : Que fais-tu si la personne fait 2 fois l'installation de suite ?

Je vois le souci => je pense que je vais opter pour la solution de la dorsale

Bref elle se regarde le nombril et tes infos sont potentiellement perdues.

Je pense que si la la bd de mise à jour ne comporte pas les tables spéciales, elle les importe et supprime la bd old, du coup, si elles sont présentes, elle continue l'ouverture comme d'hab. et tout va bien...

Pour MSysBook et MSysTMP mais en plus tu encryptes tes champs de valeur (avec une petite fonction VBA).

çà, j'y avais pensé et normalement, pas de souci de ce côté là

Après, je suis bien conscient qu'on arrive à tout craquer avec un peu de volonté, ceci dit, je dispose d'un back office, chez moi qui va recenser les utilisateurs officiels, des requêtes d'assistance en provenance d'autres personnes seront donc "suspectes". Les personnes intéressées téléchargent librement mon soft depuis le site internet qui m'envoie un mail automatiquement et cette personne dispose d'un mois d'essai gratuit: après ... le soft démarre tjrs mais n'est plus fonctionnel, il peut tjrs demander une licence payante définitive. Je dispose dans mon soft de backoffice d'une liste de ces gens avec ou sans licence. Il n'en demeure pas moins vrai que le piratage peut-être un point critique. En cas j'écrirai la V2 (si succès de mon soft) dans un langage compilé.

Merci Marot_r de ton intéret et de tes remarques pertinentes, je te plussoie et bravo encore à ce forum que je suis depuis pas mal de temps sans trouver d'équivalent !!!

[argyronet]

Bonjour,

Je me permets de rajouter un petit truc, car confronté à une situation identique, voilà comment je gère le déploiement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 - Ouverture de la frontale.
 - Tentative rattache des tables (avec contrôle du nombre attendu et rejet éventuel si différence).
 - Verification de la version (stockée dans la Dorsale et inscrite en dur dans la frontale).
 - Si différence :
 => message de MAJ nécessaire :
        - si OK
          => exécution des scripts de MAJ (structure, données, objets)*.
               ¤ Si Erreur, Rollback et alerte par message.
               ¤ Sinon MAJ N° version et info du succès de MAJ.
Ouverture écran d'accueil.

* soit directement si application locale ou par EXE si application itinérante (hors connexion)

Si cela peut t'aider...

Argy

[Ric500]

Bonjour argyronet, et merci de ta réponse

Je réponds avec un peu de retard à ton post, mais quand on porte toutes les casquettes (dev inépendant), pfouuu !!
L'algo que tu proposes me paraît intéressant mais soulève une question: comment gères-tu le roll-back?
Bonne continuation

[argyronet]

Bonjour,

Je n'ai pas précisé mais effectivement, tu peux y encapsuler les méthodes BeginTrans, CommitTrans et RollBack en cas d'erreur.

Argy