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
jeorme
plutot SQLOLEDB ça marche mieux
dim strconnection as ADODB.connection strConnexion = "Provider=SQLOLEDB.1;Initial Catalog=TaBaseDeDonnees;Data Source=TonServeur" strLogin = "TonLogin" strPass = "TonMotDePasse" Set objConn = New ADODB.Connection
dim Rs as ADODB.recordset
Set RS = new ADODB.recordset rs.open "chaine SQL", strconnection
"Lapin" a écrit dans le message news: #
Bonjour,
J'ai une application VB qui attaque une base Access avec ADO. J'ai migré la base sous SQL Server.
Mais les temps de réponse sont bien plus lents qu'avec Access.
Dois-je utiliser ODBC, SQLOLEDB ou y a t'il une connection plus rapide ?
Merci.
plutot SQLOLEDB ça marche mieux
dim strconnection as ADODB.connection
strConnexion = "Provider=SQLOLEDB.1;Initial Catalog=TaBaseDeDonnees;Data
Source=TonServeur"
strLogin = "TonLogin"
strPass = "TonMotDePasse"
Set objConn = New ADODB.Connection
dim Rs as ADODB.recordset
Set RS = new ADODB.recordset
rs.open "chaine SQL", strconnection
"Lapin" <nospam@nospam.org> a écrit dans le message news:
#qJpu1R3DHA.560@TK2MSFTNGP11.phx.gbl...
Bonjour,
J'ai une application VB qui attaque une base Access avec ADO.
J'ai migré la base sous SQL Server.
Mais les temps de réponse sont bien plus lents qu'avec Access.
Dois-je utiliser ODBC, SQLOLEDB ou y a t'il une connection plus rapide ?
dim strconnection as ADODB.connection strConnexion = "Provider=SQLOLEDB.1;Initial Catalog=TaBaseDeDonnees;Data Source=TonServeur" strLogin = "TonLogin" strPass = "TonMotDePasse" Set objConn = New ADODB.Connection
dim Rs as ADODB.recordset
Set RS = new ADODB.recordset rs.open "chaine SQL", strconnection
"Lapin" a écrit dans le message news: #
Bonjour,
J'ai une application VB qui attaque une base Access avec ADO. J'ai migré la base sous SQL Server.
Mais les temps de réponse sont bien plus lents qu'avec Access.
Dois-je utiliser ODBC, SQLOLEDB ou y a t'il une connection plus rapide ?
Merci.
VUILLERMET Jacques
La lenteur vient-elle de bibliothèque utilisée par la connexion ? Si les temps de réponse sont "bien plus lents", alors il y a peu de chance qu'une amélioration sensible vienne de là.
Voir plutôt en priorité : - l'indexation ; - le dimensionnement matériel du serveur ; - la répartition des fichiers par contrôleur disque, - ...
Ce ne sont que des indications car nous ne savons rien sur cette application et cette base (volumétrie des données ?, migré avec un assistant ?, nb users ?, situation du serveur (même segment réseau que les postes clients ?, traverse un firewall ?, ...) ?, ...) !
Dis-nous en plus sur tes tests !
Jacques.
"Lapin" a écrit dans le message de news: #
Bonjour,
J'ai une application VB qui attaque une base Access avec ADO. J'ai migré la base sous SQL Server.
Mais les temps de réponse sont bien plus lents qu'avec Access.
Dois-je utiliser ODBC, SQLOLEDB ou y a t'il une connection plus rapide ?
Merci.
La lenteur vient-elle de bibliothèque utilisée par la connexion ?
Si les temps de réponse sont "bien plus lents", alors il y a peu de chance
qu'une amélioration sensible vienne de là.
Voir plutôt en priorité :
- l'indexation ;
- le dimensionnement matériel du serveur ;
- la répartition des fichiers par contrôleur disque,
- ...
Ce ne sont que des indications car nous ne savons rien sur cette application
et cette base (volumétrie des données ?, migré avec un assistant ?, nb users
?, situation du serveur (même segment réseau que les postes clients ?,
traverse un firewall ?, ...) ?, ...) !
Dis-nous en plus sur tes tests !
Jacques.
"Lapin" <nospam@nospam.org> a écrit dans le message de news:
#qJpu1R3DHA.560@TK2MSFTNGP11.phx.gbl...
Bonjour,
J'ai une application VB qui attaque une base Access avec ADO.
J'ai migré la base sous SQL Server.
Mais les temps de réponse sont bien plus lents qu'avec Access.
Dois-je utiliser ODBC, SQLOLEDB ou y a t'il une connection plus rapide ?
La lenteur vient-elle de bibliothèque utilisée par la connexion ? Si les temps de réponse sont "bien plus lents", alors il y a peu de chance qu'une amélioration sensible vienne de là.
Voir plutôt en priorité : - l'indexation ; - le dimensionnement matériel du serveur ; - la répartition des fichiers par contrôleur disque, - ...
Ce ne sont que des indications car nous ne savons rien sur cette application et cette base (volumétrie des données ?, migré avec un assistant ?, nb users ?, situation du serveur (même segment réseau que les postes clients ?, traverse un firewall ?, ...) ?, ...) !
Dis-nous en plus sur tes tests !
Jacques.
"Lapin" a écrit dans le message de news: #
Bonjour,
J'ai une application VB qui attaque une base Access avec ADO. J'ai migré la base sous SQL Server.
Mais les temps de réponse sont bien plus lents qu'avec Access.
Dois-je utiliser ODBC, SQLOLEDB ou y a t'il une connection plus rapide ?
Merci.
jmn
Une information qui pourrait vous aider...
Sous Access, les requêtes : "select * from truc" ET "select champ1,champ2 from truc" s'exécutent dans le même temps. Si truc comporte beaucoup de champs, ce n'est absolument pas la même chose avec SQL server : il faut éviter les '*' et préciser une liste de champs explicite (et seulement ceux dont vous avez besoin !). Dans le cas de tables avec de nombreux champs, la différence de temps d'exécution est spectaculaire.
Une information qui pourrait vous aider...
Sous Access, les requêtes : "select * from truc" ET "select champ1,champ2
from truc" s'exécutent dans le même temps. Si truc comporte beaucoup de
champs, ce n'est absolument pas la même chose avec SQL server : il faut
éviter les '*' et préciser une liste de champs explicite (et seulement ceux
dont vous avez besoin !). Dans le cas de tables avec de nombreux champs, la
différence de temps d'exécution est spectaculaire.
Sous Access, les requêtes : "select * from truc" ET "select champ1,champ2 from truc" s'exécutent dans le même temps. Si truc comporte beaucoup de champs, ce n'est absolument pas la même chose avec SQL server : il faut éviter les '*' et préciser une liste de champs explicite (et seulement ceux dont vous avez besoin !). Dans le cas de tables avec de nombreux champs, la différence de temps d'exécution est spectaculaire.
Yan
Bonjour,
Pour compléter, si y a beaucoup de volume, il faut sans doute lancer le calcul des stats puisque les plans d'exécution des vues sont basés dessus.
Yan
-----Message d'origine----- Bonjour,
J'ai une application VB qui attaque une base Access avec
ADO.
J'ai migré la base sous SQL Server.
Mais les temps de réponse sont bien plus lents qu'avec
Access.
Dois-je utiliser ODBC, SQLOLEDB ou y a t'il une
connection plus rapide ?
Merci.
.
Bonjour,
Pour compléter, si y a beaucoup de volume, il faut sans
doute lancer le calcul des stats puisque les plans
d'exécution des vues sont basés dessus.
Yan
-----Message d'origine-----
Bonjour,
J'ai une application VB qui attaque une base Access avec
ADO.
J'ai migré la base sous SQL Server.
Mais les temps de réponse sont bien plus lents qu'avec
