Bonjour,
je ch un peu d'info sur les possibilité d'interface avec Sage V14 ligne 100
MS SQL Server.
Dans un premier temps pour faire une offre, puis ensuite surement besoin
d'une resource.
Merci d'avance
Bonsoir, en fait je souhaite : composer une commande, consulter les stocks, mettre les stocks à jour, etc...
y a t il (je reve..) une API, des web services, des procèdures stockées....
le but : réaliser pour des grossiste un B2B en qq sorte.
"Eric" <ericb33+ a écrit dans le message de news: fthv9tndt818$
Le 12 février 2007 à 18:26, dans <news:45d0a329$0$5090$, Dominique Lecocq nous disait :
je ch un peu d'info sur les possibilité d'interface avec Sage V14 ligne 100 MS SQL Server.
Quel type d'infos ?
-- Eric
Eric
Le 12 février 2007 à 19:43, dans <news:45d0b53f$0$27408$, Dominique Lecocq nous disait :
en fait je souhaite : composer une commande, consulter les stocks, mettre les stocks à jour, etc...
y a t il (je reve..) une API, des web services, des procèdures stockées....
Rien de tout ça. On peut attaquer la base SQL en OLEDB ou ODBC et j'ai tendance à utiliser les 2 méthodes selon ce que j'ai à faire.
Dans les lectures et certaines écritures simples, il vaut mieux privilégier OLEDB pour des raisons de rapidité.
En ce qui concerne les écritures complexes telles que les documents de vente, ODBC est plus adapté car de nombreuses tables peuvent être impliquées et le driver se charge de les mettre à jour automatiquement. De plus, le driver permet d'utiliser des fonctions retournant des valeurs qu'il serait compliqué de calculer autrement. Par exemple, on peut obtenir le total TTC d'une facture en appelant une fonction, alors qu'en OLEDB il faut lancer plusieurs requêtes pour obtenir le même résultat. Revers de la médaille, ODBC est assez poussif.
-- Eric
Le 12 février 2007 à 19:43, dans
<news:45d0b53f$0$27408$ba4acef3@news.orange.fr>, Dominique Lecocq nous
disait :
en fait je souhaite :
composer une commande,
consulter les stocks,
mettre les stocks à jour,
etc...
y a t il (je reve..) une API, des web services, des procèdures stockées....
Rien de tout ça.
On peut attaquer la base SQL en OLEDB ou ODBC et j'ai tendance à
utiliser les 2 méthodes selon ce que j'ai à faire.
Dans les lectures et certaines écritures simples, il vaut mieux
privilégier OLEDB pour des raisons de rapidité.
En ce qui concerne les écritures complexes telles que les documents de
vente, ODBC est plus adapté car de nombreuses tables peuvent être
impliquées et le driver se charge de les mettre à jour automatiquement.
De plus, le driver permet d'utiliser des fonctions retournant des
valeurs qu'il serait compliqué de calculer autrement. Par exemple, on
peut obtenir le total TTC d'une facture en appelant une fonction, alors
qu'en OLEDB il faut lancer plusieurs requêtes pour obtenir le même
résultat. Revers de la médaille, ODBC est assez poussif.
Le 12 février 2007 à 19:43, dans <news:45d0b53f$0$27408$, Dominique Lecocq nous disait :
en fait je souhaite : composer une commande, consulter les stocks, mettre les stocks à jour, etc...
y a t il (je reve..) une API, des web services, des procèdures stockées....
Rien de tout ça. On peut attaquer la base SQL en OLEDB ou ODBC et j'ai tendance à utiliser les 2 méthodes selon ce que j'ai à faire.
Dans les lectures et certaines écritures simples, il vaut mieux privilégier OLEDB pour des raisons de rapidité.
En ce qui concerne les écritures complexes telles que les documents de vente, ODBC est plus adapté car de nombreuses tables peuvent être impliquées et le driver se charge de les mettre à jour automatiquement. De plus, le driver permet d'utiliser des fonctions retournant des valeurs qu'il serait compliqué de calculer autrement. Par exemple, on peut obtenir le total TTC d'une facture en appelant une fonction, alors qu'en OLEDB il faut lancer plusieurs requêtes pour obtenir le même résultat. Revers de la médaille, ODBC est assez poussif.
-- Eric
Dominique Lecocq
> En ce qui concerne les écritures complexes telles que les documents de vente, ODBC est plus adapté car de nombreuses tables peuvent être impliquées et le driver se charge de les mettre à jour automatiquement.
Je ne comprend pas? le drivers ODBC est un driver "spécial" fournit pas Sage? Peux tu me donner un exemple? je comprend parfaitement que plusieurs tables puissent être impliqués mais commente le driver "le sait"?
De plus, le driver permet d'utiliser des fonctions retournant des valeurs qu'il serait compliqué de calculer autrement. Par exemple, on peut obtenir le total TTC d'une facture en appelant une fonction, alors qu'en OLEDB il faut lancer plusieurs requêtes pour obtenir le même résultat. Revers de la médaille, ODBC est assez poussif.
je travaille en dotnet c# et 1 seul module à maintenir en WD...
j'ai la comprenette un peu difficile je veux bien un exemple de mise à jour de table en "cascade" par exemple.
D'avance Merci
Dominique "QNX" Lecocq
PS : Où trouver la structure de la base L100 MS SQL (sur le serveur...je sais) y a t il une doc d'interface, c'est la partie Gesco qui m'interesse.
> En ce qui concerne les écritures complexes telles que les documents de
vente, ODBC est plus adapté car de nombreuses tables peuvent être
impliquées et le driver se charge de les mettre à jour automatiquement.
Je ne comprend pas? le drivers ODBC est un driver "spécial" fournit pas
Sage?
Peux tu me donner un exemple? je comprend parfaitement que plusieurs tables
puissent être impliqués mais commente le driver "le sait"?
De plus, le driver permet d'utiliser des fonctions retournant des
valeurs qu'il serait compliqué de calculer autrement. Par exemple, on
peut obtenir le total TTC d'une facture en appelant une fonction, alors
qu'en OLEDB il faut lancer plusieurs requêtes pour obtenir le même
résultat. Revers de la médaille, ODBC est assez poussif.
je travaille en dotnet c# et 1 seul module à maintenir en WD...
j'ai la comprenette un peu difficile je veux bien un exemple de mise à jour
de table en "cascade" par exemple.
D'avance Merci
Dominique "QNX" Lecocq
PS : Où trouver la structure de la base L100 MS SQL (sur le serveur...je
sais) y a t il une doc d'interface, c'est la partie Gesco qui m'interesse.
> En ce qui concerne les écritures complexes telles que les documents de vente, ODBC est plus adapté car de nombreuses tables peuvent être impliquées et le driver se charge de les mettre à jour automatiquement.
Je ne comprend pas? le drivers ODBC est un driver "spécial" fournit pas Sage? Peux tu me donner un exemple? je comprend parfaitement que plusieurs tables puissent être impliqués mais commente le driver "le sait"?
De plus, le driver permet d'utiliser des fonctions retournant des valeurs qu'il serait compliqué de calculer autrement. Par exemple, on peut obtenir le total TTC d'une facture en appelant une fonction, alors qu'en OLEDB il faut lancer plusieurs requêtes pour obtenir le même résultat. Revers de la médaille, ODBC est assez poussif.
je travaille en dotnet c# et 1 seul module à maintenir en WD...
j'ai la comprenette un peu difficile je veux bien un exemple de mise à jour de table en "cascade" par exemple.
D'avance Merci
Dominique "QNX" Lecocq
PS : Où trouver la structure de la base L100 MS SQL (sur le serveur...je sais) y a t il une doc d'interface, c'est la partie Gesco qui m'interesse.
PERCAPITA
Bonjour,
Oui l'ODBC SAGE est fournie par SAGE (payant). En fait je pense que c'est le même que pour version en base propriétaire (.mae) SAGE préconise ailleurs de passer par lui. Il y a une autre possibilité c'est de passé par un nouveau truc que vend SAGE les objets métiers. Il s'agit d'une bibliothèque de classe permettant d'attaquer la base SAGE L100 SQL. Attention le prix est dissuasif.
Bon courage.
"Dominique Lecocq" a écrit dans le message de news: 45d0be30$0$5077$
En ce qui concerne les écritures complexes telles que les documents de vente, ODBC est plus adapté car de nombreuses tables peuvent être impliquées et le driver se charge de les mettre à jour automatiquement.
Je ne comprend pas? le drivers ODBC est un driver "spécial" fournit pas Sage? Peux tu me donner un exemple? je comprend parfaitement que plusieurs tables puissent être impliqués mais commente le driver "le sait"?
De plus, le driver permet d'utiliser des fonctions retournant des valeurs qu'il serait compliqué de calculer autrement. Par exemple, on peut obtenir le total TTC d'une facture en appelant une fonction, alors qu'en OLEDB il faut lancer plusieurs requêtes pour obtenir le même résultat. Revers de la médaille, ODBC est assez poussif.
je travaille en dotnet c# et 1 seul module à maintenir en WD...
j'ai la comprenette un peu difficile je veux bien un exemple de mise à jour de table en "cascade" par exemple.
D'avance Merci
Dominique "QNX" Lecocq
PS : Où trouver la structure de la base L100 MS SQL (sur le serveur...je sais) y a t il une doc d'interface, c'est la partie Gesco qui m'interesse.
Bonjour,
Oui l'ODBC SAGE est fournie par SAGE (payant). En fait je pense que c'est le
même que pour version en base propriétaire (.mae) SAGE préconise ailleurs de
passer par lui. Il y a une autre possibilité c'est de passé par un nouveau
truc que vend SAGE les objets métiers. Il s'agit d'une bibliothèque de
classe permettant d'attaquer la base SAGE L100 SQL. Attention le prix est
dissuasif.
Bon courage.
"Dominique Lecocq" <lecocq.dominique@wanadoo.frNOSPAM> a écrit dans le
message de news: 45d0be30$0$5077$ba4acef3@news.orange.fr...
En ce qui concerne les écritures complexes telles que les documents de
vente, ODBC est plus adapté car de nombreuses tables peuvent être
impliquées et le driver se charge de les mettre à jour automatiquement.
Je ne comprend pas? le drivers ODBC est un driver "spécial" fournit pas
Sage?
Peux tu me donner un exemple? je comprend parfaitement que plusieurs
tables puissent être impliqués mais commente le driver "le sait"?
De plus, le driver permet d'utiliser des fonctions retournant des
valeurs qu'il serait compliqué de calculer autrement. Par exemple, on
peut obtenir le total TTC d'une facture en appelant une fonction, alors
qu'en OLEDB il faut lancer plusieurs requêtes pour obtenir le même
résultat. Revers de la médaille, ODBC est assez poussif.
je travaille en dotnet c# et 1 seul module à maintenir en WD...
j'ai la comprenette un peu difficile je veux bien un exemple de mise à
jour de table en "cascade" par exemple.
D'avance Merci
Dominique "QNX" Lecocq
PS : Où trouver la structure de la base L100 MS SQL (sur le serveur...je
sais) y a t il une doc d'interface, c'est la partie Gesco qui m'interesse.
Oui l'ODBC SAGE est fournie par SAGE (payant). En fait je pense que c'est le même que pour version en base propriétaire (.mae) SAGE préconise ailleurs de passer par lui. Il y a une autre possibilité c'est de passé par un nouveau truc que vend SAGE les objets métiers. Il s'agit d'une bibliothèque de classe permettant d'attaquer la base SAGE L100 SQL. Attention le prix est dissuasif.
Bon courage.
"Dominique Lecocq" a écrit dans le message de news: 45d0be30$0$5077$
En ce qui concerne les écritures complexes telles que les documents de vente, ODBC est plus adapté car de nombreuses tables peuvent être impliquées et le driver se charge de les mettre à jour automatiquement.
Je ne comprend pas? le drivers ODBC est un driver "spécial" fournit pas Sage? Peux tu me donner un exemple? je comprend parfaitement que plusieurs tables puissent être impliqués mais commente le driver "le sait"?
De plus, le driver permet d'utiliser des fonctions retournant des valeurs qu'il serait compliqué de calculer autrement. Par exemple, on peut obtenir le total TTC d'une facture en appelant une fonction, alors qu'en OLEDB il faut lancer plusieurs requêtes pour obtenir le même résultat. Revers de la médaille, ODBC est assez poussif.
je travaille en dotnet c# et 1 seul module à maintenir en WD...
j'ai la comprenette un peu difficile je veux bien un exemple de mise à jour de table en "cascade" par exemple.
D'avance Merci
Dominique "QNX" Lecocq
PS : Où trouver la structure de la base L100 MS SQL (sur le serveur...je sais) y a t il une doc d'interface, c'est la partie Gesco qui m'interesse.
Eric
Le 12 février 2007 à 20:21, dans <news:45d0be30$0$5077$, Dominique Lecocq nous disait :
En ce qui concerne les écritures complexes telles que les documents de vente, ODBC est plus adapté car de nombreuses tables peuvent être impliquées et le driver se charge de les mettre à jour automatiquement.
Je ne comprend pas? le drivers ODBC est un driver "spécial" fournit pas Sage?
Oui et il est payant, comme le dit PERCAPITA.
Peux tu me donner un exemple? je comprend parfaitement que plusieurs tables puissent être impliqués mais commente le driver "le sait"?
Exemple simple : lorsque tu crées un bon de commande par l'intermédiaire du driver, la table des règlements sera mise automatiquement à jour en fonction du mode de règlement par défaut du client. Si tu passes par OLEDB, tu devras mettre manuellement à jour cette table et ça n'est pas forcément très simple pour des raisons trop longues à expliquer ici. Il en est de même pour la mise à jour des stocks des articles commandés.
De plus, le driver permet d'utiliser des fonctions retournant des valeurs qu'il serait compliqué de calculer autrement. Par exemple, on peut obtenir le total TTC d'une facture en appelant une fonction, alors qu'en OLEDB il faut lancer plusieurs requêtes pour obtenir le même résultat. Revers de la médaille, ODBC est assez poussif.
je travaille en dotnet c# et 1 seul module à maintenir en WD...
Euh...
j'ai la comprenette un peu difficile je veux bien un exemple de mise à jour de table en "cascade" par exemple.
L'exemple que je donne plus haut te convient-il ?
PS : Où trouver la structure de la base L100 MS SQL (sur le serveur...je sais) y a t il une doc d'interface, c'est la partie Gesco qui m'interesse.
Je peux t'envoyer le PDF kivabien si tu le souhaites.
-- Eric
Le 12 février 2007 à 20:21, dans
<news:45d0be30$0$5077$ba4acef3@news.orange.fr>, Dominique Lecocq nous
disait :
En ce qui concerne les écritures complexes telles que les documents de
vente, ODBC est plus adapté car de nombreuses tables peuvent être
impliquées et le driver se charge de les mettre à jour automatiquement.
Je ne comprend pas? le drivers ODBC est un driver "spécial" fournit pas
Sage?
Oui et il est payant, comme le dit PERCAPITA.
Peux tu me donner un exemple? je comprend parfaitement que plusieurs tables
puissent être impliqués mais commente le driver "le sait"?
Exemple simple : lorsque tu crées un bon de commande par l'intermédiaire
du driver, la table des règlements sera mise automatiquement à jour en
fonction du mode de règlement par défaut du client.
Si tu passes par OLEDB, tu devras mettre manuellement à jour cette table
et ça n'est pas forcément très simple pour des raisons trop longues à
expliquer ici. Il en est de même pour la mise à jour des stocks des
articles commandés.
De plus, le driver permet d'utiliser des fonctions retournant des
valeurs qu'il serait compliqué de calculer autrement. Par exemple, on
peut obtenir le total TTC d'une facture en appelant une fonction, alors
qu'en OLEDB il faut lancer plusieurs requêtes pour obtenir le même
résultat. Revers de la médaille, ODBC est assez poussif.
je travaille en dotnet c# et 1 seul module à maintenir en WD...
Euh...
j'ai la comprenette un peu difficile je veux bien un exemple de mise à jour
de table en "cascade" par exemple.
L'exemple que je donne plus haut te convient-il ?
PS : Où trouver la structure de la base L100 MS SQL (sur le serveur...je
sais) y a t il une doc d'interface, c'est la partie Gesco qui m'interesse.
Je peux t'envoyer le PDF kivabien si tu le souhaites.
Le 12 février 2007 à 20:21, dans <news:45d0be30$0$5077$, Dominique Lecocq nous disait :
En ce qui concerne les écritures complexes telles que les documents de vente, ODBC est plus adapté car de nombreuses tables peuvent être impliquées et le driver se charge de les mettre à jour automatiquement.
Je ne comprend pas? le drivers ODBC est un driver "spécial" fournit pas Sage?
Oui et il est payant, comme le dit PERCAPITA.
Peux tu me donner un exemple? je comprend parfaitement que plusieurs tables puissent être impliqués mais commente le driver "le sait"?
Exemple simple : lorsque tu crées un bon de commande par l'intermédiaire du driver, la table des règlements sera mise automatiquement à jour en fonction du mode de règlement par défaut du client. Si tu passes par OLEDB, tu devras mettre manuellement à jour cette table et ça n'est pas forcément très simple pour des raisons trop longues à expliquer ici. Il en est de même pour la mise à jour des stocks des articles commandés.
De plus, le driver permet d'utiliser des fonctions retournant des valeurs qu'il serait compliqué de calculer autrement. Par exemple, on peut obtenir le total TTC d'une facture en appelant une fonction, alors qu'en OLEDB il faut lancer plusieurs requêtes pour obtenir le même résultat. Revers de la médaille, ODBC est assez poussif.
je travaille en dotnet c# et 1 seul module à maintenir en WD...
Euh...
j'ai la comprenette un peu difficile je veux bien un exemple de mise à jour de table en "cascade" par exemple.
L'exemple que je donne plus haut te convient-il ?
PS : Où trouver la structure de la base L100 MS SQL (sur le serveur...je sais) y a t il une doc d'interface, c'est la partie Gesco qui m'interesse.
Je peux t'envoyer le PDF kivabien si tu le souhaites.
-- Eric
Dominique Lecocq
Merci à tous pour le PDF je suis preneur : info (arobase) binact.com
L'exemple me convient parfaitement, mais ce que je comprend c'est que le driver ODBC est "intelligent".
Pour le "outils" Sage c'est quoi "dissuasif" quand on parle de prix? une idée?
Encore Merci.
Donc pas de limite en ecriture dans la base de données c'etait un peu ma peur...
Dominique "QNX" Lecocq
"Eric" <ericb33+ a écrit dans le message de news:
Le 12 février 2007 à 20:21, dans <news:45d0be30$0$5077$, Dominique Lecocq nous disait :
En ce qui concerne les écritures complexes telles que les documents de vente, ODBC est plus adapté car de nombreuses tables peuvent être impliquées et le driver se charge de les mettre à jour automatiquement.
Je ne comprend pas? le drivers ODBC est un driver "spécial" fournit pas Sage?
Oui et il est payant, comme le dit PERCAPITA.
Peux tu me donner un exemple? je comprend parfaitement que plusieurs tables puissent être impliqués mais commente le driver "le sait"?
Exemple simple : lorsque tu crées un bon de commande par l'intermédiaire du driver, la table des règlements sera mise automatiquement à jour en fonction du mode de règlement par défaut du client. Si tu passes par OLEDB, tu devras mettre manuellement à jour cette table et ça n'est pas forcément très simple pour des raisons trop longues à expliquer ici. Il en est de même pour la mise à jour des stocks des articles commandés.
De plus, le driver permet d'utiliser des fonctions retournant des valeurs qu'il serait compliqué de calculer autrement. Par exemple, on peut obtenir le total TTC d'une facture en appelant une fonction, alors qu'en OLEDB il faut lancer plusieurs requêtes pour obtenir le même résultat. Revers de la médaille, ODBC est assez poussif.
je travaille en dotnet c# et 1 seul module à maintenir en WD...
Euh...
j'ai la comprenette un peu difficile je veux bien un exemple de mise à jour de table en "cascade" par exemple.
L'exemple que je donne plus haut te convient-il ?
PS : Où trouver la structure de la base L100 MS SQL (sur le serveur...je sais) y a t il une doc d'interface, c'est la partie Gesco qui m'interesse.
Je peux t'envoyer le PDF kivabien si tu le souhaites.
-- Eric
Merci à tous
pour le PDF je suis preneur :
info (arobase) binact.com
L'exemple me convient parfaitement, mais ce que je comprend c'est que le
driver ODBC est "intelligent".
Pour le "outils" Sage c'est quoi "dissuasif" quand on parle de prix? une
idée?
Encore Merci.
Donc pas de limite en ecriture dans la base de données c'etait un peu ma
peur...
Dominique "QNX" Lecocq
"Eric" <ericb33+spam@alussinan.org> a écrit dans le message de news:
1xgnjatly1axb.dlg@ericb33spam.alussinan.org...
Le 12 février 2007 à 20:21, dans
<news:45d0be30$0$5077$ba4acef3@news.orange.fr>, Dominique Lecocq nous
disait :
En ce qui concerne les écritures complexes telles que les documents de
vente, ODBC est plus adapté car de nombreuses tables peuvent être
impliquées et le driver se charge de les mettre à jour automatiquement.
Je ne comprend pas? le drivers ODBC est un driver "spécial" fournit pas
Sage?
Oui et il est payant, comme le dit PERCAPITA.
Peux tu me donner un exemple? je comprend parfaitement que plusieurs
tables
puissent être impliqués mais commente le driver "le sait"?
Exemple simple : lorsque tu crées un bon de commande par l'intermédiaire
du driver, la table des règlements sera mise automatiquement à jour en
fonction du mode de règlement par défaut du client.
Si tu passes par OLEDB, tu devras mettre manuellement à jour cette table
et ça n'est pas forcément très simple pour des raisons trop longues à
expliquer ici. Il en est de même pour la mise à jour des stocks des
articles commandés.
De plus, le driver permet d'utiliser des fonctions retournant des
valeurs qu'il serait compliqué de calculer autrement. Par exemple, on
peut obtenir le total TTC d'une facture en appelant une fonction, alors
qu'en OLEDB il faut lancer plusieurs requêtes pour obtenir le même
résultat. Revers de la médaille, ODBC est assez poussif.
je travaille en dotnet c# et 1 seul module à maintenir en WD...
Euh...
j'ai la comprenette un peu difficile je veux bien un exemple de mise à
jour
de table en "cascade" par exemple.
L'exemple que je donne plus haut te convient-il ?
PS : Où trouver la structure de la base L100 MS SQL (sur le serveur...je
sais) y a t il une doc d'interface, c'est la partie Gesco qui
m'interesse.
Je peux t'envoyer le PDF kivabien si tu le souhaites.
Merci à tous pour le PDF je suis preneur : info (arobase) binact.com
L'exemple me convient parfaitement, mais ce que je comprend c'est que le driver ODBC est "intelligent".
Pour le "outils" Sage c'est quoi "dissuasif" quand on parle de prix? une idée?
Encore Merci.
Donc pas de limite en ecriture dans la base de données c'etait un peu ma peur...
Dominique "QNX" Lecocq
"Eric" <ericb33+ a écrit dans le message de news:
Le 12 février 2007 à 20:21, dans <news:45d0be30$0$5077$, Dominique Lecocq nous disait :
En ce qui concerne les écritures complexes telles que les documents de vente, ODBC est plus adapté car de nombreuses tables peuvent être impliquées et le driver se charge de les mettre à jour automatiquement.
Je ne comprend pas? le drivers ODBC est un driver "spécial" fournit pas Sage?
Oui et il est payant, comme le dit PERCAPITA.
Peux tu me donner un exemple? je comprend parfaitement que plusieurs tables puissent être impliqués mais commente le driver "le sait"?
Exemple simple : lorsque tu crées un bon de commande par l'intermédiaire du driver, la table des règlements sera mise automatiquement à jour en fonction du mode de règlement par défaut du client. Si tu passes par OLEDB, tu devras mettre manuellement à jour cette table et ça n'est pas forcément très simple pour des raisons trop longues à expliquer ici. Il en est de même pour la mise à jour des stocks des articles commandés.
De plus, le driver permet d'utiliser des fonctions retournant des valeurs qu'il serait compliqué de calculer autrement. Par exemple, on peut obtenir le total TTC d'une facture en appelant une fonction, alors qu'en OLEDB il faut lancer plusieurs requêtes pour obtenir le même résultat. Revers de la médaille, ODBC est assez poussif.
je travaille en dotnet c# et 1 seul module à maintenir en WD...
Euh...
j'ai la comprenette un peu difficile je veux bien un exemple de mise à jour de table en "cascade" par exemple.
L'exemple que je donne plus haut te convient-il ?
PS : Où trouver la structure de la base L100 MS SQL (sur le serveur...je sais) y a t il une doc d'interface, c'est la partie Gesco qui m'interesse.
Je peux t'envoyer le PDF kivabien si tu le souhaites.
-- Eric
dragonal42_
C'est vraiement de la MMMMMMM****de l odbc de Sage ... c long et en plus le fonctionnement est aléatoire ... il vaut mieux prendre sont temps et etudier leur base pour l'attaquer directement ... mais c long ... j'ai mis 4 mois à bien comprendre et à développer TOUT ce qui n existe pas sur ce "Super" Logiciel de M..de désolé ... mais j'en ai vraiement baver et en plus personne chez eux ne nos a aidé .....
je vais essayer de trouver mes codes pour vous donner des idées :::!)))
C'est vraiement de la MMMMMMM****de l odbc de Sage ... c long et en
plus le fonctionnement est aléatoire ...
il vaut mieux prendre sont temps et etudier leur base pour l'attaquer
directement ...
mais c long ... j'ai mis 4 mois à bien comprendre et à développer TOUT
ce qui n existe pas sur ce "Super" Logiciel de M..de
désolé ... mais j'en ai vraiement baver et en plus personne chez eux
ne nos a aidé .....
je vais essayer de trouver mes codes pour vous donner des idées :::!)))
C'est vraiement de la MMMMMMM****de l odbc de Sage ... c long et en plus le fonctionnement est aléatoire ... il vaut mieux prendre sont temps et etudier leur base pour l'attaquer directement ... mais c long ... j'ai mis 4 mois à bien comprendre et à développer TOUT ce qui n existe pas sur ce "Super" Logiciel de M..de désolé ... mais j'en ai vraiement baver et en plus personne chez eux ne nos a aidé .....
je vais essayer de trouver mes codes pour vous donner des idées :::!)))
Pierre BOUSQUET
t'excuses pas on comprend ce genre de réactions concernant SAGE. Malheureusement ils vont finir par être leader dans ce domaine...
dragonal42_ a formulé ce mardi :
C'est vraiement de la MMMMMMM****de l odbc de Sage ... c long et en plus le fonctionnement est aléatoire ... il vaut mieux prendre sont temps et etudier leur base pour l'attaquer directement ... mais c long ... j'ai mis 4 mois à bien comprendre et à développer TOUT ce qui n existe pas sur ce "Super" Logiciel de M..de désolé ... mais j'en ai vraiement baver et en plus personne chez eux ne nos a aidé .....
je vais essayer de trouver mes codes pour vous donner des idées :::!)))
-- Pierre BOUSQUET
" Ne me dites pas que ce problème est difficile. S'il n'était pas difficile, ce ne serait pas un problème. "
t'excuses pas on comprend ce genre de réactions concernant SAGE.
Malheureusement ils vont finir par être leader dans ce domaine...
dragonal42_ a formulé ce mardi :
C'est vraiement de la MMMMMMM****de l odbc de Sage ... c long et en
plus le fonctionnement est aléatoire ...
il vaut mieux prendre sont temps et etudier leur base pour l'attaquer
directement ...
mais c long ... j'ai mis 4 mois à bien comprendre et à développer TOUT
ce qui n existe pas sur ce "Super" Logiciel de M..de
désolé ... mais j'en ai vraiement baver et en plus personne chez eux
ne nos a aidé .....
je vais essayer de trouver mes codes pour vous donner des idées :::!)))
--
Pierre BOUSQUET
" Ne me dites pas que ce problème est difficile.
S'il n'était pas difficile, ce ne serait pas un problème. "
t'excuses pas on comprend ce genre de réactions concernant SAGE. Malheureusement ils vont finir par être leader dans ce domaine...
dragonal42_ a formulé ce mardi :
C'est vraiement de la MMMMMMM****de l odbc de Sage ... c long et en plus le fonctionnement est aléatoire ... il vaut mieux prendre sont temps et etudier leur base pour l'attaquer directement ... mais c long ... j'ai mis 4 mois à bien comprendre et à développer TOUT ce qui n existe pas sur ce "Super" Logiciel de M..de désolé ... mais j'en ai vraiement baver et en plus personne chez eux ne nos a aidé .....
je vais essayer de trouver mes codes pour vous donner des idées :::!)))
-- Pierre BOUSQUET
" Ne me dites pas que ce problème est difficile. S'il n'était pas difficile, ce ne serait pas un problème. "
Eric
Le 13 février 2007 à 08:43, dans <news:45d16c15$0$27367$, Dominique Lecocq nous disait :
L'exemple me convient parfaitement, mais ce que je comprend c'est que le driver ODBC est "intelligent".
En quelque sorte, oui.
Pour le "outils" Sage c'est quoi "dissuasif" quand on parle de prix? une idée?
Je ne sais pas car le driver m'est fourni par la société qui me sous-traite les développements SAGE. Cela dit, je peux me renseigner.
Donc pas de limite en ecriture dans la base de données c'etait un peu ma peur...
Attention quand même, certaines tables ne sont pas accessibles en écriture et, dans celles qui le sont, il peut y avoir des champs inaccessibles.
-- Eric
Le 13 février 2007 à 08:43, dans
<news:45d16c15$0$27367$ba4acef3@news.orange.fr>, Dominique Lecocq nous
disait :
L'exemple me convient parfaitement, mais ce que je comprend c'est que le
driver ODBC est "intelligent".
En quelque sorte, oui.
Pour le "outils" Sage c'est quoi "dissuasif" quand on parle de prix? une
idée?
Je ne sais pas car le driver m'est fourni par la société qui me
sous-traite les développements SAGE. Cela dit, je peux me renseigner.
Donc pas de limite en ecriture dans la base de données c'etait un peu ma
peur...
Attention quand même, certaines tables ne sont pas accessibles en
écriture et, dans celles qui le sont, il peut y avoir des champs
inaccessibles.
