Grosse lenteur ODBC

Cette section est consacrée aux développements d'applications interfacées avec les logiciels Sage.

Modérateurs: Super-Apogea, Super Modérateur

Grosse lenteur ODBC

de sakhavhyand » Mer 7 Mar 2018 17:31

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.
Dernière édition par sakhavhyand le Ven 9 Mar 2018 11:24, édité 1 fois.
Posteur néophyte
Posteur néophyte
 
Messages: 18
Inscription: Jeu 1 Mar 2018 19:44

Re: Grosse lenteur ODBC

de asr31 » Mer 7 Mar 2018 19:39

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,
ASR31

En recherche de missions.
Avatar de l’utilisateur
Super Contributeur
Super Contributeur
 
Messages: 2975
Inscription: Mer 13 Fév 2008 15:31
Localisation: TOULOUSE

Re: Grosse lenteur ODBC

de sakhavhyand » Mer 7 Mar 2018 19:47

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).
Posteur néophyte
Posteur néophyte
 
Messages: 18
Inscription: Jeu 1 Mar 2018 19:44

Re: Grosse lenteur ODBC

de IMPERIAL » Jeu 8 Mar 2018 09:58

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
IMPERIAL
Consultant Ligne 100 - INFOROPE
Le savoir c'est comme l'Amour. Si tu ne le partage pas, il devient inutile.

IMPERIAL
Avatar de l’utilisateur
Super Contributeur
Super Contributeur
 
Messages: 4661
Inscription: Jeu 6 Aoû 2009 12:39
Localisation: ROSNY SOUS BOIS

Re: Grosse lenteur ODBC

de sakhavhyand » Jeu 8 Mar 2018 10:12

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.
Posteur néophyte
Posteur néophyte
 
Messages: 18
Inscription: Jeu 1 Mar 2018 19:44

Re: Grosse lenteur ODBC

de sakhavhyand » Jeu 8 Mar 2018 10:48

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 !
Posteur néophyte
Posteur néophyte
 
Messages: 18
Inscription: Jeu 1 Mar 2018 19:44

Re: Grosse lenteur ODBC

de sakhavhyand » Jeu 8 Mar 2018 11:16

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 ?
Posteur néophyte
Posteur néophyte
 
Messages: 18
Inscription: Jeu 1 Mar 2018 19:44

Re: Grosse lenteur ODBC

de sakhavhyand » Jeu 8 Mar 2018 16:25

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 ?
Posteur néophyte
Posteur néophyte
 
Messages: 18
Inscription: Jeu 1 Mar 2018 19:44

Re: Grosse lenteur ODBC

de asr31 » Jeu 8 Mar 2018 19:49

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.
ASR31

En recherche de missions.
Avatar de l’utilisateur
Super Contributeur
Super Contributeur
 
Messages: 2975
Inscription: Mer 13 Fév 2008 15:31
Localisation: TOULOUSE

Re: Grosse lenteur ODBC

de sakhavhyand » Ven 9 Mar 2018 11:24

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 !
Posteur néophyte
Posteur néophyte
 
Messages: 18
Inscription: Jeu 1 Mar 2018 19:44


Qui est en ligne
Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 0 invités