Discussion :

[sasuma]

salut à tous,

j'ai un problème, je me connecte en vb à une BD Sql server mais je n'arrive pas à faire une requête sql à partir de cette table.

En access je met ca (le code ci dessous) mais en SQL server je ne sais pas comment le faire???

Ca n'accepte pas que je mette Set MaDb = MaDbSQLServer

merci pour vos aides

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
connection.......
strConn="Provider=SQLOLEDB;DataSource=;uid=;pwd=;database=MaDbSQLServer"
Conn.Open strConn
Set MaDb = MaDbSQLServer
Set Resultat = MaDb.OpenRecordset("SELECT * FROM matable where ")
Resultat.MoveFirst
 
While Not Resultat.EOF
DateOuv = Resultat![OpenDate]
....
Resultat.MoveNext
Wend
Conn.Close
End Sub

[jero44]

Bonjour,
Je ne pense pas que ce soit une erreur SQL Serveur mais cela semble putôt être une erreur lièe au langage Ce n'est pas le bon forum. Mais je vois mal comment vous pouvez esperer travailler sur une base sans faire appel à votre connexion? LA requete est sans doute à associer à la connexion avant de pouvoir l'exécuter.

[sasuma]

Bonjour,
Je ne pense pas que ce soit une erreur SQL Serveur mais cela semble putôt être une erreur lièe au langage Ce n'est pas le bon forum. Mais je vois mal comment vous pouvez esperer travailler sur une base sans faire appel à votre connexion? LA requete est sans doute à associer à la connexion avant de pouvoir l'exécuter.

Bonjour,

J'ai mis plutot ca et ca marche!! merci

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
question.ActiveConnection = mabdsqlserver
question.CommandText = "SELECT * FROM Incident where "
Set Resultat = question.Execute
...

[elsuket]

Quel dommage pour les performances et la maintenabilité :

- Vous avez mis 'SELECT *' : que pensez-vous que l'optimiseur de requêtes fait quand il trouve * ? il va chercher dans les tables système les colonnes des tables spécifiées par votre requête, puis les retourne toutes.
Donc vous surchargez un petit peu en lectures et en CPU, mais un petit peu + un petit peu, ça finit par faire beaucoup.

- Vous n'avez pas précisé le schéma auquel appartient la table 'Incident'. Là encore, ue pensez-vous que l'optimiseur de requêtes fait ? si vous êtes sous SQL Server 2000, il va d'abord chercher la table dans le rôle sys, et dans tous les cas dans le rôle dbo, puis enfin dans les rôles crées par l'utilisateur s'il en existe.

- Comme vous spécifiez la requête dans le code de votre application, vous la faites passer à travers le réseau, SQL Server la compile à chaque fois que vous y faites appel, ... alors qu'en utilisant une procédure stockée vous bénéficiez du cache de plans qui conserve les plans d'exécution compilés. Vous n'avez qu'à appeler votre procédure stockée en lui passant des paramètres : moins de trafic réseau, plus de sécurité, plus de performances ...

- Que se passe-t-il lorsque vous devez modifier la requête ? vous la modifiez dans le code de votre application, puis vous la recompilez et la republiez.
Si vous avez un certain nombre d'utilisateurs, ça devient vite ingérable.
Avec une procédure stockée, vous mettez simplement à jour le code de celle-ci, la modification est instantanée, et vous n'avez pas besoin de recompiler votre application

@++

[agemis31]

Bonsoir,

- Comme vous spécifiez la requête dans le code de votre application, vous la faites passer à travers le réseau, SQL Server la compile à chaque fois que vous y faites appel, ... alors qu'en utilisant une procédure stockée vous bénéficiez du cache de plans qui conserve les plans d'exécution compilés.

C'est un mythe ça, depuis la V7, SQL Serveur compile et cache les requêtes adhoc paramétrées de la même façon que les procédures stockées.
L'énorme avantage d'utiliser les procédures stockés, IMHo, est l'isolation applicatif/Serveur SQL.

@+

[mikedavem]

Bonsoir,



C'est un mythe ça, depuis la V7, SQL Serveur compile et cache les requêtes adhoc paramétrées de la même façon que les procédures stockées.
L'énorme avantage d'utiliser les procédures stockés, IMHo, est l'isolation applicatif/Serveur SQL.

@+

Voilà un sujet controversé

Effectivement, le plan d'exécution des requêtes adhoc sont également mis en cache. Cependant le fait d'envoyer une requête texte qui a été modifiée va certainement provoquer une recompilation du plan d'éxécution et la non utilisation du plan déjà en cache. (Même si le moteur sqlserver est capable de faire une paramétrisation pour des requêtes textes relativement simple).

Il est vrai aussi qu'en utilisant les commandes : SqlCommand et SqlParameter avec l'exécution de la méthode prepare avec ado.net, SQLServer remplace la requête texte d'origine par l'appel de la procédure sp_executesql et permet donc de bénéficier du plan d'éxecution de la requête. Mais dans ce cas également la simple modification de la requête texte provoquera une recompilation du plan.

De plus pour les raisons citées par Elsuket il y a de grandes chances pour qu'il y ait une recompilation du plan d'exécution à chaque fois (absence du schéma par exemple)

Bien sûr l'inconvénient majeur avec les procédures stockées c'est d'utiliser un plan d'éxécution faussé. Il faudra donc utiliser sp_recompile ou l'option WITH RECOMPILE dans la procédure.


Personnellemnt j'ai une nette tendance à préférer l'utilisation des procédures stockées pour ces principales raisons :

- Maintenabilité de l'application
- Sécurité
- Optimisation des données envoyées sur le réseau (On n'envoie sur le réseau que l'appel d'exécution de la procédure et ses paramètres éventuels au lieu de toute la requête sql texte)

[agemis31]

Bonjour mikedavem,

C'est effectivement un sujet contreversé.
Mais ce n'est pas sur la contreverse que je voulais insister , mais sur cette légende qui dit que SQL Serveur ne cacherai pas les query ad hoc.

Pour la contreverse, je préfère de loin les procédures stockées, parce que ca permet d'avoir les données et les traitements essentiels dans la base et de former un frontal cohérent à n'importe quelle application.

Mais il y a des gens qui utilisent correctement du code ad hoc paramétré, parce qu'ils estiment y gagner beaucoup en temps de maintenance (je ne suis pas convaincu). C'est sans doute une question de culture du team de developpement...

@+

[elsuket]

SQL Serveur compile et cache les requêtes adhoc paramétrées de la même façon que les procédures stockées.

Certes, mais cela dépend purement de combien cela coûte de les compiler, et comme pour les procédures stockées, de leur fréquence d'utilisation.
Et si l'on regarde dans les vues dynamiques de SQL Server 2005, on s'aperçoit vite que pour des requêtes ad-hoc même simples, cela coûte un peu plus cher ... et quid de leur optimisation quand elles sont dans une application ?

@++