Le Forum des Utilisateurs Sage

Salut à tous,

je suis en train de développer un accès aux bases SAGE (v16 proprio) via un Intranet en asp.net.
Pour mes requêtes, je passe par le drivers ODBC installé sur le serveur web.
La source ODBC marche très bien si je me connecte avec Excel, avec un logiciel de requête (WinSQL par exemple) ou par du code C# dans une application Windows classique.

Par contre lorsque mes pages asp tentent une requête via la même source ODBC, je me ramasse systématiquement les message d'erreur suivant :

ERROR [42000] [Simba][SimbaEngine ODBC Driver][DRM File Library]File access denied.
ERROR [IM006] [Microsoft][Gestionnaire de pilotes ODBC] Échec SQLSetConnectAttr du pilote
ERROR [01000] [Microsoft][Gestionnaire de pilotes ODBC] Le pilote ne gère pas la version du comportement ODBC demandé par l'application (voir SQLSetEnvAttr).

Par contre, les mêmes requêtes, dirigées vers un sqlserveur ayant la base SAGE en serveur lié via la même source ODBC, marchent mais sont très longues. Déjà que le drivers ODBc est très lent, là on rajoute une couche qui fait que mes pages mettent souvent plus de 2 min pour se chargées et j'ai régulièrement des erreur de Timeout.

Que faut-il faire pour résoudre les connexions directe via l'odbc. Je pense que c'est un problème de compte utilisateur utilisé par le service web, mais j'avoue que je ne sais plus ou chercher.

est tu certain que ta base est en multi utilisateur ?
Menu "fichier \ configuration système et partage"

Ouppsss, j'ai oublier de répondre.

Le problème est résolu.

Ce n'était pas un problème de multi-utilisateurs ou de login.

Le problème vient de IIS qui a, semble-t-il du mal à passer l'authentification aux sources (ou à certaines) ODBC.
La solution consiste (j'explique comme j'ai compris, pas sur que les termes soient bon) à indiquer à IIS de ne pas s'occuper le l'authentification et d'être totalement transparent sur ce point. Pour cela il faut rajouter la ligne <identity impersonate="true" /> dans la partie <system.web> du web.config du site.


PS : Le problème de lenteur, lui, n'est pas résolu.

l'ODBC Sage peut être très long et donc il faut optimiser à mort les requêtes et encore parfois ça suffit pas !

As-tu un exemple à donner d'une requête qui est longue et et combien ya d'élément retourné par celle-ci ?

Oui, l'odbc Sage est lent, mais d'autant plus à travers IIS. Entre l'interrogation de la requête par la page asp et l'interrogation directe de la même par l'analyseur de requête de SQLServeur, IIS doit multiplier le temps par 2 ou 3, je pense. (Il n'est pas impossible qu'il y ait aussi un problème de surcharge du serveur)

Certaines requêtes sont directes via l'odbc car elles ne renvoie que des données Sage, d'autres sont faite à travers l'odbc monté en serveur lié sur un SQLServer car j'ai des jointures sur des tables SQL.

Certaines requêtes, notamment sur les articles achetés peuvent renvoyées plus de 10000 lignes.

Quand je fais les requêtes manuellement par le code, j'essaye d'optimiser,mais lorsque je passe par un dataset c'est moins évident, surtout que le driver n'accepte pas les requêtes paramétrées. Je suis donc obligé de rapatrier un grand volume de données de Sage dans une table virtuelle (faite avec OPENQUERY) pour appliquer les filtres et paramètres au niveau de la requête sur cette table virtuelle.


Tout ça à cause de la génialisme idée de la direction de passer une partie de l'application de gestion de fabrication développée en interne, il y a bien longtemps, sous Access et SQLserver sous Sage pour la partie Achat et nomenclature, le reste restant sous SQLServeur.

Je comprend plus, tu es en version proprio donc obligation de passer par l'ODBC ou version SQL serveur ?

Version proprio pour SAGE, couplé à une ancienne gestion de fabrication qui, elle, est sous SQLServer2000

La partie Achat et Nomenclature de la gestion de fabrication a été transféré dans Sage, mais le reste est resté sous sqlserver, c'est pour ça que je suis obligé de connecter les 2 bases.

Pour le moment, il n'est pas question de passer Sage en slqserver, les coût sont trop élevés. Mais bon quand ils verront la base Sage implosée, ils comprendront.

J'ai bataillé 3 mois pour réussir à avoir une licence ODBC, 1 pas 2. D'où l'intranet pour que tout le monde puisse accéder malgré la seule licence.
La gescom/compta, c'est une licence 4 postes pour 7 personnes qui l'utilisent courrament.....

ok, comprend mieux

J'vais surement de casser le moral mais ne compare jamais une requête que tu lances sur ODBC sur une base SQL serveur, ya de quoi pleurer !
C'est tout simplement le driver qui est lent !
j'ai déjà vu des requêtes se faire en quelques secondes sous SQL serveur et quelques minutes sous ODBC !

j'ai même vu parfois, prendre plusieurs table entière en mémoire, faire mes propres filtres par le code, et c'était bien plus rapide que la requête en ODBC !!!

Après si tu n'as pas besoin d'avoir des données en temps réel, c'est de copier les tables dont tu as besoins dans une base SQL et de tout travailler sur du SQL. Du coup vitesse garantie !

Malheureusement, non j'ai besoin du temps réel.

Je sais que le driver est lent, il est codé avec les pieds. Je pense même qu'il ne respecte pas complètements tous les standards car il n'est pas utilisable avec n'importe quel logiciel.
SAGE n'investie pas dans son driver, se contente juste de le rendre compatible avec ses versions L100. Malheureusement c'est la seule possibilité de brancher la L100 avec l'extérieur.

C'est quand plus simple avec la L1000 même si le logiciel est plus complexe.

100% d'accord

Pour les requêtes juste faire attention dans les filtres à bien cibler les champs qui servent d'index et enlever les critères superflus.
Un critère en plus ralenti parfois considérablement une requête !

j'ai hâte de voir ce que va donner leur objet métier sur ODBC, si c'est aussi performant que le drivers c'est pas gagné !

Justement, beaucoup des filtres sont sur des champs non indexés (ex, ar_sommeil, infos libres, ...)

Bon bé te souhaite juste un bon courage !

je reprends une idée cité plus haut

Selon la version de ton Framework.net et si tu connais un peu link to object.
Tu peux prendre ta table en filtrant que sur des index et pour le reste des critères le faire en code avec link.

Dans un objet de type Datatable et faire un truc du genre :

Code: Tout sélectionner

Dim Resultat = (from Ligne as datarow in Datatable.rows
                        where MonCritère1='MaValeur1'
                        AndAlso MonCritère2='MaValeur2' ).ToList





C'est du gros système D mais j'ai déjà vu gagner pas mal de temps de réponse en faisant comme cela.

Je connais pas linq (pas encore eu le temps de m'y intéresser), mais effectivement faudrait que je m'y intéresse.

Ça va bien quand on doit faire du traitement pas le code sur les données. Moi essentiellement les données sont affichées, soit dans des grilles asp.net (je débute complètement en asp.net) soit dans des rapports Crystal Report.

Mais j'ai peut-être effectivement quelques requêtes qui pourraient passer sous linq

Petit test aujourd'hui avec des tables temporaires
La structure suivante me renvoie environ 5000 lignes en 30 secondes.

Code: Tout sélectionner

EXECUTE sp_executesql N'if exists(select name from tempdb..sysobjects where name like ''#FTARTICLE%'')
                  begin drop table #FTARTICLE END;
                  if exists(select name from tempdb..sysobjects where name like ''#FTNOMENCLAT%'')
                  begin drop table #FTNOMENCLAT END;
                  SELECT * INTO #FTARTICLE FROM OPENQUERY(SAGE100,
                         ''select a.ar_ref,a.ar_design,a.matiere,a.fabricant,a.emplacement,a.stock_fin_annee,a.ar_punet,a.ar_sommeil
                         from f_article a INNER JOIN f_catalogue c ON a.cl_no1=c.cl_no where c.cl_code=''''AC'''''')
                  SELECT * INTO #FTNOMENCLAT FROM OPENQUERY(SAGE100,''select n.ar_ref,n.no_refdet,n.no_qte, a.ar_sommeil
                         from f_nomenclat n inner join f_article a on n.ar_ref=a.ar_ref where a.ar_nomencl=1'');
                  SELECT A.* FROM #FTARTICLE A WHERE A.AR_REF NOT IN (SELECT DISTINCT no_refdet FROM #FTNOMENCLAT)'

La requete équivalente directement sur le drivers ODBC au bout de 8 min n'avait toujours pas rendu la main :

Code: Tout sélectionner

SELECT a.ar_ref, a.ar_design, a.matiere, a.fabricant, a.emplacement, a.stock_fin_annee, a.ar_punet, a.ar_sommeil FROM F_ARTICLE a INNER JOIN f_catalogue c ON a.cl_no1=c.cl_no where c.cl_code='AC' and A.AR_REF NOT IN (SELECT DISTINCT no_refdet FROM F_NOMENCLAT)