Discussion :

[zooffy]

Bonjour

Je vais avoir beaucoup de mal à exprimer mon souci, car je n'arrive pas à le cerner.
J'ai plein de souci avec ma liaison sur la BDD. J'ai fait un test sur un serveur beaucoup plus puissant que mon serveur de DEV et j'ai la même chose, donc j'ai écarté les soucis de temps de réponse ou de puissance pure sur serveur.

Donc, mes soucis sont trés disparates :
- l'état de la connexion est ouvert
- le volume ne peut pas être Read
- aucune ligne à la position 0 (alors que je sais trés bien qu'il y a des données)
- le champ Machin n'existe pas (alors que je sais qu'il est dans la table)

Bref, pas mal de soucis qui se règle jsute en faisant F5 la plupart du temps.
Alors vu que je sollicite pas mal la BDD je me dis que certainement, j'ai mal configurer ma ConnectionString. Et vu que je suis un poil léger sur ce genre de chose, je voudrais vous la soumettre pour que vous puissiez me dire les paramettre que je devrais rajouter pour "fiabiliser" la liaison avec la BDD.

Code :

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

1
2
3
4
 
<connectionStrings>
    <add name="CS" connectionString="data source=SERVEUR; Initial Catalog=BASE;user id=USER;pwd=PASS"/>
  </connectionStrings>

Elle est définie dans le Web.Config, en majuscule, les valeurs des choses.

Merci pour votre aide.

[nah666]

provider name ?

moi j'ai providerName="System.Data.SqlClient" (dans la CS)

tu ferme bien tes connexions ?

[zooffy]

Je viens de rajouter le Provider Name et ça n'a rien changé. Mais je vais le garder, ça m'a l'air pas mal comme truc.

Sinon, sur la fermeture des connexion, oui, elles sont fermées, enfin je crois bien que oui.

Mes connections : soit elles sont fait avec un SqlDataSource pour les GridView, soit elles sont faite par un FrameWork amison qui gère la chose de la manière suivante :

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
16
17
18
19
20
21
22
23
 
Public Function ExecuterRequeteSimple(ByVal requete As String) As DataTable
         Try
                ' On assigne une requêtes parametrée à la commande
                Dim commande As New SqlCommand(requete)
 
                ' On lui assigne une connexion
                commande.Connection = Me.Conex
 
                Adapteur = New SqlDataAdapter(commande)
                Dim oCommandBuilder As New SqlCommandBuilder(Adapteur)
 
                Table = New DataTable()
                Conex.Open()
                Adapteur.Fill(Table)
 
                Return Table
            Catch ex As Exception
                Throw New AppExecption(ex)
            Finally
                Me.Conex.Close()
            End Try
        End Function

Donc, vu le Finally, j'en déduis que, quoi qu'il arrive, la connexion est refermée.

Donc c'est les deux seules méthodes que j'utilise pour aller dans la BDD.

[nah666]

Tu as un return Table avant de fermer ta connexion.

Donc en fait tu la ferme que si ca se passe mal

[nah666]

J'ai dit une connerie, le finally passe tout de meme, c'est pas ca

[nah666]

Essaie de faire un test sur l'etat de ta connexion juste apres le close.

voir deja si c'est la fermeture qui pose probleme.

[zooffy]

Quel genre de test ?
Et puis, ça pose quelques soucis car c'est un FrameWork Maison, donc il est compilé et encapsulé dans une DLL qu'il faut metre à jour sur le serveru, dans le GAC de toutes les machines, bla, bla, bla.

Donc si tu pouvais m'indiquer un test plus simple à faire, ça serait pas mal.

[nah666]

Un truc du genre :

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
16
17
18
19
20
21
22
23
24
25
26
 
Public Function ExecuterRequeteSimple(ByVal requete As String) As DataTable
         Try
                ' On assigne une requêtes parametrée à la commande
                Dim commande As New SqlCommand(requete)
 
                ' On lui assigne une connexion
                commande.Connection = Me.Conex
 
                Adapteur = New SqlDataAdapter(commande)
                Dim oCommandBuilder As New SqlCommandBuilder(Adapteur)
 
                Table = New DataTable()
                Conex.Open()
                Adapteur.Fill(Table)
 
                Return Table
            Catch ex As Exception
                Throw New AppExecption(ex)
            Finally
                Me.Conex.Close()
                if conex.state <> ConnectionState.Closed then
                  msgbox("ya un souci! " & conex.state)
                endif
            End Try
        End Function

[zooffy]

Ok, je vois mieux.

Mais si je mettais ce test juste aprés l'appel de cette fonction dans mon code, ça ferais pareil ?

[nah666]

Normalement oui, je sais pas ce que tu fais de ta connex ailleurs vu qu'elle est pas déclarée dans ta fonction

[zooffy]

STOP ! Zooffy est un boulet !
Prière de ne pas ébruité la chose, il a un ego surdimensionné et suporterait trés mal de voir la communauté toute entière détenir une information de ce prix là !

Bref, je pense que j'ai trouvé d'où viennet tous mes souci de conenxion. Donc je soumets mon diée et tu me dis (les autres qui passent peuvent donner leur avis aussi).

Donc, mon FrameWork Maison me rend bien service, mais je crois que je l'ai un poil trop sollicité. La bestiole qui sert à exécuter les requête (voir le code plus bas dans le topic ou plus haut pour ceux qui lise les messages dans l'autre sens) est un Méthode d'un objet dont voici la New

Code :

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

1
2
3
4
5
6
7
8
9
 
Public Class DataManager
        Public Sub New(ByVal idChainCo As String)
            Dim sRQ As String = FichierConfiguration.GetChaineCon(idChainCo)
            If sRQ = "" Then
                Throw New AppExecption("Chaine de connexion " & idChainCo & " introuvable")
            End If
            Conex = New SqlConnection(sRQ)
        End Sub

idChainCo sert à récupérer dans le Web.Config la chaine complète du même nom.

Donc tout va bien et ça marche super. Les ennuis commencent lorsque Zooffy veut faire son radin et économiser du code. Alors il fait des conneries dans ce genre là :

Code :

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

1
2
3
4
5
6
 
Imports Microsoft.VisualBasic
 
Namespace OutilWeb
	Public Class OutilsOW
		Public Shared dmGlobCS As New DataManager("CS")

Et il mets ça dans le Web.Config

Code :

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

1
2
3
4
5
6
 
 <system.web>
		<pages theme="Default" validateRequest="false" enableEventValidation="true">
      <namespaces>
        <clear/>
        <add namespace="OutilWeb.OutilsOW"/>

Et c'est super j'ai un DataManager tout prés dans toutes mes pages.
Et donc lorsque j'ai besoins je fais directement ça

Code :

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

1
2
 
Dim dt As DataTable = dmGlobCS.ExecuterRequeteSimple("la requête qui va bien")

Ben oui, mais si dans la page on l'appelle 10 fois le machin, y un moment où il doit se mélanger les pineaux sévère, puisque c'est la même instance de l'objet, non ?
Et alors encore pire lorsqu'il y a deux pages différentes qui l'appelle, là il commence à paniquer
Et à la fin, il fait son gréviste de base, se met en rogne et commence à avoir des revendications. Bilan, il bloque tout (tiens on dirait la SNCF.....) et paralyse l'application (tiens, ça on dirait la France, quand la SNCF.......)

Bref, je pense que je vais repasser dans tout mon code pour arrêter les économie de bout de chandelles. Si vous avez une solution de remplacement pour me permettre de faire quand même mon économie de code, je veux bien.

Mais surtout dites moi si j'ai bien pris la bonne route, parce que je voudrais pas faire toutes les modifs et m'apercevoir que c'est pas ça.

[zooffy]

Normalement oui, je sais pas ce que tu fais de ta connex ailleurs vu qu'elle est pas déclarée dans ta fonction

Avec tous les bouts de code du topic, plus celui là, tu peux reproduire le fameux FrameWork, pour la partie accès base de données.

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
16
 
Private _conex As SqlConnection
        ''' <summary>
        ''' Connexion à la base de données
        ''' </summary>
        ''' <value></value>
        ''' <returns></returns>
        ''' <remarks></remarks>
        Private Property Conex() As SqlConnection
            Get
                Return _conex
            End Get
            Set(ByVal value As SqlConnection)
                _conex = value
            End Set
        End Property

J'aimerais bien partager plus, voir même tout le projet, mais je risque de me faire un peux taper sur les doigts. Maintenant, y d'autres moyens, genre si tu m'écrivais en perso pour me dire que tu as trouvé un trés bon groupe de Power Métal ou plutôt du Death Mélodic suédois

[nah666]

Si j'ai compris ton souci, oui les shared c'est TRES dangereux en web car ils sont partagés par tout le monde.

Et pour ton Framework, j'apprecie ta proposition, mais je pense qu'on en a tous un, et j'ai le mien

[SaumonAgile]

Si tu veux vraiment améliorer tes accès aux données, tu devrais plutôt le baser sur les conseils que tu trouveras ici : http://johannblais.developpez.com/tu...acces-donnees/

En fait, ton membre shared ne sert qu'à te créer des problèmes. Et en plus ton "framework" ne gère pas du tout les paramètres SQL (ce qui en soi est déjà une raison de le faire évoluer).

[zooffy]

Merci Saumon, longtemps que je ne t'avais lu sur un de mes topics.

Je vais potasser ce tuto qui m'as l'air trés interressant.
Juste un point, à la cantonade "Requête parametrée" versus "tout en Proc Stock", niveau sécurité, ça vaut quoi ?

Parce que j'ai pris cette orientation par commodité, ça me permet de récupérer des truc dans le cadre des requêtes action, le nombre de ligne affectés, par exemple et ça me donne une plus grande souplesse de travail sur la BDD, genre je déporte une aprtie de la charge de travail sur le server SQL lorsqu'il s'agit de manipuler des données uniquement, plutôt que faire faire des manipulations par le codeBehind. Mon server SQL était une grosse faignasse, maintenant c'est un homme, un vrai avec du poil, il bosse, 60 %d'UC en moyenne et remplissage de la mémoire physique

[SaumonAgile]

Ton appli peut être un mix "requetes param"/"stored proc".

Ce que j'entendais par "requêtes paramétrées", c'est que ta méthode ExecuterRequeteSimple prend en paramètre une chaine de caractères représentant la requête SQL. Le problème est que pour une requête de type :

Code :

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

SELECT dbo.Table.[les champs] FROM dbo.Table WHERE dbo.Table.Champ = 'toto'

ton framework devrait passer la valeur toto dans un paramètre SQL et pas directement concaténée dans la requête, pour tout un tas de raisons expliquées dans mon article.

Ceci dit, si tu utilises des stored proc, tu es déjà obligé de passer par des paramètres SQL, donc le problème ne se pose plus.
C'est simple pour les requêtes SQL écrites à la mimine.

[predalpha]

Merci pour l'article saumon,

j'ai assez honte depuis que je l'ai lu mais maintenant je saurais eviter les désagréments des paramètres inscrits directement en sql.

[SaumonAgile]

j'ai assez honte depuis que je l'ai lu

Mieux vaut avoir honte une bonne fois que de se satisfaire indéfiniment de médiocrité.

[zooffy]

Merci pour toutes ces précisions. Je vais procéder à la lecture de l'évangile SQLienne par Saint Saumon et faire en sorte de trnsmettre la bonne parole à tous les petits programmes et autres pages web de la paroisse.

Je boucle et j'ouvre une autre topic, y a un truc que je capte pas sur les Shared