Discussion :

[LeMin]

Bonjour à tous,

Un de mes traitement exécute un traitement un peu long (30 secondes) qui fait planter l'application quand je travaille sur le réseau d'entreprise. Le même traitement avec la base en local sur le poste se termine correctement.

La configuration:
- développement en access 2007 (en .accdlb converti en .accde)
- une base sur chaque poste W10 qui exécute l'application, l'autre base sur le serveur (data)
- tous les postes exécutent le .accde avec le runtime 2007
- l'accès au réseau est donné par le MAP Lettre R
- le serveur est un serveur microsoft qui partage le dossier en L/E à tous, et qui définit le map (R) au login

Quand ça se plante, la base Data se trouve dans un état incohérent. Nécessité de la réparer. Quelquefois, la réparation ne suffit pas (index ko, tables absentes).

Merci pour toutes vos idées

[Jean-Philippe André]

Salut,

les idées évidentes qui me viennent en tête :
- raccourcir le temps de traitement
- segmenter ton traitement

[LeMin]

Salut,

les idées évidentes qui me viennent en tête :
- raccourcir le temps de traitement
- segmenter ton traitement

Merci @jean-philipe pour ton intérêt. Qu'entends tu par segmenter ?
Et j'ai lu qu'il valait mieux utiliser le chemin complet du serveur plutôt qu'un Map: tu en penses quoi ?

[Jean-Philippe André]

Le mapping vers un autre point du réseau ne me gène pas outre mesure, mais il peut y avoir conflit avec un autre R sur certains postes ?


Pour la segmentation, l'idée serait de faire des codes en plusieurs étapes, et non pas des scripts qui font plusieurs centaines de lignes de code…


Tu peux par exemple passer par des tâches planifiées qui effectuent les traitements par morceaux...

[LeMin]

Le mapping vers un autre point du réseau ne me gène pas outre mesure, mais il peut y avoir conflit avec un autre R sur certains postes ?

Pour la segmentation, l'idée serait de faire des codes en plusieurs étapes, et non pas des scripts qui font plusieurs centaines de lignes de code…
Tu peux par exemple passer par des tâches planifiées qui effectuent les traitements par morceaux...

Non, pas de conflit: le R est défini par le serveur au loggin de la personne. A priori, ce sont tous les même.

Le code qui génère un traitement long n'est pas très long. Et l'utilisateur a besoin du traitement pour continuer. Il faudrait plutôt que je regarde comment diminuer le temps de traitement, en organisant les données ou les requêtes autrement ...

As tu souvent entendu parler de ce plantage inexpliqué qui laisse la base data en vrac ?
Penses tu que ce soit dû au Runtime qui exécute le prog. plutôt que le programme complet ?
Je suis en version 2007. De passer à une version plus récente peut être bénéfique ? (j'ai peur des compatibilités !)

Merci

[Jean-Philippe André]

En principe, utiliser des versions récentes ne peut être mauvais ^^

Les plantages sont tous identiques et uniques èa la fois, il faudrait voirle code, tenter de reproduire l'erreur en local, bref faire du support en conditions réelles

[LeMin]

En principe, utiliser des versions récentes ne peut être mauvais ^^

Oui, je pense aussi que la V2019 pourrait mieux être optimisée. Mais une récente expérience me fait hésiter: en effet, l'application exporte et importe un fichier excel avec des champs mémo longs.ça marche nickel sauf si on utilise un access 365 au lieu du runtime 2007: les libellés sont tronqués à 256 carracteres à l'importation !

Il faudrait voir le code, tenter de reproduire l'erreur en local, bref faire du support en conditions réelles

Oui, mais jamais de plantage en local . Je vais regarder sur la diminution du temps de traitement ...

[loufab]

Bonjour,

Mais une récente expérience me fait hésiter: en effet, l'application exporte et importe un fichier excel avec des champs mémo longs.ça marche nickel sauf si on utilise un access 365 au lieu du runtime 2007: les libellés sont tronqués à 256 caractères à l'importation !

C'est un problème connu qui touche toutes les versions d'ACCESS. C'est dû à l'analyse du contenu des premières lignes mémo récupérées.

Cordialement,

[LeMin]

Bonjour,



C'est un problème connu qui touche toutes les versions d'ACCESS. C'est dû à l'analyse du contenu des premières lignes mémo récupérées.

Cordialement,

Et je redoute aussi d'autres incompatibilité du coup

[nico84]

Bonjour,

Quelle est la taille de la dorsale ? Est-elle compactée régulièrement ? Combien d'utilisateurs simultanés ?
Il est peut-être temps de migrer les données vers une base client/serveur

[LeMin]

Bonjour,

Quelle est la taille de la dorsale ? Est-elle compactée régulièrement ? Combien d'utilisateurs simultanés ?
Il est peut-être temps de migrer les données vers une base client/serveur

Bonjour Nico84,
merci de t'intéresser à mon sort !
- la taille du .accde diffusé sur tous les postes est 120M
- la taille des datas sur le serveur est 80M: elle est compactée régulièrement (quand je fais une nv version généralement)
- il doit y avoir au max 4 utilisateurs simultanés

[nico84]

Cela me semble raisonnable mais mon sentiment est que MS abandonne progressivement access car le stockage de données n'est pas délocalisable.
S'il s'agit d'une application importante je te conseille de préparer la migration des données cela règlera bien des problèmes. La frontale peut rester en access tant que l'appli reste sur un seul site.

[LeMin]

S'il s'agit d'une application importante je te conseille de préparer la migration des données cela règlera bien des problèmes. La frontale peut rester en access tant que l'appli reste sur un seul site.

Qu'entends tu par la "migration des données" ?
Tu veux dire ailleurs que sur un dossier partagé ?
Cela représente beaucoup de travail ?

[nico84]

J'entends par là remplacer la dorsale access par une base client/serveur (oracle, sql server, mysql...)
Pour ma part j'utilise sql server
Cela peut se faire relativement facilement mais pour que ça marche bien il faut réécrire toutes les (grosses) requetes VBA en ADO

Dans mon cas cela m'a permis de sauver ma frontale qui représentait un gros développement

[LeMin]

J'entends par là remplacer la dorsale access par une base client/serveur (oracle, sql server, mysql...)
Pour ma part j'utilise sql server
Cela peut se faire relativement facilement mais pour que ça marche bien il faut réécrire toutes les (grosses) requetes VBA en ADO

J'avis regardé un peu le sujet, liaison avec sql server via odbc.
J'avoue que je me suis laissé impressionner par la ré écriture VBA en ADO.
Mais, j'aimerais bien essayer ...

Pour l'heure, je vais me concentrer sur "réduire le temps de traitement".
Je pense que ça améliorera la stabilité de l'application.

En tous cas, merci pour ces pistes d'amélioration

[nico84]

J'avoue que je me suis laissé impressionner par la ré écriture VBA en ADO.

Il y a de quoi... La syntaxe est "presque" la même et cela peut dans un 1er temps ne concerner que les requetes complexes.

[LeMin]

Il y a de quoi... La syntaxe est "presque" la même et cela peut dans un 1er temps ne concerner que les requetes complexes.

Alors là, tu me tentes.

Je vais déjà essayer de réduire le temps de calcul.

Si je décide de me lancer en un 2eme temps, pourrais je te demander plus précisément comment faire le passage ?

[nico84]

Si je décide de me lancer en un 2eme temps, pourrais je te demander plus précisément comment faire le passage ?

Sans garantie de disponibilité ou alors pas gratuitement - c'est mon métier !

[LeMin]

Sans garantie de disponibilité ou alors pas gratuitement - c'est mon métier !

Je comprends tout à fait ton point de vue. Je développe moi même et je facture !

Il ne serait pas question du blocage actuel, mais juste me mettre sur la piste pour une petite application "test".

En 2018, voici ce que j'avais crée:
1) j'ai crée un site internet local (hébergé en local sur un PC) en Joomla via easyPhp.
2) La BD sql est "partagée" sur ce pc via OBDH
3) et mon applic Access "voit donc" les tables de ma base de données SQL (du site internet)

Voici le type de questions que je risque de te poser:
- Suis je sur la bonne piste pour l'accès aux données ?
- quelle est la syntaxe pour passer de VBA à ADO ?

[nico84]

Vu ton expérience tu ne devrais pas avoir trop de difficultés. Le plus dur est de faire les bons choix au départ et les miens ne seront peut-être pas adaptés à ton cas.

Pour ma part j'ai développé un ERP pour PME en access il y a 12 ans (ça passe...) et je l'améliore depuis. Quand j'ai rencontré les limites d'access sur le volume de données j'ai d'abord voulu migrer vers postgres mais par manque de conseils et de tutos je n'ai pas réussi.
Ensuite j'ai essayé avec une base azure, ça a marché assez rapidement mais avec des temps de réponse catastrophiques !!!
Finalement j'utilise une base sql server express, c'est gratuit et ça marche très bien depuis 5 ans. Le plus dur a été de la paramétrer pour un accès multi-utilisateur sécurisé, je n'avais aucune expérience d'administrateur de BD.

Mon ERP a un accès ODBC vers les tables MSQL donc cela n'a rien changé pour toute la partie fenêtrage, j'ai juste dû dépouiller quelques fenêtres un peu longues à s'ouvrir.

Par contre j'ai repris tout le code VBA pour que les requêtes soient compatibles access / msql. Par exemple cela donne ceci :

Code :

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

1
2
3
4
5
6
7
8
9
      rst.Open "SELECT t.cd_tache, t.phase as poste, t.id_of as cd_of, t_tache as nop, fnom as libelle, t.qui, id_article as draw_ref" _
      & ", t.description as designation, sum(T) as T0, " _
      & IIf(msql, "datepart(dw,dateadd(d,1,p.jour))", "weekday(p.jour)") & "  as W, t.Tbudget+t.Tbudsup as Tb, t.Tpointe as Tp, " & IIf(msql, "coalesce", "nz") & "(max(p.date_trans),0) as imp " _
      & "FROM (pointages as p inner join taches as t on p.cd_tache=t.cd_tache) inner join tiers on t.cd_tiers=tiers.cd_tiers " _
      & "WHERE cd_pers=" & x_cd_pers & " and jour>=" & IIf(msql, "", "cdate") & "('" & x_jour - 1 & "') and jour<=" & IIf(msql, "", "cdate") & "('" & x_jour + 5 & "') " _
      & "GROUP BY t.cd_tache, t.phase, t.id_of, t_tache, t.qui, id_article, fnom, description, " & IIf(msql, "datepart(dw,dateadd(d,1,p.jour))", "weekday(p.jour)") & ", t.Tbudget+t.Tbudsup, t.Tpointe " _
      & "UNION ALL SELECT cd_tache, phase, id_of, t_tache, fnom, qui, id_article, description, null, null, t.Tbudget+t.Tbudsup, t.Tpointe, 0 " _
      & "FROM taches as t inner join tiers on t.cd_tiers=tiers.cd_tiers WHERE etat<='P' and qui='" & qui & "' " _
      & "ORDER BY 1;", cnx, adOpenStatic

cnx étant une connexion ADO ouverte en permanence sur la base à interroger (elle peut être access ou MSQL)
Ensuite l'utilisation du recordset est la même

Si la même requete était faite sur la base MSQL en DAO, comme il y a des jointures et une union, ce serait le PC du client qui la découperait en une multitude de sous-requetes élémentaires qu'il enverrait au serveur et même avec la puissance des ordis d'aujourd'hui ça mettrait des plombes ! Par contre les requetes simples peuvent rester en DAO sans souci car JET (le moteur DAO d'access) la sous-traite en une seule fois.

Mon défi pour les années à venir : développer des modules avec un outil web pour interroger ma base avec un utilisateur distant, ce qu'access ne sait pas faire...

Mon plus gros client a 40 utilisateurs et 500Mo de données. Ca a commencé à merdouiller avec access à partir de 10 utilisateurs et 200Mo mais chez d'autres clients j'ai eu des problèmes bien plus vite. MSQL n'est peut-être pas la bonne solution pour toi, par contre je pense que dans la stratégie MS, access est un avatar de la suite personnelle office et rien d'autre.

Bon courage !