Il est d'usage de dire quand on utilise un DataReader, puis d'exécuter la
commande ExecuteReader pour obtenir les données à partir d'une requette sql
ne comsomme pas de mémoire car a chaque read du DataReader la requette nous
retourne une ligne.
Je ne suis pas du tout d'accord avec cette affirmation.
En effet selon la taille de la table ma procedure tombe sur l'erreur out of
memory !!!
(La requette sql ne fait pas de sélection on retourne toute la table)
Je précise je suis un petit périphérique sous win ce 4.2 et framework .net
1.1, db sqlce 2.0 et128 meg de ram
Peut être que je devrais mettre des sélections ds la requette, les
performances vont sérieusement en patir.
Au lieu de lire tout le fichier on va lire ligne à ligne clause where
id_record = N compteur ?? , le read du reader va forcément avoir un seule
ligne ?
Quelqu un a t il une autre méthode ?
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
Patrice
Bjr,
Le reader utilise effectivement un buffer donc pour moi on ne devrait effectivement pas avoir ce comportement. Après difficile d'en dire plus sans savoir ce qui est fait (bien sûr si les lignes ne sont pas traitées puis abandonnées mais stockées qq part l'utilisation d'un DataReader ne va pas magiquement réduire les besoins des autres structures de données à néant).
Le fait d'envisager l'ajout d'une sélection me laisse penser que les lignes lues sont bien stockées et non pas traitées à la volée puis oubliées. Cela me parait aussi généralement sain de ne récupérer que ce qui est utile à un moment donné.
-- Patrice
"Korben" a écrit dans le message de groupe de discussion : hq9uct$hkp$
Bonjour
Il est d'usage de dire quand on utilise un DataReader, puis d'exécuter la commande ExecuteReader pour obtenir les données à partir d'une requette sql ne comsomme pas de mémoire car a chaque read du DataReader la requette nous retourne une ligne. Je ne suis pas du tout d'accord avec cette affirmation. En effet selon la taille de la table ma procedure tombe sur l'erreur out of memory !!! (La requette sql ne fait pas de sélection on retourne toute la table) Je précise je suis un petit périphérique sous win ce 4.2 et framework .net 1.1, db sqlce 2.0 et128 meg de ram Peut être que je devrais mettre des sélections ds la requette, les performances vont sérieusement en patir. Au lieu de lire tout le fichier on va lire ligne à ligne clause where id_record = N compteur ?? , le read du reader va forcément avoir un seule ligne ? Quelqu un a t il une autre méthode ?
Bjr,
Le reader utilise effectivement un buffer donc pour moi on ne devrait
effectivement pas avoir ce comportement. Après difficile d'en dire plus sans
savoir ce qui est fait (bien sûr si les lignes ne sont pas traitées puis
abandonnées mais stockées qq part l'utilisation d'un DataReader ne va pas
magiquement réduire les besoins des autres structures de données à néant).
Le fait d'envisager l'ajout d'une sélection me laisse penser que les lignes
lues sont bien stockées et non pas traitées à la volée puis oubliées. Cela
me parait aussi généralement sain de ne récupérer que ce qui est utile à un
moment donné.
--
Patrice
"Korben" <KorbenDallas75@yahoo.fr> a écrit dans le message de groupe de
discussion : hq9uct$hkp$1@s1.news.oleane.net...
Bonjour
Il est d'usage de dire quand on utilise un DataReader, puis d'exécuter la
commande ExecuteReader pour obtenir les données à partir d'une requette
sql ne comsomme pas de mémoire car a chaque read du DataReader la requette
nous retourne une ligne.
Je ne suis pas du tout d'accord avec cette affirmation.
En effet selon la taille de la table ma procedure tombe sur l'erreur out
of memory !!!
(La requette sql ne fait pas de sélection on retourne toute la table)
Je précise je suis un petit périphérique sous win ce 4.2 et framework .net
1.1, db sqlce 2.0 et128 meg de ram
Peut être que je devrais mettre des sélections ds la requette, les
performances vont sérieusement en patir.
Au lieu de lire tout le fichier on va lire ligne à ligne clause where
id_record = N compteur ?? , le read du reader va forcément avoir un seule
ligne ?
Quelqu un a t il une autre méthode ?
Le reader utilise effectivement un buffer donc pour moi on ne devrait effectivement pas avoir ce comportement. Après difficile d'en dire plus sans savoir ce qui est fait (bien sûr si les lignes ne sont pas traitées puis abandonnées mais stockées qq part l'utilisation d'un DataReader ne va pas magiquement réduire les besoins des autres structures de données à néant).
Le fait d'envisager l'ajout d'une sélection me laisse penser que les lignes lues sont bien stockées et non pas traitées à la volée puis oubliées. Cela me parait aussi généralement sain de ne récupérer que ce qui est utile à un moment donné.
-- Patrice
"Korben" a écrit dans le message de groupe de discussion : hq9uct$hkp$
Bonjour
Il est d'usage de dire quand on utilise un DataReader, puis d'exécuter la commande ExecuteReader pour obtenir les données à partir d'une requette sql ne comsomme pas de mémoire car a chaque read du DataReader la requette nous retourne une ligne. Je ne suis pas du tout d'accord avec cette affirmation. En effet selon la taille de la table ma procedure tombe sur l'erreur out of memory !!! (La requette sql ne fait pas de sélection on retourne toute la table) Je précise je suis un petit périphérique sous win ce 4.2 et framework .net 1.1, db sqlce 2.0 et128 meg de ram Peut être que je devrais mettre des sélections ds la requette, les performances vont sérieusement en patir. Au lieu de lire tout le fichier on va lire ligne à ligne clause where id_record = N compteur ?? , le read du reader va forcément avoir un seule ligne ? Quelqu un a t il une autre méthode ?
Korben
Bonjour,
Effectivement j ai modifie la requette, j ai mis une selection pour ne lire qu une seule ligne a chaque read. La proc passe sans avoir un pb de mémoire, mais ca rame à mort !!! A mon avis a la requette sans selection à l execute reader il doit stocker les identifiants des lignes de la table pour pouvoir retrouver les lignes un à un à chaque read .
"Patrice" <http://scribe-fr.blogspot.com/> a écrit dans le message de news:
Bjr,
Le reader utilise effectivement un buffer donc pour moi on ne devrait effectivement pas avoir ce comportement. Après difficile d'en dire plus sans savoir ce qui est fait (bien sûr si les lignes ne sont pas traitées puis abandonnées mais stockées qq part l'utilisation d'un DataReader ne va pas magiquement réduire les besoins des autres structures de données à néant).
Le fait d'envisager l'ajout d'une sélection me laisse penser que les lignes lues sont bien stockées et non pas traitées à la volée puis oubliées. Cela me parait aussi généralement sain de ne récupérer que ce qui est utile à un moment donné.
-- Patrice
"Korben" a écrit dans le message de groupe de discussion : hq9uct$hkp$
Bonjour
Il est d'usage de dire quand on utilise un DataReader, puis d'exécuter la commande ExecuteReader pour obtenir les données à partir d'une requette sql ne comsomme pas de mémoire car a chaque read du DataReader la requette nous retourne une ligne. Je ne suis pas du tout d'accord avec cette affirmation. En effet selon la taille de la table ma procedure tombe sur l'erreur out of memory !!! (La requette sql ne fait pas de sélection on retourne toute la table) Je précise je suis un petit périphérique sous win ce 4.2 et framework .net 1.1, db sqlce 2.0 et128 meg de ram Peut être que je devrais mettre des sélections ds la requette, les performances vont sérieusement en patir. Au lieu de lire tout le fichier on va lire ligne à ligne clause where id_record = N compteur ?? , le read du reader va forcément avoir un seule ligne ? Quelqu un a t il une autre méthode ?
Bonjour,
Effectivement j ai modifie la requette, j ai mis une selection pour ne lire
qu une seule ligne a chaque read. La proc passe sans avoir un pb de mémoire,
mais ca rame à mort !!!
A mon avis a la requette sans selection à l execute reader il doit stocker
les identifiants des lignes de la table pour pouvoir retrouver les lignes un
à un à chaque read .
"Patrice" <http://scribe-fr.blogspot.com/> a écrit dans le message de news:
eXoiFLY3KHA.4964@TK2MSFTNGP05.phx.gbl...
Bjr,
Le reader utilise effectivement un buffer donc pour moi on ne devrait
effectivement pas avoir ce comportement. Après difficile d'en dire plus
sans savoir ce qui est fait (bien sûr si les lignes ne sont pas traitées
puis abandonnées mais stockées qq part l'utilisation d'un DataReader ne va
pas magiquement réduire les besoins des autres structures de données à
néant).
Le fait d'envisager l'ajout d'une sélection me laisse penser que les
lignes lues sont bien stockées et non pas traitées à la volée puis
oubliées. Cela me parait aussi généralement sain de ne récupérer que ce
qui est utile à un moment donné.
--
Patrice
"Korben" <KorbenDallas75@yahoo.fr> a écrit dans le message de groupe de
discussion : hq9uct$hkp$1@s1.news.oleane.net...
Bonjour
Il est d'usage de dire quand on utilise un DataReader, puis d'exécuter la
commande ExecuteReader pour obtenir les données à partir d'une requette
sql ne comsomme pas de mémoire car a chaque read du DataReader la
requette nous retourne une ligne.
Je ne suis pas du tout d'accord avec cette affirmation.
En effet selon la taille de la table ma procedure tombe sur l'erreur out
of memory !!!
(La requette sql ne fait pas de sélection on retourne toute la table)
Je précise je suis un petit périphérique sous win ce 4.2 et framework
.net 1.1, db sqlce 2.0 et128 meg de ram
Peut être que je devrais mettre des sélections ds la requette, les
performances vont sérieusement en patir.
Au lieu de lire tout le fichier on va lire ligne à ligne clause where
id_record = N compteur ?? , le read du reader va forcément avoir un seule
ligne ?
Quelqu un a t il une autre méthode ?
Effectivement j ai modifie la requette, j ai mis une selection pour ne lire qu une seule ligne a chaque read. La proc passe sans avoir un pb de mémoire, mais ca rame à mort !!! A mon avis a la requette sans selection à l execute reader il doit stocker les identifiants des lignes de la table pour pouvoir retrouver les lignes un à un à chaque read .
"Patrice" <http://scribe-fr.blogspot.com/> a écrit dans le message de news:
Bjr,
Le reader utilise effectivement un buffer donc pour moi on ne devrait effectivement pas avoir ce comportement. Après difficile d'en dire plus sans savoir ce qui est fait (bien sûr si les lignes ne sont pas traitées puis abandonnées mais stockées qq part l'utilisation d'un DataReader ne va pas magiquement réduire les besoins des autres structures de données à néant).
Le fait d'envisager l'ajout d'une sélection me laisse penser que les lignes lues sont bien stockées et non pas traitées à la volée puis oubliées. Cela me parait aussi généralement sain de ne récupérer que ce qui est utile à un moment donné.
-- Patrice
"Korben" a écrit dans le message de groupe de discussion : hq9uct$hkp$
Bonjour
Il est d'usage de dire quand on utilise un DataReader, puis d'exécuter la commande ExecuteReader pour obtenir les données à partir d'une requette sql ne comsomme pas de mémoire car a chaque read du DataReader la requette nous retourne une ligne. Je ne suis pas du tout d'accord avec cette affirmation. En effet selon la taille de la table ma procedure tombe sur l'erreur out of memory !!! (La requette sql ne fait pas de sélection on retourne toute la table) Je précise je suis un petit périphérique sous win ce 4.2 et framework .net 1.1, db sqlce 2.0 et128 meg de ram Peut être que je devrais mettre des sélections ds la requette, les performances vont sérieusement en patir. Au lieu de lire tout le fichier on va lire ligne à ligne clause where id_record = N compteur ?? , le read du reader va forcément avoir un seule ligne ? Quelqu un a t il une autre méthode ?
Patrice
Effectivement j ai modifie la requette, j ai mis une selection pour ne lire qu une seule ligne a chaque read. La proc passe sans avoir un pb de mémoire, mais ca rame à mort !!! A mon avis a la requette sans selection à l execute reader il doit stocker les identifiants des lignes de la table pour pouvoir retrouver les lignes un à un à chaque read .
Normalement le reader lit les lignes dans un buffer et le curseur étant uniquement "en avançant", il n'a besoin de rien stocker sur une ligne déjà lue...
Difficile d'en dire plus sans voir le code. Il faudrait réduire au minimum le code montrant le problème puis poster le résultat... Ou essayer par exemple une simple boucle qui ne fait QUE la lecture :
while (reader.Read);
Cette boucle ne devrait pas générer un out of memory même si toute la table est lue (sauf peut-être si une colonne "blob" est présente dans le select)...
-- Patrice
Effectivement j ai modifie la requette, j ai mis une selection pour ne
lire qu une seule ligne a chaque read. La proc passe sans avoir un pb de
mémoire, mais ca rame à mort !!!
A mon avis a la requette sans selection à l execute reader il doit stocker
les identifiants des lignes de la table pour pouvoir retrouver les lignes
un à un à chaque read .
Normalement le reader lit les lignes dans un buffer et le curseur étant
uniquement "en avançant", il n'a besoin de rien stocker sur une ligne déjà
lue...
Difficile d'en dire plus sans voir le code. Il faudrait réduire au minimum
le code montrant le problème puis poster le résultat... Ou essayer par
exemple une simple boucle qui ne fait QUE la lecture :
while (reader.Read);
Cette boucle ne devrait pas générer un out of memory même si toute la table
est lue (sauf peut-être si une colonne "blob" est présente dans le
select)...
Effectivement j ai modifie la requette, j ai mis une selection pour ne lire qu une seule ligne a chaque read. La proc passe sans avoir un pb de mémoire, mais ca rame à mort !!! A mon avis a la requette sans selection à l execute reader il doit stocker les identifiants des lignes de la table pour pouvoir retrouver les lignes un à un à chaque read .
Normalement le reader lit les lignes dans un buffer et le curseur étant uniquement "en avançant", il n'a besoin de rien stocker sur une ligne déjà lue...
Difficile d'en dire plus sans voir le code. Il faudrait réduire au minimum le code montrant le problème puis poster le résultat... Ou essayer par exemple une simple boucle qui ne fait QUE la lecture :
while (reader.Read);
Cette boucle ne devrait pas générer un out of memory même si toute la table est lue (sauf peut-être si une colonne "blob" est présente dans le select)...
