[SAGE] optimiser les temps d'acces à la base
Fermé
tipierre
Messages postés
11
Date d'inscription
lundi 15 mai 2006
Statut
Membre
Dernière intervention
5 juin 2006
-
22 mai 2006 à 16:28
ppa Messages postés 254 Date d'inscription samedi 3 juillet 2004 Statut Contributeur Dernière intervention 23 août 2011 - 20 avril 2008 à 19:00
ppa Messages postés 254 Date d'inscription samedi 3 juillet 2004 Statut Contributeur Dernière intervention 23 août 2011 - 20 avril 2008 à 19:00
A voir également:
- Type de base non trouvé sage
- Formules excel de base - Guide
- Trouver un numéro de portable avec un nom ✓ - Forum Mobile
- Ou se trouve la corbeille de whatsapp - Guide
- Indiquez l'unité pour la taille de ces fichiers. type document texte brut taille 8,1 ?? première réponse à trouver longueur 8085 caractères type image jpeg taille 3,0 ?? deuxième réponse à trouver dimension 3776 × 2124 px type vidéo mpeg-4 taille 1,1 ?? troisième réponse à trouver durée 02:01:15 - Forum Google Chrome
- La base de données de sécurité du serveur n'a pas de compte d'ordinateur pour la relation ✓ - Forum Réseau
3 réponses
je souhaiterai avoir des info sur sage et comment on peut exporter une base de données sage vers access 2003
ppa
Messages postés
254
Date d'inscription
samedi 3 juillet 2004
Statut
Contributeur
Dernière intervention
23 août 2011
65
23 mai 2006 à 09:41
23 mai 2006 à 09:41
Slt Tipierre,
Le temps d'accès aux bases de données de Sage via ODBC de Sage est effectivement excessivement long sur les bases propriétaire (cBase).
L'explication en est simple mais malheureusement, incontournable. Le driver ODBC de Sage n'est pas seulement un driver ODBC. Ce driver est aussi bourré de procédures internes de validation et de complément de requète.
Par exemple, lors de la création d'un tiers "client" ;) tu auras indiqué le N° du tiers + l'intitulé du tiers + le compte général collectif + le type du tiers. Ta requète INSERT via ODBC sera retraitée pour s'assurer que le compte général collectif existe , que le type du tiers est cohérent avec le type du collectif, mettra à jour la date de création, etc...
Pour une requète UPDATE, par défaut, nous les programmeurs, nous faisons la mise à jour que des zones à modifier. ODBC de Sage se chargera à notre place de monter en mémoire la totalité des zones de l'enregistrement que nous souhaitons mettre à jour, modifiera le contenu de ces zones et ré-enregistrera la totalité des zones de l'enregistrement (ce que nous serions sensé faire nous même). Le driver en profitera pour contrôler la cohérence des infos modifiées.
Pour une requète DELETE, le driver ODBC assure le contrôle d'intégrité des données, vérifiant par exemple que tu ne cherche pas à supprimer un tiers pour lequel il existe des écritures comptables ou des documents dans la gescom.
Voila pourquoi le driver ODBC est effectivement épouventablement lent. Il n'y a que sous Sage SQL que nous pouvons gagner du temps de traitement, pour tout et autant que nous nous conformions aux règles de contrôle et actualisation des enregistrements.
Phil
Le temps d'accès aux bases de données de Sage via ODBC de Sage est effectivement excessivement long sur les bases propriétaire (cBase).
L'explication en est simple mais malheureusement, incontournable. Le driver ODBC de Sage n'est pas seulement un driver ODBC. Ce driver est aussi bourré de procédures internes de validation et de complément de requète.
Par exemple, lors de la création d'un tiers "client" ;) tu auras indiqué le N° du tiers + l'intitulé du tiers + le compte général collectif + le type du tiers. Ta requète INSERT via ODBC sera retraitée pour s'assurer que le compte général collectif existe , que le type du tiers est cohérent avec le type du collectif, mettra à jour la date de création, etc...
Pour une requète UPDATE, par défaut, nous les programmeurs, nous faisons la mise à jour que des zones à modifier. ODBC de Sage se chargera à notre place de monter en mémoire la totalité des zones de l'enregistrement que nous souhaitons mettre à jour, modifiera le contenu de ces zones et ré-enregistrera la totalité des zones de l'enregistrement (ce que nous serions sensé faire nous même). Le driver en profitera pour contrôler la cohérence des infos modifiées.
Pour une requète DELETE, le driver ODBC assure le contrôle d'intégrité des données, vérifiant par exemple que tu ne cherche pas à supprimer un tiers pour lequel il existe des écritures comptables ou des documents dans la gescom.
Voila pourquoi le driver ODBC est effectivement épouventablement lent. Il n'y a que sous Sage SQL que nous pouvons gagner du temps de traitement, pour tout et autant que nous nous conformions aux règles de contrôle et actualisation des enregistrements.
Phil
tipierre
Messages postés
11
Date d'inscription
lundi 15 mai 2006
Statut
Membre
Dernière intervention
5 juin 2006
23 mai 2006 à 10:43
23 mai 2006 à 10:43
tu peux me donner la porcedure pour transformer un bon de commande en bon de livraison, je patauge dans les tables à impacter et les champs obligatoires.
si j'ai bien compris il faut supprimer le bon de commande dans la table f_docentete et f_docligne et ensuite recréer en bon de livraison. ( dans le cas ou je livre la totalité de ma commande)
si j'ai bien compris il faut supprimer le bon de commande dans la table f_docentete et f_docligne et ensuite recréer en bon de livraison. ( dans le cas ou je livre la totalité de ma commande)
ppa
Messages postés
254
Date d'inscription
samedi 3 juillet 2004
Statut
Contributeur
Dernière intervention
23 août 2011
65
>
tipierre
Messages postés
11
Date d'inscription
lundi 15 mai 2006
Statut
Membre
Dernière intervention
5 juin 2006
23 mai 2006 à 17:56
23 mai 2006 à 17:56
Slt Tipierre,
Un document de gescom est effectivement décrit dans les tables F_DOCENTETE et F_DOCLIGNE.
La vie de ce document ne fait que se modifier au cours des étapes en question.
Il convient donc de modifier le :
-> F_DOCENTETE.DO_Type de 1 vers 3
-> F_DOCLIGNE.DO_Type de chaque ligne,
ATTENTION, ce n'est valable que dans le cas d'une transformation complète. Si elle n'est que partielle, il faut dupliquer de DOCENTETE en changeant le type et le DO_PIECE, et dupliquer les lignes non complètement servies en les rattachant à la bonne entête.
Phil
Un document de gescom est effectivement décrit dans les tables F_DOCENTETE et F_DOCLIGNE.
La vie de ce document ne fait que se modifier au cours des étapes en question.
Il convient donc de modifier le :
-> F_DOCENTETE.DO_Type de 1 vers 3
-> F_DOCLIGNE.DO_Type de chaque ligne,
ATTENTION, ce n'est valable que dans le cas d'une transformation complète. Si elle n'est que partielle, il faut dupliquer de DOCENTETE en changeant le type et le DO_PIECE, et dupliquer les lignes non complètement servies en les rattachant à la bonne entête.
Phil
tipierre
Messages postés
11
Date d'inscription
lundi 15 mai 2006
Statut
Membre
Dernière intervention
5 juin 2006
23 mai 2006 à 18:02
23 mai 2006 à 18:02
si j'ai bien compris pour de changer un bon de commande en bon de livraison il suffit de changer le type et le Driver ODBC crée autmatiquement le bon de livraison ?
tu peux me donner la requete stp parce ke là je patauge grave...
J'ai pas encore bien saisi les automatisme de SAGE :(:(
tu peux me donner la requete stp parce ke là je patauge grave...
J'ai pas encore bien saisi les automatisme de SAGE :(:(
20 avril 2008 à 19:00
La base de donnée Sage peut se présenter sous plusieurs types de SGBD :
* base propiétaire (Cbase)
* base MsSQL
* base Sage SQL (ORACLE)
Dans le cas du Cbase, le seul moyen d'accéder à la structure de chaque table est d'utiliser les driver ODBC de Sage. Dans les autres cas, le driver ODBC de MsSQL ou d'Oracle (8i) permet de visualiser les tables. Une fois la base ouverte et les tables visibles, il reste à écrire les procédures de copie de table de la base Sage à Access, et là, c'est des requêtes ou des scripts SQL.
S'il n'est pas indispensable de récupérer l'intégralité des champs de chaque table, il reste la méthade "mano" en exportant sous excel (slk) les fichiers et en les ouvrant dans Access.
La structure des bases sur http://segs.free.fr/Pages/segs-documentation.html
amicalement,
Phil