Discussion :

[olra72]

Bonjour,

Depuis deux ans, je maintiens une base Access sur des postes qui étaient initialement en Windows 8, Office 2013 (ie. Pack Office 15). La base est en dessous de 100Mo, non segmentée, et utilisée par deux à huit personnes à partir d'un disque réseau.

Puis des postes sont passés en Office 2016 (Pack Office 16). Pour éviter une montée de version automatique des références de ma base .accdb de la version 15 à la version 16 (Pack Office, Word, Excel, Outlook), j'ai commencé à distribuer la base au format .accde, tout en produisant cette version sur un poste en 15. De cette façon, plus de montée de version automatique ! Ça a très bien marché pendant deux ans.

Depuis peu, certains postes sont passés en Windows 10, Office 2016 (avec des mises à jour successives) et ça a commencé à merder !

Très régulièrement, la base plante à l'ouverture sur un poste (alors qu'elle tourne bien au même moment sur un autre) et cela provoque la création d'un fichier Sauvegarde, puis Sauvegarde (2), etc.
Souvent, il suffit d'arriver à ouvrir la base en étant seul dessus, de faire un "compacter" et ça repart - sans qu'apparaisse aucune table décrivant les erreurs et/ou des données égarées.

Est-ce que quelqu'un a une idée quelconque de ce qui peut se passer ou de ce qu'il faudrait faire pour cerner le problème ?

Pour info, le service informatique de ma boîte est férocement anti-Access alors je ne peux escompter aucune aide de leur part, juste quelques ricanements satisfaits du genre "je vous l'avais bien dit !".

Cordialement,
Olivier

[rnd]

Bonsoir,

Quand tu dis que la base n'est pas segmentée, tu entend que les tables et tous les autres objets (requête, forms, état...) sont dans la même base, et partagé simplement en réseau? Si c'est le cas je te conseille vivement de scinder en deux ta base, garder les datas sur le partage et tu laisse la frontale sur les postes avec des tables attachées. Ouvrir une base unique, même en accde, avec différente version d'office

J'ai des applis que je dev sous 2010 qui tourne en prod en accde avec ce qu'il y a sur les postes en mix W7-10 et office 2010 à 365.

Cdt, Renaud.

[olra72]

Il y a deux ans, j'avais fait quelques essais avec une base scindée (backend + frontend - tous les deux côte à côte sur le réseau) et les performances s'effondraient dès le deuxième utilisateur, d'où mon retour à une base compacte ! Mais je vais refaire un essai pour voir !

Par contre, déployer le frontend sur les postes des utilisateurs n'est guère pratique. Je produis facilement une version par semaine (on en est à la 237) et je ne peux compter sur aucun support des ITs pour me faciliter le déploiement. Sois j'écris du code pour dupliquer le frontend en local au lancement ... mais, avec un réseau lent, ça va prendre des plombes ... sois je demande aux utilisateurs de procéder eux-mêmes aux copies sur notification ... et ils le feront une fois sur deux.

Pas d'autres idées sur le fait que ça ait marché si longtemps et que, depuis peu, ça crashe une fois tous les dix jours .. ou deux fois par semaine ? J'ai aussi régulièrement des problèmes de partages Windows persistants et même quelques coupures de réseaux franches (ça m'est même arrivé sous Excel - une heure de travail perdue !).

Autre détails : en fait, je gère quatre applications très similaires (avec un nombre d'utilisateurs simultanés variant de 1 à 5-8), et une seule d'entre elle crashe aussi souvent. Une deuxième a crashé une fois. Les autres tournent sans problème.

Cordialement,
Olivier

[micniv]

Bjr,
Je viens juste appuyer et confirmer ce qu'a écrit Rnd :

je te conseille vivement de scinder en deux ta base, garder les datas sur le partage et tu laisse la frontale sur les postes avec des tables attachées. Ouvrir une base unique, même en accde, avec différente version d'office ???

Cdlt

[rnd]

Re;

Par contre, déployer le frontend sur les postes des utilisateurs n'est guère pratique. Je produis facilement une version par semaine (on en est à la 237) et je ne peux compter sur aucun support des ITs pour me faciliter le déploiement. Sois j'écris du code pour dupliquer le frontend en local au lancement ... mais, avec un réseau lent, ça va prendre des plombes ... sois je demande aux utilisateurs de procéder eux-mêmes aux copies sur notification ... et ils le feront une fois sur deux.

Bon on va passer le chapitre de tes ITs, qui visiblement font parties de ceux pour qui Access c'est de la m... et que c'est pas un produit pro et blablabla... et qui ne t'apporteront aucune aide. Et pour les utilisateurs finaux, on est toujours confronté a celui qui ne suivra jamais les consignes, ou pire que fera tout l'inverse. Pas de choix, surtout si tu sort régulièrement des mise a jour de tes softs; il faut que tu gère le moyen de déploiement des tes mise a jour, sur les postes.

Soit en faisant une archive autoextractible avec une config commune pour tous les postes (je parle du chemin d'installation) que tu le laisse sur le partage, dans un dossier MAJ par exemple, avec la procédure pas à pas, pour que l'utilisateur sache toujours ce qu'il doit faire. Cela implique bien sure que l'utilisateur doit avoir l'information qu'une mise à jour est disponible et doit être installée, que ce soit par mail ou par une procédure de vérification de version au lancement du programme; tu peux même dans ce dernier cas, bloquer l'appli si elle n'est pas à jour, avec un message "Vous avez la version 237, la 238 est disponible, veuillez l'installer..."

Soit tu ne fais pas confiance au utilisateur, un peu comme moi , et tu met en place une mise à jour automatique forcée, par script ou programme tiers au lancement de l'appli. Pour ma part, sur les postes client je lances mes appli Access à l'aide d'un script VBS (pour rester dans l'envirronement VB, qui peux même être compiler avec VBStoEXE ou alors tu prend VB Express et tu fait un EXE direct) je test sur sur le serveur, a l'aide de simple fichier INI, si le numéro de version de l’appli est toujours identique, si oui je lance mon ACCDE et sinon, un fs.filecopy ACCDE-mise-à-jour ACCDE-local, puis je lance mon ACCDE , sans oublier de mettre le numéro de version dans INI local.

Cela dit, je rebondis quand sur 2 choses, et là tes ITs devraient se sentir normalement concerné , tu parle de réseau lent et de perte de partage réseau franche; là dessus tu pourras mettre en place tous ce que tu veux, si les éléments sont contre toi, tu ne peux pas y faire grand choses. En tout Access n'aime pas non plus les coupures réseau, forcément ça aide pas

Cdt, Renaud.

[loufab]

Bonjour,
Pour avoir un peu étudié les lenteurs (cf mon tuto toujours d'actualité) de réseaux avec les bases Jet/accd il y a un truc qui est très important. Ta dorsale (celle qui contient les tables) doit être placée le plus près possible de ta racine de partage.
Soit en créant un partage directement sur le répertoire, soit en rapprochant la bdd le plus possible de la racine du disque partagé, idéalement au premier niveau de répertoire.
A noter qu'utiliser un nommage de type 8 caractères peu également aider.

Si après ça il n'y a pas d'amélioration il faudra voir du côté du réseau/serveur.

Concernant la mise à jour, j'utilise la méthode suivante :
1) une table "version" dans la dorsale.
2) une fonction fVersion() dans la frontale qui donne la version de l'appli.

Le but étant de comparer la version de la dorsale avec celle de la fonction et, soit d'afficher un message, soit de faire la mise à jour de la frontale automatiquement depuis l'application.
Je procède de la deuxième manière sans aucun script externe de lancement, juste en faisant une comparaison au lancement de l'appli et un utilisant cette fonction si la mise à jour doit être effectuée.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Function MiseAJour()
Dim vFile As Long
Dim strLigne As String
 
If vgMiseAJourInterdite = True Then Exit Function
'extrait la version
Zip_ExtractFile vgStrRepertoireData & "miseajour\aga.zip", CurrentProject.Name, vgStrRepertoireTemp, False
 
If FichierExiste(vgStrRepertoireApplication & "majAga.cmd") Then fSupprimerFichiers vgStrRepertoireApplication & "majAga.cmd"
vFile = FreeFile
Open vgStrRepertoireApplication & "majAga.cmd" For Output As vFile
 
Print #vFile, ":Loop"
Print #vFile, "tasklist /fi ""imagename eq msaccess.exe"" |find "":"" > nul"
Print #vFile, "if errorlevel 1 goto loop"
Print #vFile, "copy """ & vgStrRepertoireTemp & CurrentProject.Name & """ """ & vgStrRepertoireApplication & CurrentProject.Name & """ /Y"
Print #vFile, "DEL """ & vgStrRepertoireTemp & CurrentProject.Name & """ / Q"
Print #vFile, """" & vgStrRepertoireApplication & CurrentProject.Name & """"
 
Close #vFile        ' Ferme le fichier.
pAttendre 50
 
Shell "cmd /K """ & vgStrRepertoireApplication & "majAga.cmd"""
 
End Function

vgMiseAJourInterdite me permet de fonctionner en mode débug et évite la mise à jour. Tu dois la mettre à false dans la version livrée en exploitation.
vgStrRepertoireData est le répertoire de la dorsale, je place la mise àjour dans le répertoire miseajour de ce répertoire.
fSupprimerFichiers() est une simple fonction de suppression de fichier, tu peux la remplacer par un remove.
vgStrRepertoireApplication est le répertoire de l'application frontale (sur le poste client).
vgStrRepertoireTemp est un répertoire temp.
pAttendre() est une procédure d'attente,
Zip_ExtractFile() permet d'extraire un fichier zip. On peut la trouver dans la faq.
FichierExiste() vérifie l'existence d'un fichier.
Tout cela c'est de la plomberie l'important c'est la création du fichier cmd qui va provoquer la mise à jour.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
Private Declare PtrSafe Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)
Sub pAttendre(TimeInMilliSec As Long)
'---------------------------------------------------------------------------------------
' Procedure : pAttendre
' Author    : Fabrice CONSTANS (MVP)
' Date      : 17/03/2016
' Purpose   : fait une pause de TimeInMilliSec
' Parameters:
' Return    :
'---------------------------------------------------------------------------------------
'
      If TimeInMilliSec > 0 Then
        Call Sleep(TimeInMilliSec)
      End If
End Sub

Donc après comparaison, l'application copie la nouvelle version zipée dans le répertoire temp du poste client, la dézipe.
Puis crée un batch, lance le batch et rend la main à l'application pour fermeture.
Le batch attend de ne plus avoir l'exécutable MsAccess.exe dans les tâches en fonctionnement (la fermeture).
Quand c'est le cas, elle copy(écrase) la version du client et relance l'application nouvelle version.

Reste qu'à adapter tout ça à ton application.

A noter qu'il y a d'autres exemples dans les contributions.

Cordialement,

[olra72]

Super ! Merci ! Je pensais me diriger vers un truc du genre et, là, Miracle, c'est déjà tout fait !

De passer à une base segmentée m'a obligé à renoncer aux dbOpenTable et aux macros de tables. Je vais laisser tomber aussi les champs calculés, les pièces jointes et je serai prêt à basculer (si besoin) sur du MySQL .... Ah non ! Il me reste encore à voir les champs multi-valués dont j'ai fait un usage intensif ...

Pour distinguer la version de dév de la version de prod, je me base sur le nom de l'appli : SiGaLab, c'est de la prod, SGL_XXX, c'est de la dév - et tout autre nom, c'est du bac-à-sable.

Encore merci !

[rnd]

une base segmentée m'a obligé à renoncer aux dbOpenTable et aux macros de tables.

LA pour le coup il faut tout remplacer par openDynaset, effectivement. Par contre pour les macro de table sur le Backend, pas besoin de les supprimer, cela fonctionne toujours. J'en utilise pas beaucoup mais cela fonctionne. Pour le reste je ne sais, je ne les utilises pas du tout.

Bonne continuation

Cdt, Renaud.

[loufab]

dbopendynaset pour ceux qui sont en lecture/ecriture et dbopensnapshot pour ceux en lecture seule sont les plus courants.

Les champs multivalués à remplacer par une simple table.
Les Pj par des blob.

[olra72]

Bonjour,

Si les macros de tables font appels à des requêtes qui sont dans le front-end, ça ne marche plus. Mais, de toute façon, pour la tranquillité de mes successeurs éventuels (voir pour un transfert vers MySQL), j'envisageais déjà de me passer de ce genre de truc...

Sinon je viens de souffrir sur un équivalent des champs multi-valués à base de table de jointure et de mini-formulaire modal maison (autodimensionnable). Comme je ne touchais pas directement au recordset, j'avais passé le type du recordset du formulaire à "Instantané" et, là, surprise : avec des tables locales, ça marchait impec (ie. quand je cochais/décochais une case, un INSERT ou un DELETE dans la base suivi d'un Me.Requery, me donnait un recordset mis à jour) mais avec des tables liées, il ne se passait plus rien, le Me.Requery semblait sans effet. Il me fallait fermer et rouvrir le formulaire pour voir mes coches enfin mises à jour.

J'ai repassé le type du recordset en "Feuille de réponse dynamique", et, maintenant, ça marche pareil avec des tables locales ou avec des tables liées ! Access, c'est subtil et parfois obscur ! Faut pas stresser ...

Moi qui pensait garder un environnement de dév avec des tables locales (c'est quand même plus commode pour les modifs synchronisées tables/code) et ne passer en tables liées que pour la version de prod, je crois que je vais revoir ma stratégie.

Super, ces forums - on ne le dira jamais assez ! D'un autre côté cela permet à des outils hyper-mal documentés (voire indocumentables) de se développer. Alors j'espère que MicroSoft vous envoie des chocolats pour Noël !

Cordialement,
Olivier

[loufab]

...

Alors j'espère que MicroSoft vous envoie des chocolats pour Noël !

...

Non mais tu peux toujours le faire.

[rnd]

Non mais tu peux toujours le faire.

+1, en plus c'est bientôt Pâques.

[olra72]

Encore dix milles merci à Loufab pour son script de mise à jour du Front-End ! Ça a marché du premier coup! YEAaaH !

Plus que deux trois petits détails et j'aurais ma nouvelle trame applicative en mode fractionnée, avec connexion des utilisateurs en mode SSO (Single-Sign On), permutation d'utilisateurs sur demande (pour pouvoir prendre la main sur la session d'un collègue et le dépanner avec des droits étendus), gestion du contexte prod/dév avec sécurisation du Back-End de production, gestion des montées de versions ... et création de bac-à-sables auto-porteurs qu'on peut emporter à la maison.

Reste à voir si, une fois tout ceci mis en service sur mes quatre applications Access, je n'ai plus les crashs qui ont motivés tout ça !