Discussion :

[Arnard]

Bonjour,

je suis dans un cas assez critique, car ne maitrisant pas .Net (ni visual)

Dans le cas d'utilisation de SQL Server dans une application, il m'a été demandé de créer une classe de connexion à la base de données en OLE DB, afin de n'avoir qu'une seule connexion exploitée par l'application.

1) Comment écrire cette classe sous VB.NET ?

2) Une seule connexion est-elle suffisante, faut-il prévoir un pool de connexion ? Dans ce cas-là la structure de la classe change radicalement, comment faudrait-il alors la concevoir ?

Le désir au final étant de réduire au maximum le nombre de connexions faites ^^

Je remercie les bonnes âmes qui me viendront en aide.

[Pol63]

tout accès aux données doit etre encapsulé dans une connexion et donc celle ci doit etre fermée tout de suite après

si tu fais un select , tu ouvres, tu select, tu traites et tu fermes
meme pour un update tu ouvres et tu fermes juste après

c'est ce que microsoft recommande et ca evite des problemes

pour que ceci soit rapide, sql serveur gère un pool de connexion pré ouvertes donc quand t'en demande une, il te la passe rapidement

donc dans ton code, tu peux utiliser plusieurs objets sqlconnexion ou un seul de toute facon tu dois ouvrir et fermer très souvent

réduire le nombre de connexion n'est pas forcément utile .
et dans ton titre tu as mis ole db, hors ole db sert pour se connecter à access, toi tu dois chercher dans system.data.sqlclient (sqlconnexion sqlcommand sqldatareader etc...)

[Piotrek]

Salut

Dans le cas d'utilisation de SQL Server dans une application, il m'a été demandé de créer une classe de connexion à la base de données en OLE DB, afin de n'avoir qu'une seule connexion exploitée par l'application.

Pourquoi utiliser OLEDB? ca ne garantira pas un nombre de connections moindre qu'avec le driver Sql

2) Une seule connexion est-elle suffisante, faut-il prévoir un pool de connexion ? Dans ce cas-là la structure de la classe change radicalement, comment faudrait-il alors la concevoir ?

Il faut une connection par datareader d'ouvert. Donc tout depend si tu dois avoir deux readers d'ouverts simultanement (c'est pas tres frequent)

Le désir au final étant de réduire au maximum le nombre de connexions faites ^^

En fait la meilleure facon d'avoir un nombre minimal de connection a la base de donnees est d'ouvrir et de refermer les connections que lorsqu'elles doivent etre utilisees
Il existe deja un mechanisme de pooling dans ADO.Net qui garde les connections ouvertes et les reutilise (a condition que la connectionstring a la base de donnees soit strictement la meme)

Connection pooling

[Arnard]

OKi merci déjà pour ces infos, je vais aller sieuter ta page msdn ^^

Pour OLE DB, excusez ma mauvaise formulation, je ne voulais pas dire qu'il devait être utilisé dans le sens de réduire le nombre de connexions, mais qu'il était imposé comme mode de communication (et comme j'y connais rien en VB , ça m'étonne pas de faire des amalgames ^^), et que l'application de base utilise principalement ce mode de communication.

Dans un environnement de réplication, faudrait-il re-instancier les objets de connexion à chaque changement de serveur principal ?

EDIT : via OLEDB, quelle sera la charge de traitement auto, et le traitement que j'aurai à implémenter ? j'imagin que le résultat du traitement sera non traitable par défaut comme objet VB ?!

[Pol63]

Pour OLE DB, excusez ma mauvaise formulation, je ne voulais pas dire qu'il devait être utilisé dans le sens de réduire le nombre de connexions, mais qu'il était imposé comme mode de communication (et comme j'y connais rien en VB , ça m'étonne pas de faire des amalgames ^^), et que l'application de base utilise principalement ce mode de communication.

là j'suis pas trop au point mais il me semble que oledb sert pour access, dans vb.net il faut utiliser les objets spécifique sql server et ca se débrouille

Dans un environnement de réplication, faudrait-il re-instancier les objets de connexion à chaque changement de serveur principal ?

à priori non, l'objet connexion a une chaine de connexion qui précise le serveur
au moment de connexion.open ca utilise la chaine de connexion

mais de toute facon, des objets connexions il vous en faudra surement plusieurs

et puis de toute facon instancier un objet ca prends pas de temps, il n'est pas obligé d'en avoir un global pour l'appli comme à l'ancienne
un dim dans une sub suffit

EDIT : via OLEDB, quelle sera la charge de traitement auto, et le traitement que j'aurai à implémenter ? j'imagin que le résultat du traitement sera non traitable par défaut comme objet VB ?!

hein ?

[Pol63]

je viens de relire la question de départ, et pourquoi voulez vous avoir une classe de connexion ?
que doit elle faire de si différent des classes du framework pour avoir à la réécrire ?

[Arnard]

Déjà, je ne connais pas du tout le fonctionnement, je me base pour l'instant de ce qu'on a pu m'expliquer...

Après, SqlServer est une option, mais il possible que l'on tourne aussi sous PostGreSQL. Celà dépend de l'application de base à partir de laquelle nous développons, qui utilise majoritairement OLEDB et validé pour oracle/sqlserver. postGre n'étant pas encore pris en compte, bien qu'une tentative d'implementation soit apparement prévue par l'equipe développant l'appli de base.

Donc scénario : l'application de base se lance, execute la dll créé par moi-même pour la connexion SQL, et file cet objet à notre appli dépendante de l'appli de base.

Sinon, pour ma dernière question apparement mal formulé, si on fait un SELECT par exemple, qu'est ce que OLE BD va me retourner au final ? Et comment le traiter ?

Comme vous voyez j'ai vraiment peu de billes xD

[Pol63]

Déjà, je ne connais pas du tout le fonctionnement, je me base pour l'instant de ce qu'on a pu m'expliquer...

Après, SqlServer est une option, mais il possible que l'on tourne aussi sous PostGreSQL. Celà dépend de l'application de base à partir de laquelle nous développons, qui utilise majoritairement OLEDB et validé pour oracle/sqlserver. postGre n'étant pas encore pris en compte, bien qu'une tentative d'implementation soit apparement prévue par l'equipe développant l'appli de base.

Donc scénario : l'application de base se lance, execute la dll créé par moi-même pour la connexion SQL, et file cet objet à notre appli dépendante de l'appli de base.

Sinon, pour ma dernière question apparement mal formulé, si on fait un SELECT par exemple, qu'est ce que OLE BD va me retourner au final ? Et comment le traiter ?

Comme vous voyez j'ai vraiment peu de billes xD

deja tu ne peux pas trop aller à l'encontre du systeme ...
sinon une connexion en soit ca ne sert à rien à part connecter
selon ce qu'on veut faire sur la base, vb.net offre plusieurs objets

donc en fait ca va dependre de ce que les gens attendent de l'objet que tu dois faire
tu pourras leur simplifier le travail en leur laissant à disposition que des choses simples et claires et faire le travail derriere

[MaelstroeM]

Pour n'avoir qu'une seule connexion pour toute l'appli une solution peut être d'utiliser un pattern Singleton dans une classe qui heberge une IDbConnection.

Ainsi tu es independant de la source de données et le singleton te garanti que tu utiliseras toujours la même instance de ta connection.

Il y a un article sur le Dev en Couche qui pourrait t'aider :

http://morpheus.developpez.com/architecture/

Moi il m'a bien aidé à éviter de faire des c#@%&ries.

@+