Bonjour,
Habituellement, une mise à jour avec réorganisation de la BDD prends entre 20 et 30 mn.
Avec la v2.2 je suis déjà à plus d'1h30, durée que j'estime anormale bien que la mise à jour ne semble pas plantée (des écritures dans la table temp_devisligne se font...)
Avez vous rencontré ce problème ? Si oui, combien dure la mise à jour (afin de la replanifier à un moment plus opportun)
Merci

Bonjour,
Nous avons constaté que certaines migration vers les V.2.20 peuvent être longue. Dans un premier temps, êtes vous sur le serveur ou postes serveur pour faire la migration de données ? Si vous faites la migration depuis un "poste client", cela peut être long ou très long (par expérience).
Deuxièmement, de quelle version vient le dossier société ? Les migrations peuvent prendre du temps ou plantées à cause de champs supplémentaires.
Troisièmement, il est toujours préférable de faire une réorganisation de donnée avant de procéder à une migration (par expérience).

Apifrog

En réponse à vos questions : Mise à jour depuis la v2.1 sur un serveur

Le support SAGE m'a indiqué que ce n'était pas normal et m'a conseillé de faire une réparation des bases via Access car elles pouvait être selon eux endommagée.
Effectivement après cette manipulation, la procédure de mise à jour / réorganisation a été nettement accélérée (moins de 10 mn).

Bonjour
La réorganisation avec Access est devenue la nouvelle mode de la hotline Sage après avoir dit pendant des années de ne pas faire cette manip et de passer par la boite à outils ou l'analyseur.
Peuvent en est, pendant un moment en ouvrant la base Sage avec Access vous aviez un message vous informant que la base n'était plus garantie par l'éditeur.

Mais, comme ils ont décidé de ne plus mettre à jour la boite à outils partenaires, on repasse par la formule "réparation par "ACCESS" (retour en 2008....).

Entre nous, la boite à outils partenaire faisait la même chose : une réparation de base de données par l'ODBC Access.
Si vous n'avez pas ACCESS ou qu'il n'est pas installé sur le poste du client, vous pouvez toujours passer par l'ODBC Access pour faire la réparation.

En faisant une réorganisation (traitement exhaustif) de l'ancienne base par le logiciel en version N-1 puis en migrant vers la nouvelle version et en refaisant une réorganisation sur la version N, nous n'avons jamais (ou très très exceptionnellement) eu à refaire de réparation avec ACCESS suite à migration.

Le principal est le résultat : votre réorganisation de migration a abouti.

Merci pour votre retour.

Cordialement,
Apifrog