Le Forum des Utilisateurs Sage

Bonjour, je vous consulte suite à de grosse lenteur sur les connexion ODBC depuis 2 mois presque maintenant.

La situation initiale :
Sage 100 i7 17.71 (Gescom/Compta/Immo/Tréso)
Windows Server 2012 R2 avec SQL Serveur Standard 10.0.5500.0

Actuellement deux logiciel communique sur cette base via ODBC, aucun problème jusqu'a ce que les écritures se mettent à prendre beaucoup de temps.
Une mise en place d'EDI à commencé, aucun souci sur de la lecture de document, lenteur énorme sur l'insertion de BC rendant l'EDI inutilisable.
Pour un ordre d'idée la requête suivante :

update f_docentete set do_coord01='test' where do_piece='xxxxxxx'

Exécuter via msquery et l'ODBC prenait 3min30 !!

Suite à cela la base à été passé dans Supporia (Gescom/Compta et Immo), après deux semaines de combats plus d'erreur sur la base.
Un archivage à également été fait (année fiscale de 94 à 2012, n'avait jamais été fait) grâce à l'aide de IMPERIAL (merci encore).
Passage dans maintenance, recalcul des Index (fait toutes les nuits avec CB_Maintenance), recalcul des CMUP, vérification des liens, etc ...

Sur la requête basique d'update, je suis descendu à 2 minutes, ce qui est encore trop long n'est-ce pas ?

Pour info, une recopie de la base est en cours ( faite en dernier car j'avais des erreurs non détecté par la maintenance ou Supporia).

Des idées de où cela pourrait venir ? Le serveur n'est clairement pas sollicité à son maximum (RAM/CPU), des test on été fait sur un autre serveur fraichement installé (SQL/SAGE) avec restauration d'une copie de la base et j'ai exactement le même problème.

Bonjour,
;
Il faut peut-être optimiser les requêtes pour utiliser un maximum les indexes.

Dans la clause WHERE, je rajouterai DO_Domaine=0 (si ventes) AND DO_Type=1 (si commande).

Quand tu dis ODBC, tu parles de l'ODBC Sage, on est d'accord ?

Attention aussi à bien gérer la connexion à la base de données.
S'il y a connexion + requête + déconnexion, en effet, ça va être long : essayer d'ouvrir la connexion pour faire un lot d'instructions puis fermer ensuite.
Mais c'est peut-être déjà ce que tu fais...

Cordialement,

Bonsoir, j'avais d'abord fait le test avec DO_Domaine et DO_Type, même résultats.
Je vais réessayer dans le doute sur la dernière version de ma base.

On parle bien de l'ODBC SAGE, pardon j'ai oublié de préciser.

Pour la partie EDI je n'ai malheureusement pas la main dessus (j'ai pu zieuté un peu leur code quand même, c'est mon serveur mwahahaha) et cela m'a l'air propre.

Petite précision, sur l'exécution de ma requête 'test' (l'update) un profilage SQL me retourne environ 188 000 requêtes (dans la première version de la base, pour les autres j'ai juste regarder le temps d’exécution).

Bonjour

Pour savoir si ça vient de ton dev ou de SQL, essaie de faire un Update directement dans SSMS et regarde combien de temps mets ton update.

Essaie sur la base bijou pour voir si c'est aussi long ...

Cdlt

Bonjour IMPERIAL, via SSMS, cela est instantanée.
Même sans précisé le domaine et type du document dans l'update.

Via MSQUERY/ODBC, sans préciser le domaine et le type 2 min, en les précisant c'est instantanée.
Je suis en train de faire les test avec le programme de l'EDI pour voir si j'ai des améliorations sur la base recopier.

Bon, l'EDI est toujours beaucoup trop long.

Avec un profilage voila ce qu'il se passe pendant que l'EDI est censé insérer le document :

Code: Tout sélectionner

SELECT TOP 1 * FROM F_LOTSERIE ORDER BY DL_NoOut DESC,  cbMarq DESC
SELECT TOP 1 * FROM F_LOTSERIE ORDER BY DL_NoOut DESC,  cbMarq DESC
exec sp_executesql N'SELECT [commentaire],[PRIS_SUR_STAND],[POIDS_COLIS],[TYPE_COLIS],[PREPAREE],[alert],[Alert_Articles_lié_Belgique],[Alerte_articles_lié_Suisse] FROM F_DOCLIGNE WHERE cbMarq = @P1',N'@P1 int',423073
exec CB_EqGreaterILS_NOOUT 1178573

Et cela en boucle avec juste du paramètre qui change.

Sachant que la table F_LOTSERIE ne contient que 2 lignes !

Je viens de faire quelques recherches, les deux lignes concernent donc un Article en sommeil en suivi de stock par lot (le seul de la base).
Sauf que je ne retrouve pas les valeurs des champs DL_NoIn et DL_NoOut dans la table F_LOTFIFO.

Le problème pourrait venir de la ? Puis-je supprimer les deux lignes de la table F_LOTSERIE sans risque ?
Ais-je oublié de vérifié un lien potentiel avec une autre table ?

Bon après plusieurs test fait avec un technicien de l'EDI, j'ai recentré mon problème.

En fait, il s’avère que à l'insertion d'article, l'ODBC va s'obstiner à chercher un numéro de Série/Lots alors que les articles sont en CMUP. Sur certain article je n'ai pas le soucis, l'ODBC ne génère aucun requête sur la table F_LOTSERIE et l'intégration se fait relativement rapidement.
En revanche certains article génère une grosse quantité de select sur cette table.

La gestion des n°Lots/Série peut-elle être forcé par un réglage utilisateurs que quelqu'un aurait tripoté sans nous le dire ?

Bonjour,

Il te faut voir avec ton prestataire EDI pourquoi un article en CMUP peut être considéré comme en lot/série.
Il y a peut-être une synchro article entre la Gescom et l'EDI (l'EDI gardant en cache les caractéristiques article).

Là, de mon coté, je n'ai pas assez de billes pour résoudre le problème...

Bon courage.

Bonjour, j'ai trouvé la solution hier soir et validé ce matin avec le prestataire EDI.

J'ai fouillé un peu dans leur code (PHP 4, sniff ...) et j'ai remarqué qu'il chercher le dernier numéro de BC sur la mauvaise souche.
Une qui ne contient aucun numéro de BC, chose qu'ils ne vérifié pas.
Tout partait en cacahuète à partir de ce moment la.

Je pense que je peut encore améliorer d'autre requête de leur coté, leur étape de vérification prend beaucoup trop de temps par rapport au temps d’exécution de leur requête.

Je clôture donc ce ticket ; et j’espère également clôturé 3 semaines à manger de la base SAGE tout les jours !