Discussion :

[nyassouh]

Bonsoir,
je cherche a faire affiché des données depuis la BDD dans un datagrid et j'aimerai que les données s'actualisent automatiquement par exemple toute les 3 secondes les mise à jour des données s'affiche automatiquement dans le datagridview.
Merci.

[François DORIN]

Bonjour,

Plusieurs possibilités. Les deux plus simples sont les suivantes.

La première consiste à utiliser un timer et exécuter une requête toutes les 3 secondes, et à ensuite afficher les résultats.

La seconde, consiste à utiliser un SqlDepencendy, qui permet d'être notifié en temps réel lorsqu'une requête donnée retourne un jeu de valeur différents. Attention toutefois, cette solution est conçu à la base pour des serveurs (et donc un nombre très limité de client). S'il peut y avoir un grand nombre de client, il vaut mieux utiliser la première approche.

[nyassouh]

Bonjour,

Plusieurs possibilités. Les deux plus simples sont les suivantes.

La première consiste à utiliser un timer et exécuter une requête toutes les 3 secondes, et à ensuite afficher les résultats.

La seconde, consiste à utiliser un SqlDepencendy, qui permet d'être notifié en temps réel lorsqu'une requête donnée retourne un jeu de valeur différents. Attention toutefois, cette solution est conçu à la base pour des serveurs (et donc un nombre très limité de client). S'il peut y avoir un grand nombre de client, il vaut mieux utiliser la première approche.

Bonsoir,
je vous remercie François pour vos solutions précieuses mais j'ai déjà essayer avec un timer il affiche les résultats souhaité et au bout de quelques minutes l'application se plante et affiche un message d'erreur.
je pense que cela est du a cause des données un peut volumineux et du nombre des requêtes envoyer vers SQL serveur chaque seconde.
j'aimerai bien savoir votre avis et vos conseils précieuses.
merci d'avance.

[François DORIN]

j'ai déjà essayer avec un timer il affiche les résultats souhaité et au bout de quelques minutes l'application se plante et affiche un message d'erreur.

Et bien on va en trouver la cause !

Quel est le message d'erreur ?

[nyassouh]

Quel est le message d'erreur ?[/QUOTE]


Voici l'erreur qui s'affiche après quelques minutes :

[François DORIN]

Alors, effectivement, le fournisseur de données génère une exception E_OUTOFMEMORY. Comme son nom l'indique, la mémoire est insuffisante. Cela peut se produire si les données récupérées sont très volumineuse et dépasse les capacités de la machine. Cela peut aussi se produire si l'application est une application 32 bits sur une architecture 64 bits. Changer de méthode pour accéder aux données ne changera pas fondamentalement les choses...

Maintenant, je m'interroge sur la pertinence d'actualiser un jeu de données volumineux (je dirais plus d'une centaine de milliers d'enregistrements) toutes les 3 secondes dans un datagrid...

Si l'objectif est d'afficher des statistiques, alors il vaut mieux faire calculer ces statistiques au SGBD.

[Noxen]

Est-ce-qu'il ne serait pas possible dans la (ou les) table concernée une colonne avec le timestamp de la dernière modification de l'enregistrement et de ne récupérer les données que s'il y a eu des modifications depuis la dernière requête ?

[nyassouh]

Alors, effectivement, le fournisseur de données génère une exception E_OUTOFMEMORY. Comme son nom l'indique, la mémoire est insuffisante. Cela peut se produire si les données récupérées sont très volumineuse et dépasse les capacités de la machine. Cela peut aussi se produire si l'application est une application 32 bits sur une architecture 64 bits. Changer de méthode pour accéder aux données ne changera pas fondamentalement les choses...

Maintenant, je m'interroge sur la pertinence d'actualiser un jeu de données volumineux (je dirais plus d'une centaine de milliers d'enregistrements) toutes les 3 secondes dans un datagrid...

Si l'objectif est d'afficher des statistiques, alors il vaut mieux faire calculer ces statistiques au SGBD.

En effet,je me douté sur la capacité mémoire puisque je travail sur mon ordinateur personnel et donc je me pose la question si j'installe SQL server sur un ordinateur serveur puissant est ce que sa peut résoudre le problème ?
Concernant l'objectif , je vous explique l'utilité d'affiché tous ces données en temps réel, en fait cette application c'est un CRM dédié pour les centres d'appels, donc la tâche du superviseur et de contrôlé les téléopérateurs a partir de cette page qui lui affiche tout ce qui se passe avec les téléopérateurs depuis son poste de travail.
voila en résumé l'objectif de cette page.

[nyassouh]

Est-ce-qu'il ne serait pas possible dans la (ou les) table concernée une colonne avec le timestamp de la dernière modification de l'enregistrement et de ne récupérer les données que s'il y a eu des modifications depuis la dernière requête ?

En fait ces deux tables permet au superviseur de contrôlé l'état des téléopérateurs par exemple si un téléopérateur est en cours d'appel et il a dépasser les 3 minutes le superviseur doit intervenir ou bien si un téléopérateur a dépassé la limite d'une pause il doit aussi intervenir ...
Ce pour cela les données doivent être à jour chaque seconde et au max chaque 5 secondes.

[François DORIN]

En effet,je me douté sur la capacité mémoire puisque je travail sur mon ordinateur personnel et donc je me pose la question si j'installe SQL server sur un ordinateur serveur puissant est ce que sa peut résoudre le problème ?

Potentiellement oui. Mais j'ai quelques doutes malgré tout (cf. ci-après).

Concernant l'objectif , je vous explique l'utilité d'affiché tous ces données en temps réel, en fait cette application c'est un CRM dédié pour les centres d'appels, donc la tâche du superviseur et de contrôlé les téléopérateurs a partir de cette page qui lui affiche tout ce qui se passe avec les téléopérateurs depuis son poste de travail.

D'accord, donc le volume de données est faible, contrairement à ce que vous nous indiquiez plus haut. Du coup, je doute que le véritable problème soit une quantité de mémoire trop faible.

Le problème peut venir du fournisseur de données. OleDB est un fournisseur générique, reconnu pour ne pas être le plus performant. Si vous utilisez SQL Server, il vaut mieux utiliser le fournisseur adapté, c'est-à-dire SqlConnectino, SqlCommand, etc...

Sinon, comment est gérée la connexion au sein de votre application, qui est a priori un client lourd ? S'agit-il d'une seule connexion ouverte en permanence ? Ou s'agit-il d'une connexion ouverte à chaque fois que vous en avez besoin ?

[StringBuilder]

Ça pourrait aussi sentir la fuite mémoire cette histoire...

Quand vous chargez vos données, vous en faites quoi avant de les afficher ?

Détruisez-vous proprement les objets utilisés ?
Disposez-vous convenablement les objets non managés ?

Ça sent l'ouverture d'une nouvelle connexion à chaque Tick sans jamais fermer l'ancienne ça, ou l'ajout ad vitam æternam de données dans une List ou DataGrid sans jamais faire le ménage...

PS : Attention au rafraîchissement ! Je vois que vous affichez une liste. Si l'utilisateur sélectionne une ligne pour la mettre en valeur, à chaque Tick vous allez perdre sa sélection, ce qui peut passablement le gonfler !

[vanquish]

Détruisez-vous proprement les objets utilisés ?
Disposez-vous convenablement les objets non managés ?

Je me suis fait la même réflexion en voyant la création d'un obj command et reader ainsi dans le corps d'une fonction.
Le reader n'est probablement pas détruit (et si en interne la command garde une référence sur le reader - ce que j'ignore - il n'est pas détruit non plus).
Cela expliquerait tout à fait le débordement mémoire au bout d'un certain nombre d'itérations.

Ces deux objet devraient être sortie de cette fonction et créés dans une double instruction using.

[nyassouh]

Potentiellement oui. Mais j'ai quelques doutes malgré tout (cf. ci-après).



D'accord, donc le volume de données est faible, contrairement à ce que vous nous indiquiez plus haut. Du coup, je doute que le véritable problème soit une quantité de mémoire trop faible.

Bon avec une vingtaine de téléopérateurs connecté voir plus les données augmentent et donc sa devient un petit peut volumineux les données envoyer depuis le serveur.

Le problème peut venir du fournisseur de données. OleDB est un fournisseur générique, reconnu pour ne pas être le plus performant. Si vous utilisez SQL Server, il vaut mieux utiliser le fournisseur adapté, c'est-à-dire SqlConnectino, SqlCommand, etc...

D'accord, je vais essayé de changé le fournisseur de données et voir ce que ça donne.

Sinon, comment est gérée la connexion au sein de votre application, qui est a priori un client lourd ? S'agit-il d'une seule connexion ouverte en permanence ? Ou s'agit-il d'une connexion ouverte à chaque fois que vous en avez besoin ?

En effet, c'est une application client lourd et en ce qui concerne la connexion, elle est ouverte en permanence dés le lancement de l'application et puis fermé à la fermeture de l'application.
En fait, pendant mon dernier teste ça a l'aire de bien marché. J'ai utilisé l'application pendant plus d'une heure sans bug mais je ne sais pas si ça va durée c'est pour cela je cherche une solution durable et je vous remercie pour votre attention et pour touts vos conseils.

[nyassouh]

Ça pourrait aussi sentir la fuite mémoire cette histoire...

Quand vous chargez vos données, vous en faites quoi avant de les afficher ?

Détruisez-vous proprement les objets utilisés ?
Disposez-vous convenablement les objets non managés ?

Voici la méthode utilisé pour l'affichage des données dans le datagrid2 :

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
27
     public void Fill_list_ap()
        {
            try{
            int i = 0;
 
            dgv_et_ap.Rows.Clear();
            Selection ve = new Selection();
            string aa = "connecté";
            OleDbDataReader rq = ve.simple_select("select  * from statistiques where etat_appli = '"+aa+"' ");
 
            while (rq.Read())
            {
                        dgv_et_ap.Rows.Add();                
                        dgv_et_ap[1, i].Value = rq["etat_ap"].ToString();
                        dgv_et_ap[2, i].Value = rq["duree_ap"].ToString();
                        dgv_et_ap[3, i].Value = rq["nbr_ap"].ToString();
                        i++;
            }
            }
            catch (Exception)
            {
                connection cn = new connection();
                cn.closeConnection();
                cn.OpenConnection();
            }
 
        }

Ça sent l'ouverture d'une nouvelle connexion à chaque Tick sans jamais fermer l'ancienne ça, ou l'ajout ad vitam æternam de données dans une List ou DataGrid sans jamais faire le ménage...

PS : Attention au rafraîchissement ! Je vois que vous affichez une liste. Si l'utilisateur sélectionne une ligne pour la mettre en valeur, à chaque Tick vous allez perdre sa sélection, ce qui peut passablement le gonfler !

La connexion est ouverte à l'ouverture de l'application et puis fermé à la fermeture de l'app.
En ce qui concerne le rafraîchissement vous avez raison mais ce n'est pas la le problème et puis si vous avez une autre solution qui permet d'affiché des données qui varient chaque seconde sans utilisé un timer_tick sa sera la bienvenue.
Si vous pouvez aussi me donnée un petit exemple de ménage qui permet d'allégé l'utilisation de la mémoire ca sera très gentil et je vous remercie beaucoup pour ton effort.

[nyassouh]

Je me suis fait la même réflexion en voyant la création d'un obj command et reader ainsi dans le corps d'une fonction.
Le reader n'est probablement pas détruit (et si en interne la command garde une référence sur le reader - ce que j'ignore - il n'est pas détruit non plus).
Cela expliquerait tout à fait le débordement mémoire au bout d'un certain nombre d'itérations.

Ces deux objet devraient être sortie de cette fonction et créés dans une double instruction using.

Bonsoir vanquish,
Est ce que vous pouvez me donné un exemple et merci d'avance.

[vanquish]

Bonsoir vanquish,
Est ce que vous pouvez me donné un exemple et merci d'avance.

Je n'utilise jamais OleDb, ne ne garantit pas l'exactitude du code ci-dessous à 100%, mais le principe est du style :

Code :

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

1
2
3
4
5
6
7
8
9
10
using( var cd = new OleDbCommand( req, connection.Cn ) )
{
	using ( var r = cd.ExecuteReader() )
	{
		while (r.Read())
		{
			// -- votre code
		}
	}
}

La sortie du using, va faire le ménage dans tout ce qui n'est pas du code managé (les connecteurs à la base de donnée), avant même que le ramasse miette de .Net fasse le ménage dans sa propre gestion mémoire.
Ca va fermer tout ce qui doit l'être : l'absence du r.Close() dans mon code n'est pas très rigoureuse, mais ne va pas gêner.
Si une exception survient, là aussi tout sera nettoyé proprement.

Je ne dis pas que c'est forcement la cause du problème, mais je mettrais un facilement un billet là dessus.
Il est faux de penser que .Net interdit les fuites mémoires.
Parfois le framework, les contrôles ou une construction de notre code, peuvent garder une référence sur un objet qui pour nous n'est plus référencé.

[François DORIN]

Code :

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

1
2
3
4
5
6
             catch (Exception)
            {
                connection cn = new connection();
                cn.closeConnection();
                cn.OpenConnection();
            }

Ouch, bobo les yeux. Dans le genre inutile à souhait, je pense qu'il n'y a pas beaucoup mieux. Il ne sert à rien de créer une nouvelle connexion, de l'ouvrir, puis de la fermer. Autant supprimer ces lignes (et du coup le try aussi qui n'a plus de sens sans le catch).

Bon avec une vingtaine de téléopérateurs connecté voir plus les données augmentent et donc sa devient un petit peut volumineux les données envoyer depuis le serveur.

Pour tout SGBD, cette volumétrie est très faible. Je doute donc que les problèmes rencontrés viennent de là.

Code :

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

1
2
3
4
5
6
7
8
9
10
using( var cd = new OleDbCommand( req, connection.Cn ) )
{
	using ( var r = cd.ExecuteReader() )
	{
		while (r.Read())
		{
			// -- votre code
		}
	}
}

Je me permets de donner une réécriture syntaxique ici, pour des raisons de clarté :

Code :

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

1
2
3
4
5
6
7
8
using( var cd = new OleDbCommand( req, connection.Cn ) )
using ( var r = cd.ExecuteReader() )
{
	while (r.Read())
	{
		// -- votre code
	}
}

car le second using est en lui-même un bloc de code, il est inutile d'utiliser des accolades pour le premier using. 2 lignes et de l'indentation en moins.

Il est faux de penser que .Net interdit les fuites mémoires.
Parfois le framework, les contrôles ou une construction de notre code, peuvent garder une référence sur un objet qui pour nous n'est plus référencé.

Il est faux de penser le contraire. Par conception, il n'y a pas de fuite de mémoire au sein d'un programme .Net, et plus généralement, au sein d'un langage avec un bon ramasse-miette.
Si un objet est toujours référencé, c'est qu'il est potentiellement toujours utilisable. Avec une fuite de mémoire, par définition, la mémoire non libérée est perdue définitivement (enfin durant la durée de vie du programme).

Par contre, il peut y avoir une consommation croissante de mémoire due à un manque de libération des objets. Et vanquish à tout à fait raison sur ce point, ce manque de libération peut être tout à fait subtile.

Enfin, pour en revenir au problème initial, je pense qu'effectivement l'utilisation des using permettra de résoudre le soucis. Le problème de mémoire rencontré n'est pas au sein du code managé a priori (il suffit de regarder la consommation mémoire de la capture d'écran pour s'en rendre compte, 230Mo, ce n'est pas excessif). Je pense que le problème de mémoire se situe dans du code natif, car les ressources ne sont pas libérées correctement. Utiliser des clauses using permettra une libération correcte des ressources non managées.

[vanquish]

Si un objet est toujours référencé, c'est qu'il est potentiellement toujours utilisable.

Je vous rejoint sur un fait : au final, le ramasse-miette de .Net est un sale con qui a toujours raison.
Mais on trouve les termes "memory leak" dans la documentation de .Net elle même.
(https://msdn.microsoft.com/en-us/library/dn342825.aspx - les 3 premiers mots)

Votre définition n'est donc pas universelle.
D'ailleurs, si on entre ".Net memory leak" dans Google, on trouve 2 ou 3 résultats quand même (dont certains sont hyper-instructif).

Ce qui est à retenir, c'est que la présence du ramasse miette n'est pas une raison pour ne pas se soucier du tout de la libération mémoire.
Je ne pense pas que vous donneriez le conseil contraire.

Cordialement

[François DORIN]

Votre définition n'est donc pas universelle.

Tout d'abord, je n'ai jamais prétendu le contraire Ensuite, ce n'est pas ma définition, mais une définition "historique". Et j'insiste bien sur le "une" car il y en a effectivement plusieurs. Par extension, aujourd'hui, on peut parler de fuite de mémoire lors d'une consommation excessive de mémoire. Mais cette consommation peut avoir plusieurs cause :

• absence de désallocation mémoire;
• libération tardive d'objet (que l'on peut retrouver sous le nom de space leak (que je me garderais bien de traduire) ;
• gestion inefficiente de la mémoire.

Un ramasse-miette protège de la première cause, pas des autres.

Ce qui est à retenir, c'est que la présence du ramasse miette n'est pas une raison pour ne pas se soucier du tout de la libération mémoire.
Je ne pense pas que vous donneriez le conseil contraire.

Oui et non.

Je donne le conseil contraire dans le sens où la présence d'un ramasse-miette permet de ne pas se soucier de la libération de la mémoire (en fait, en .Net en tout cas, on ne peut pas gérer manuellement la libération de la mémoire). Par contre, la présence d'un ramasse-miette n'est pas une raison pour ne pas se soucier de la libération des objets. Si la différence peut paraître subtile, il ne faut pas oublier qu'un objet requiert de la mémoire, mais parfois d'autres ressources (connexion réseau, descripteur de fichiers, sémaphore, etc...).