Bonjour,
je viens de développer un petit logiciel sous access.
j'ai une base qui se trouve sur mon serveur (mappage L et mon programme qui va se trouver sur différents postes.
Afin de pouvoir contrôler facilement que la version qui se trouvera sur un des postes est bien la dernière, je souhaite mettre en place un contrôle de version.
Il me faut donc quelque chose qui, quand je fais une modif du programme sur le serveur, incrémente la version. Mais attention, la version ne doit pas être incrémentée si je ne fais qu'utiliser le programme.
Je ne sais pas si ma demande est bien formulée mais si toutefois vous pouvez m'aider. Merci.
Si vous avez besoin de précisions, n'hésitez pas.

salut,
moi pour résoudre ce pb, j'ai créé un fichier txt qui contient la valeur de la derniere version, et lors de l'ouverture, je teste currentversion qui est une varialbe globale et si la valeur est antérieure, alors je fais la mise à jour

ok, pas de pb mais la valeur qu'il y a dans ton fichier txt, elle y est arrivée comment ? En fait, c'est la que je coince.

la valeur dans le fichier texte, c'est toi qui la met à jour,
et tu lis la valeur à chaque ouverture de l'appli

bah justement, c'est ce que je ne veux pas.
Je veux que ce soit automatique.
Au passage, Pourquoi tu t'embètes à passer ça en fichier texte (externe) alors que tu pourrais avoir une table qui gère ça direct dans la base !

J'ai une idée, je ne sais pas si c'est possible mais vous allez me le dire.
Peut-on exécuter une macro lorsque l'on réalise l'action d'enregistrer les modifications du programme ?
Si vous me trouvez ça, le reste, j'en fais mon affaire (je pense).
Merci

euh, before_close ?

bah je sais pas, le before_close c'est à chaque fois que tu fermes ? ou c'est à chaque fois que tu fermes en modifiant ?
Sinon, existe-t-il une fonction que l'on mettrait dans le before_close qui permettrait de savoir si des modifications ont été faites (sur le prog) depuis l'ouverture ?
Je pense qu'il doit exister pas mal de solutions, le tout est d'en trouver une qui fonctionne.
Par contre, le before_close, tu le mets sur un formulaire ou il est possible de le mettre indépendament du form dans le prog ?
Merci de t'intéresser à mon cas ! ;-)

non mais mettre à jour le fichier texte ca te soule ? parce que c'est AMHA le moyen le plus simple pour répondre à ta problématique...

AMHA ???

A mon Humble Avis

ah ok,
mais le problème c'est qu'il faut impérativement que le fichier se mette à jour tout seul.
Peu importe la méthode, ce qui m'intéresse réellement est le fait de détecter l'enregistrement et donc la modification de version pour pouvoir m'en servir ultérieurement.
C'est cette détection qui me manque.

y'a personne pour m'aider ?

abandonner Access au profit d'un vrai programme ? du coup tu récupères la version du build

pas très constructif.
j'ai vraiment besoin de cela, j'ai déjà 8 bases qui tournent et c'est un casse tête de connaitre les versions parce que nous (mon collègue dévelo et moi-même) ne pensons pas forcément à mettre à jour le numéro de version.
Le but est donc de rendre cela AUTOMATIQUE. Et je sais que c'est possible. Il y a même plusieurs méthodes que j'ai exploré mais sur chacune je bug sur un point ou un autre.
Il y a forcément une solution, même si ma version n'est que la date de dernière modif, pourquoi pas. J'ai testé ce genre de truc mais la date que je réccupérait changeait à chaque fermeture du prog même sans avoir fait la moindre modif :-(

alors ? personne ?

tjs personne ?
Ca doit pourtant être faisable ?

Et pourquoi ce serait faisable ?
 
Quand tu écris un document Word, y'a un numéro de version qui s'incrémente ? Non.
Bah Access, c'est pareil
 
Revoyez vos méthodes de développement et de déploiement surtout. Et dis pas que cette réponse n'est pas plus constructive que l'autre, y'a pas de solution bancale pour résoudre ton problème boîteux, c'est tout

Evidemment que non !!!
Si tu avais lu tout ce que j'ai écris, je cherche justement le moyen de le créer ce numéro !
 
Une réponse non constructive est une réponse qui ne fait pas avancer les choses.
 
Une critique c'est bien, mais il faut proposer des solutions pour permettre à ce que l'on critique de ne plus être critiquable.
 
Le fait de dire qu'il faut que je change de langage est tout simplement idiot.
Si je me fais chier avec Access c'est que j'en ai pas le choix. (contraintes de hiérarchie et de compatibilités d'anciens progs)
 
Donc si tu ne sais pas répondre à mon problème, qui est solutionnable puisque j'ai trouvé des débuts de réponses sur le net mais pas suffisants pour me permettre de créer la solution complète, hé bien passe ton chemin.  Merci.

xav, je ne suis pas sûr que le prendre de cette façon te fera bcp avancer sur ce forum. Pour ma part, je pense que la solution que je t'ai donnée est la plus simple, même si ca enquiquine ton develo et toi...
N'oublie pas que lorsque tu est demandeur, la moindre des choses est de prendre en considération les propos de ceux qui participent "constructivement" au forum.

Problème de développement :
- Les protagonistes ne sont pas capable de notifier les autres de leurs propres modifications
- Aucune communication ne permet de centraliser qui a fait quelle modification quel jour
=> Désolé, mais là il y a un vrai gros problème. C'est pas un numéro de version dont t'as besoin, mais surtout de personnes qui savent écrire de la doc et notamment allimenter un CHANGELOG.
 
Problème de déploiement
- Une version "serveur"... mais distribuée sur tous les postes clients
=> On peut savoir pourquoi les utilisateurs n'utilisent pas directement la version qui est partagée sur le serveur ?
 
Bref

jpcheck => tout à fait, et c'est pourquoi quand tu m'as répondu, je t'ai simplement dit que ce n'était pas la solution que je cherchais. Sans pour autant te critiquer ou te dire que t'es un gros nul de pas savoir faire ça. Je ne t'ai manqué de respect à aucun moment. Et je cherche des solutions. J'ai même proposé des pistes pour que ceux qui les lisent aient peut-être une idée. Mais bon.
Il me faut juste un truc qui, quand je ferme ma base après avoir fait des modifs m'incrémente un numéro ou me stocke la date ou plus simplement m'exécute un code (comme ça je pourrais mettre ce que je veux dedans). Le tout est que cela doit s'exécuter sur l'enregistrement des modifs de formulaires et pas sur les saisies de données.
Ta solution est bonne en elle, mais le problème c'est que je ne suis pas seul. Et outre mon second, il y a quelques personnes dans la boite qui me rajoutent des fonctions de temps à autres parce qu'ils bidouillent un peu. Et ces gens-là n'iront pas écrire dans le fichier texte. D'où le problème que je pose, l'automatisation.
Et je n'ai même pas besoin d'un CHANGELOG comme le propose MagicBuzz parce que les modifs, ce n'est pas ce qui m'importe, les gens savent très bien ce  qui a été fait ou pas et je n'ai pas besoin de ce genre de choses. Deplus, si je suis le seul à le mettre à jour, autant dire qu'il ne servira à rien du tout.
Je sais que ce serait très simple que tout soit noté, le problème c'est que dans la configuration actuelle, c'est strictement impossible.
Et malheureusement pour mon problème, je suis obligé de laisser ceux qui le souhaitent ajouter quelques fonctions. Ca leur simplifie la vie, je ne suis pas toujours disponible pour leur faire et en plus ils savent bien mieux que quiconque de quoi ils ont besoin. Donc je dois leur laisser cette possibilité. Simplement, après, quand je passe sur un poste et que l'on me dit que tel truc ne fonctionne pas, je ne suis à ce jour pas capable de savoir s'il s'agit de la dernière version ou non. Donc obligé de faire la mise à jour même quand elle est inutile.
D'où ma demande d'automatisation. Ou si vous préférez, d'exécution de code à l'enregistrement de modifs sur formulaires ou états. Ou encore s'il existe une date dans le fichier qui corresponde à cette dernière modif ou autre, il y a plusieurs pistes (d'après ce que j'ai pu voir sur le net). Mon seul souci est de rendre cela automatique.

Indépendamment de l'aspect bancal de l'organisation que tu mets en place, il est possible de créer des propriétés personnalisés pour une base.
Personnellement je crée une propriété « Version » (menu Fichier, Propriétés de la base, onglet Personnalisation) que j'incrémente manuellement quand je fais des modifs.
Je n'ai jamais eu à automatiser ce système car sur Access je bossais seul et je ne développais jamais sur la version d'exploitation (donc mise en exploitation = incrémenter version).
Il est très facile après de faire des procédures de test de version, voire des mises à jour auto des clients en fonction de la version serveur.
 
Je ne connais pas d'événement lié à la fermeture d'une base Access pour automatiser l'incrémentation de la version.

tegu=> "Il est très facile après de faire des procédures de test de version, voire des mises à jour auto des clients en fonction de la version serveur."
peux-tu m'en dire un peu plus s'il te plaît, peut-être une piste à explorer pour moi.
Merci

de mon côté pas de pb hein, mais je n'aime pas trop qu'on tape sur ceux qui apportent de l'aide, si peu constructif peut-il sembler selon tes termes .
le côté multi-utilisateur est complexe à gérer, dans la mesure où si chacun apporte sa pierre à l'édifice ca complique le déploiement si aucune info n'est stockée pour faire le point des mises à jour intermédiaires.  
Je propose à ce moment là de faire une autoincrémentation dans un fichier texte (oui je m'y tiens mais ca reste possible selon cette méthode). A chaque ouverture du fichier en mode modification, access va lire le fichier et incrémente la valeur contenue.
La limite de ce système vient dans le fait qu'un fichier Access peut être ouvert par plusieurs personnes simultanément, et là ca coince de tte manière, car comment savoir qui a la main etc. Les fichiers texte restent les éléments les plus simples et rapides à utiliser, sans passer forcément par une masse de code.
 
Quelles pistes issues du net es-tu en train de suivre, qu'on essaie de faire avancer le schmileumileumil...

jpcheck=> lol, là actuellement je ne suis pas sur ça. Je m'y suis mis un peu ce matin mais j'ai dû me mettre à faire autre chose.
Ce que j'ai tenté de faire c'était de récuppérer les infos du fichier, j'ai regardé un peu tout ce que je pouvais, les dates principalement, mais je n'ai pas trouvé mon bonheur. Peut-être suis-je passé à coté de quelque chose.
Si ta solution permet un autoincrément, je veux bien voir à quoi elle ressemble. Je pourrais peut-être ajouter une manière de gérer les ouvertures simultannées (bien que j'en doute), Et puis c'est assez rare pour être franc, que l'on soit plusieurs à modifier en même temps. On est effectivement plusieurs à modifier mais c'est rarement en même temps.
 
 
 
""on tape sur ceux qui apportent de l'aide""
c'est cette phrase que je n'ai pas aimé :
"abandonner Access au profit d'un vrai programme ?"
je n'appelle pas ça de l'aide. Ca me fait penser à un gars à l'IUT qui me suggérait d'installer Linux pour modifier la taille d'une de mes partitions alors que j'étais sous windows.
Si je suis sous Access, c'est que je n'en ai pas le choix. Pour ma part, je préfère le Java, après, chacun ses défauts. Sinon, j'aime bien le batch aussi. J'avais réalisé un batch qui calculait l'url à envoyer dans vlc pour enregistrer automatiquement les guignols de l'info tous le jours à partir du streaming web du site c+. Mais ils ont changés les URL à la rentrée, faut que je m'adapte ! lol
Enfin bon, voilà. C'est ce genre de phrase que je n'appelle pas de l'  "aide". Pardon pour ceux que ça a pu choquer.

Que ça te plaise ou non, et que t'es les moyens ou non, c'est pas ça le problème.
 
Utiliser Access de la façon que tu décris, ça pose un véritable problème, qui ne se cantonne d'ailleurs pas seulement aux soucis de versionning.
 
Déjà, tu peux faire un truc très simple, basé sur mes deux suggestions (parceque désolé, peut-être que tu trouves qu'elles ne t'aident pas, mais elles reposent sur le problème de faond et c'est dans ce sens là qu'il faut aborder ton problème).
 
=> Basculer tes données sur une base de données "externe" à tes formulaires Access. Ca peut tout aussi bien être une autre base Access comme un autre SGBD. Via ODBC, tu peux lier les tables d'une autre base de données, tout en conservant leur nom original : tu n'as donc pas une ligne de code à modifier dans ton programme.
 
=> Une fois que ta base Access ne contient plus que les formulaires et le code, c'est pas compliqué, tu colles cette base "vide" sur un répertoire partagé, et tout le monde tape dedans, en lecture seule : vu que les données sont distantes, ça n'empêche pas les modifications des données.
=> Celui qui veut faire une modif ouvre en modification, et vu qu'il va enregistrer sur le serveur, tout le monde bénéficie immédiatement de la nouvelle version. Seul hic, on ne peut faire ces modifs que lorsque personne n'utilise l'outil.
 
Alors après, t'as décidé que je ne t'aidais pas, donc continue à chercher une solution qui n'existe pas à un problème qui n'en est pas un, et ignore mes posts, c'est ton problème à toi, et toi seul à la solution, vais pas me battre pour te faire ouvrir les yeux.

>pxav22: ta nouvelle propriété « MaVersion » est accessible par l'objet Database et sa collection .Properties
Tu peux donc la tester en local et sur le serveur dès l'ouverture de ton programme Access, comparer les deux versions et choisir le comportement à adopter en conséquence.
 
J'ai oublié de signaler qu'il ne faut pas confondre avec la propriété .version de ton CurrentDB. Il s'agit ici de la version du moteur Jet.
Ta nouvelle propriété ne peut pas s'appeler « Version » tout court je crois, contrairement à mon premier message.

tegu > le souci, c'est qu'il veut un truc automatique, parceque personne dans sa boîte n'a la rigueur nécessaire pour faire l'effort de mettre à jour le truc quand il fait une modif (sinon je vois pas ce qui cloche avec le fichier texte...)

Il suffit de faire une retenue sur le salaire à chaque oubli, ça motive
Blague à part, je ne pense pas que ça soit possible.
À part s'immerger dans les objets système et peut-être la programmation de compléments, mais le jeu ne me semble pas en valoir la chandelle.

MagicBuzz=>"""Basculer tes données sur une base de données "externe" à tes formulaires Access. Ca peut tout aussi bien être une autre base Access comme un autre SGBD. Via ODBC, tu peux lier les tables d'une autre base de données, tout en conservant leur nom original : tu n'as donc pas une ligne de code à modifier dans ton programme."""
Je te signale que c'est déjà le cas. Et c'est écrit plus haut.
Par contre, dans ma config, tout le monde peut faire les modifs qd il veut. Ensuite, il attend qu'il n'y ai personne sur la base (ou il fait sortir tout le monde) de façon à importer ses modifs sur le prog partagé sur le serveur.
Pour ce mettre à jour, chaque client télécharge le prog qui est sur le serveur sur son propre disque.
Mon but n'est pas que tout le monde bénificie immédiatement de la nouvelle version mais que l'on sache où on en est dans les versions.
là tu es contructif.
 
tegu> ok, merci beaucoup, je vais tester dès que possible.
 
MagicBuzz> le problème c'est que ma "boite" comme tu dis, c'est pas que des informaticiens dedans. On est deux informaticiens pour gérer le matériel, le logiciel, le développement, les réseaux. L'entreprise dans laquelle je suis est éclatée sur 7 sites différents et le sera bientôt sur 9 ! Je sais très bien que ce serait si pratique que tout le monde fasse toujours tout bien, mais je connais les gars qui bossent dans l'entreprise et c'est même pas la peine d'y songer. Même si je leur dis, ils vont le faire trois fois et puis après plus jamais. Et même en leur rappelant souvent, ça ne change rien. J'ai déjà eu plusieurs fois le cas où tu leurs dis de le faire le matin et le soir même ils font une modif sans informer qui que ce soit. (j'avais mis en place une table dans laquelle à chaque modif il suffisait d'ajouter une ligne, la date s'y mettait automatiquement et ça nous servait de version. Je viens de vérifier, le logiciel a été mis en service en 02/2002 et la dernière date de version est en juillet de la même année). Je suis désolé de vous embêter avec ça, mais si je le demande, c'est que j'en ai besoin parce que le facteur humain de mon entreprise n'est pas ... fiable !
merci.

"Il suffit de faire une retenue sur le salaire à chaque oubli, ça motive"
 
ça serait pas bète, ça serait peut être une solution à soumettre à mon patron

C'est justement pourquoi je ne comprends toujours pas pourquoi tout le monde n'utilise pas directement le fichier partagé. Pourquoi faire une copie locale ? Utiliser un raccourci sur le bureau serait autrement plus simple à mon sens, et résoudrait ton problème de "mais où est donc passé la dernière version".
(Ca ne résoud pas le problème de versioning en lui-même, mais de toute façon ça ne semble pas être ce que tu cherches donc c'est pas bien gênant)

Le patron, y'a pas de souci il va aimer... C'est les délégués du personnel qui vont pas aimer