Je suis en train de tester l'accès à SQL serveur par les commandes
Hlitxxxxxxx afin de migrer à peu de frais une application de HF à SQL
SERVEUR.
Effectivement sa fonctionne sans trop toucher au code existant (sauf
utilisation de HNumEnr() et la gestion des accès concurrentiel qui est à
repenser). Néanmoins les temps de réponse sont très mauvais. Plus mauvais
qu'avec HF ! Je test donc avec l'accès natif SQL serveur en version démo
(celui qui mélange certain résultat) et les temps de réponse sont très bon !
La différence est-elle que je me demande si l'accès par le client OLEDB
n'est pas intentionnellement bridé par PCSOFT !
Bon, si vous-voulez intervenir à vous la parole ...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Frédéric LAMBOUR
Heu bug dans mon message :)
il faut lire : La différence EST TELLE que je me demande si l'accès par le client OLEDB n'est pas intentionnellement bridé par PCSOFT !
"Frédéric LAMBOUR" a écrit dans le message de news:dknnuu$r83$
Je suis en train de tester l'accès à SQL serveur par les commandes Hlitxxxxxxx afin de migrer à peu de frais une application de HF à SQL SERVEUR.
Effectivement sa fonctionne sans trop toucher au code existant (sauf utilisation de HNumEnr() et la gestion des accès concurrentiel qui est à repenser). Néanmoins les temps de réponse sont très mauvais. Plus mauvais qu'avec HF ! Je test donc avec l'accès natif SQL serveur en version démo (celui qui mélange certain résultat) et les temps de réponse sont très bon
!
La différence est-elle que je me demande si l'accès par le client OLEDB n'est pas intentionnellement bridé par PCSOFT !
Bon, si vous-voulez intervenir à vous la parole ...
Heu bug dans mon message :)
il faut lire : La différence EST TELLE que je me demande si l'accès par le
client OLEDB n'est pas intentionnellement bridé par PCSOFT !
"Frédéric LAMBOUR" <PasDeSpam_f.LAMBOUR@everlog.com> a écrit dans le message
de news:dknnuu$r83$1@aphrodite.grec.isp.9tel.net...
Je suis en train de tester l'accès à SQL serveur par les commandes
Hlitxxxxxxx afin de migrer à peu de frais une application de HF à SQL
SERVEUR.
Effectivement sa fonctionne sans trop toucher au code existant (sauf
utilisation de HNumEnr() et la gestion des accès concurrentiel qui est à
repenser). Néanmoins les temps de réponse sont très mauvais. Plus mauvais
qu'avec HF ! Je test donc avec l'accès natif SQL serveur en version démo
(celui qui mélange certain résultat) et les temps de réponse sont très bon
!
La différence est-elle que je me demande si l'accès par le client OLEDB
n'est pas intentionnellement bridé par PCSOFT !
Bon, si vous-voulez intervenir à vous la parole ...
il faut lire : La différence EST TELLE que je me demande si l'accès par le client OLEDB n'est pas intentionnellement bridé par PCSOFT !
"Frédéric LAMBOUR" a écrit dans le message de news:dknnuu$r83$
Je suis en train de tester l'accès à SQL serveur par les commandes Hlitxxxxxxx afin de migrer à peu de frais une application de HF à SQL SERVEUR.
Effectivement sa fonctionne sans trop toucher au code existant (sauf utilisation de HNumEnr() et la gestion des accès concurrentiel qui est à repenser). Néanmoins les temps de réponse sont très mauvais. Plus mauvais qu'avec HF ! Je test donc avec l'accès natif SQL serveur en version démo (celui qui mélange certain résultat) et les temps de réponse sont très bon
!
La différence est-elle que je me demande si l'accès par le client OLEDB n'est pas intentionnellement bridé par PCSOFT !
Bon, si vous-voulez intervenir à vous la parole ...
Emmanuel Lecoester
"Frédéric LAMBOUR" a écrit dans le message de news:dknnuu$r83$
Je suis en train de tester l'accès à SQL serveur par les commandes Hlitxxxxxxx afin de migrer à peu de frais une application de HF à SQL SERVEUR.
Effectivement sa fonctionne sans trop toucher au code existant (sauf utilisation de HNumEnr() et la gestion des accès concurrentiel qui est à repenser). Néanmoins les temps de réponse sont très mauvais. Plus mauvais qu'avec HF ! Je test donc avec l'accès natif SQL serveur en version démo (celui qui mélange certain résultat) et les temps de réponse sont très bon
!
La différence est-elle que je me demande si l'accès par le client OLEDB n'est pas intentionnellement bridé par PCSOFT !
Bon, si vous-voulez intervenir à vous la parole ...
L'accès par ole-db utilise au mieux 1 couche middleware, 2 au pire (ajouter la couche ODBC). L'accès natif comme son nom l'indique n'utilise pas de couche mais un accès par API => 0 couches. D'où les temps plus rapides. Pour mieux comprendre ton soucis, il serait souhaitable d'avoir la version du MDAC installée, le numéro de vesrion du driver ole-db utilisé. Ensuite il nous faudrait un bench car il n'y a rien de pire que de dire c'est plus lent... c'est plus rapide.... OK mais de combien ? par rapport à quoi ? dans la même Partant du principe que tu es de bonne fois... config réseau? Car ne l'oubliais pas, pour comparer deux bases, les tests se font en réseau avec accès concurrentiels. Pour info, lors de mes tests initiaux, HF est plus rapide que MySQL en mono utilisateur !
Voilà. Merci de continuer ton post avec les éléments demandés ;-)
"Frédéric LAMBOUR" <PasDeSpam_f.LAMBOUR@everlog.com> a écrit dans le message
de news:dknnuu$r83$1@aphrodite.grec.isp.9tel.net...
Je suis en train de tester l'accès à SQL serveur par les commandes
Hlitxxxxxxx afin de migrer à peu de frais une application de HF à SQL
SERVEUR.
Effectivement sa fonctionne sans trop toucher au code existant (sauf
utilisation de HNumEnr() et la gestion des accès concurrentiel qui est à
repenser). Néanmoins les temps de réponse sont très mauvais. Plus mauvais
qu'avec HF ! Je test donc avec l'accès natif SQL serveur en version démo
(celui qui mélange certain résultat) et les temps de réponse sont très bon
!
La différence est-elle que je me demande si l'accès par le client OLEDB
n'est pas intentionnellement bridé par PCSOFT !
Bon, si vous-voulez intervenir à vous la parole ...
L'accès par ole-db utilise au mieux 1 couche middleware, 2 au pire (ajouter
la couche ODBC). L'accès natif comme son nom l'indique n'utilise pas de
couche mais un accès par API => 0 couches. D'où les temps plus rapides.
Pour mieux comprendre ton soucis, il serait souhaitable d'avoir la version
du MDAC installée, le numéro de vesrion du driver ole-db utilisé.
Ensuite il nous faudrait un bench car il n'y a rien de pire que de dire
c'est plus lent... c'est plus rapide.... OK mais de combien ? par rapport à
quoi ? dans la même
Partant du principe que tu es de bonne fois...
config réseau? Car ne l'oubliais pas, pour comparer deux bases, les tests se
font en réseau avec accès concurrentiels. Pour info, lors de mes tests
initiaux, HF est plus rapide que MySQL en mono utilisateur !
Voilà. Merci de continuer ton post avec les éléments demandés ;-)
"Frédéric LAMBOUR" a écrit dans le message de news:dknnuu$r83$
Je suis en train de tester l'accès à SQL serveur par les commandes Hlitxxxxxxx afin de migrer à peu de frais une application de HF à SQL SERVEUR.
Effectivement sa fonctionne sans trop toucher au code existant (sauf utilisation de HNumEnr() et la gestion des accès concurrentiel qui est à repenser). Néanmoins les temps de réponse sont très mauvais. Plus mauvais qu'avec HF ! Je test donc avec l'accès natif SQL serveur en version démo (celui qui mélange certain résultat) et les temps de réponse sont très bon
!
La différence est-elle que je me demande si l'accès par le client OLEDB n'est pas intentionnellement bridé par PCSOFT !
Bon, si vous-voulez intervenir à vous la parole ...
L'accès par ole-db utilise au mieux 1 couche middleware, 2 au pire (ajouter la couche ODBC). L'accès natif comme son nom l'indique n'utilise pas de couche mais un accès par API => 0 couches. D'où les temps plus rapides. Pour mieux comprendre ton soucis, il serait souhaitable d'avoir la version du MDAC installée, le numéro de vesrion du driver ole-db utilisé. Ensuite il nous faudrait un bench car il n'y a rien de pire que de dire c'est plus lent... c'est plus rapide.... OK mais de combien ? par rapport à quoi ? dans la même Partant du principe que tu es de bonne fois... config réseau? Car ne l'oubliais pas, pour comparer deux bases, les tests se font en réseau avec accès concurrentiels. Pour info, lors de mes tests initiaux, HF est plus rapide que MySQL en mono utilisateur !
Voilà. Merci de continuer ton post avec les éléments demandés ;-)
Vincent
"Emmanuel Lecoester" a écrit dans le message de news: 436f91df$0$21622$
"Frédéric LAMBOUR" a écrit dans le message de news:dknnuu$r83$
Je suis en train de tester l'accès à SQL serveur par les commandes Hlitxxxxxxx afin de migrer à peu de frais une application de HF à SQL SERVEUR.
Effectivement sa fonctionne sans trop toucher au code existant (sauf utilisation de HNumEnr() et la gestion des accès concurrentiel qui est à repenser). Néanmoins les temps de réponse sont très mauvais. Plus mauvais qu'avec HF ! Je test donc avec l'accès natif SQL serveur en version démo (celui qui mélange certain résultat) et les temps de réponse sont très bon
!
La différence est-elle que je me demande si l'accès par le client OLEDB n'est pas intentionnellement bridé par PCSOFT !
Bon, si vous-voulez intervenir à vous la parole ...
L'accès par ole-db utilise au mieux 1 couche middleware, 2 au pire (ajouter la couche ODBC). L'accès natif comme son nom l'indique n'utilise pas de couche mais un accès par API => 0 couches. D'où les temps plus rapides. Pour mieux comprendre ton soucis, il serait souhaitable d'avoir la version du MDAC installée, le numéro de vesrion du driver ole-db utilisé. Ensuite il nous faudrait un bench car il n'y a rien de pire que de dire c'est plus lent... c'est plus rapide.... OK mais de combien ? par rapport à quoi ? dans la même Partant du principe que tu es de bonne fois... config réseau? Car ne l'oubliais pas, pour comparer deux bases, les tests se font en réseau avec accès concurrentiels. Pour info, lors de mes tests initiaux, HF est plus rapide que MySQL en mono utilisateur !
Voilà. Merci de continuer ton post avec les éléments demandés ;-)
Ce n'est pas évident à faire, mais un programme de base en C# pourra te donner aussi une idée, afin de savoir si c'est windev ou l'oledb qui rame. La bonne version de mdac semble importante. Es-tu sur la même machine que ton serveur ? J'ai essayé la même chose avec postgres via oledb et ca ne marche pas ! l'analyse n'arrive pas à récupérer les tables ! là aussi je ne sais pas si c'est la volonté de windev de faire acheter l'acces natif, j'ai developpé une classe en C# avec des fonction du genre LirePremier .... Je ne profite pas des versEcran .... pour remplir les champs automatiquement mais tampis, j'utilise le code windev de moins en moins, uniquement pour faire de "jolies fenêtres". Les traitements sont en c# pour pouvoir les récupérer en dehors de windev, windev pouvant récupérer les classes des autres langages
Vincent
il existe des acess natif alternatifs
"Emmanuel Lecoester" <elecoest@netcourrier.com> a écrit dans le message de
news: 436f91df$0$21622$636a15ce@news.free.fr...
"Frédéric LAMBOUR" <PasDeSpam_f.LAMBOUR@everlog.com> a écrit dans le
message
de news:dknnuu$r83$1@aphrodite.grec.isp.9tel.net...
Je suis en train de tester l'accès à SQL serveur par les commandes
Hlitxxxxxxx afin de migrer à peu de frais une application de HF à SQL
SERVEUR.
Effectivement sa fonctionne sans trop toucher au code existant (sauf
utilisation de HNumEnr() et la gestion des accès concurrentiel qui est à
repenser). Néanmoins les temps de réponse sont très mauvais. Plus mauvais
qu'avec HF ! Je test donc avec l'accès natif SQL serveur en version démo
(celui qui mélange certain résultat) et les temps de réponse sont très
bon
!
La différence est-elle que je me demande si l'accès par le client OLEDB
n'est pas intentionnellement bridé par PCSOFT !
Bon, si vous-voulez intervenir à vous la parole ...
L'accès par ole-db utilise au mieux 1 couche middleware, 2 au pire
(ajouter
la couche ODBC). L'accès natif comme son nom l'indique n'utilise pas de
couche mais un accès par API => 0 couches. D'où les temps plus rapides.
Pour mieux comprendre ton soucis, il serait souhaitable d'avoir la version
du MDAC installée, le numéro de vesrion du driver ole-db utilisé.
Ensuite il nous faudrait un bench car il n'y a rien de pire que de dire
c'est plus lent... c'est plus rapide.... OK mais de combien ? par rapport
à
quoi ? dans la même
Partant du principe que tu es de bonne fois...
config réseau? Car ne l'oubliais pas, pour comparer deux bases, les tests
se
font en réseau avec accès concurrentiels. Pour info, lors de mes tests
initiaux, HF est plus rapide que MySQL en mono utilisateur !
Voilà. Merci de continuer ton post avec les éléments demandés ;-)
Ce n'est pas évident à faire, mais un programme de base en C# pourra te
donner aussi une idée,
afin de savoir si c'est windev ou l'oledb qui rame. La bonne version de mdac
semble importante.
Es-tu sur la même machine que ton serveur ?
J'ai essayé la même chose avec postgres via oledb et ca ne marche pas !
l'analyse n'arrive pas à
récupérer les tables ! là aussi je ne sais pas si c'est la volonté de windev
de faire acheter l'acces
natif, j'ai developpé une classe en C# avec des fonction du genre
LirePremier ....
Je ne profite pas des versEcran .... pour remplir les champs automatiquement
mais tampis, j'utilise le code
windev de moins en moins, uniquement pour faire de "jolies fenêtres". Les
traitements sont en c# pour pouvoir les récupérer
en dehors de windev, windev pouvant récupérer les classes des autres
langages
"Emmanuel Lecoester" a écrit dans le message de news: 436f91df$0$21622$
"Frédéric LAMBOUR" a écrit dans le message de news:dknnuu$r83$
Je suis en train de tester l'accès à SQL serveur par les commandes Hlitxxxxxxx afin de migrer à peu de frais une application de HF à SQL SERVEUR.
Effectivement sa fonctionne sans trop toucher au code existant (sauf utilisation de HNumEnr() et la gestion des accès concurrentiel qui est à repenser). Néanmoins les temps de réponse sont très mauvais. Plus mauvais qu'avec HF ! Je test donc avec l'accès natif SQL serveur en version démo (celui qui mélange certain résultat) et les temps de réponse sont très bon
!
La différence est-elle que je me demande si l'accès par le client OLEDB n'est pas intentionnellement bridé par PCSOFT !
Bon, si vous-voulez intervenir à vous la parole ...
L'accès par ole-db utilise au mieux 1 couche middleware, 2 au pire (ajouter la couche ODBC). L'accès natif comme son nom l'indique n'utilise pas de couche mais un accès par API => 0 couches. D'où les temps plus rapides. Pour mieux comprendre ton soucis, il serait souhaitable d'avoir la version du MDAC installée, le numéro de vesrion du driver ole-db utilisé. Ensuite il nous faudrait un bench car il n'y a rien de pire que de dire c'est plus lent... c'est plus rapide.... OK mais de combien ? par rapport à quoi ? dans la même Partant du principe que tu es de bonne fois... config réseau? Car ne l'oubliais pas, pour comparer deux bases, les tests se font en réseau avec accès concurrentiels. Pour info, lors de mes tests initiaux, HF est plus rapide que MySQL en mono utilisateur !
Voilà. Merci de continuer ton post avec les éléments demandés ;-)
Ce n'est pas évident à faire, mais un programme de base en C# pourra te donner aussi une idée, afin de savoir si c'est windev ou l'oledb qui rame. La bonne version de mdac semble importante. Es-tu sur la même machine que ton serveur ? J'ai essayé la même chose avec postgres via oledb et ca ne marche pas ! l'analyse n'arrive pas à récupérer les tables ! là aussi je ne sais pas si c'est la volonté de windev de faire acheter l'acces natif, j'ai developpé une classe en C# avec des fonction du genre LirePremier .... Je ne profite pas des versEcran .... pour remplir les champs automatiquement mais tampis, j'utilise le code windev de moins en moins, uniquement pour faire de "jolies fenêtres". Les traitements sont en c# pour pouvoir les récupérer en dehors de windev, windev pouvant récupérer les classes des autres langages
