J'ai une application qui contient actuellement 10 fenêtres différentes
qui utilisent chacune 7 tables (les mêmes d'une fenêtre à l'autre).
Les 7 tables sont dans un DataSet.
Il y a 7 DbDataAdapter dans chaque fenêtre (1 pour chaques tables)
Ces fenêtres demandent à l'utilisateur de saisir des valeurs et met à
jour automatiquement les tables.
Etant donné que je ne fais pas de Fill() du DataSet, la première fois
que je fais Update(), le DbDataAdapter execute une instruction pour
demander à SQL Server de renvoyer le schéma de la table :
SET FMTONLY OFF; SET NO_BROWSETABLE ON; SET FMTONLY ON;SELECT * FROM
MaTable SET FMTONLY OFF; SET NO_BROWSETABLE OFF;
Si je ne dis pas de bétise, le DbDataAdapter récupère le schéma afin
d'obtenir les informations nécessaires au mapping.
Comme les utilisateurs saisissent des valeurs dans une fenetre et la
ferme après chaque validation le DbDataAdapter et crée et détruit à
chaque ouverture/fermeture de la fenêtre.
Sur une application de 50 utilisateurs, ca fait un peu de trafic
réseau...
Les 2 questions que je me pose :
- Est ce que l'on peut définir manuellement le mapping du DbDataAdapter
afin que celui-ci ne demande plus à SQL Server le schéma de la table ?
- Est-ce conseillé (dans mon cas) de créer un DbDataAdapter commun à
l'application qui est créer à l'ouverture de l'application et détruit à
la fermeture de l'application ?
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
Paul Bacelar
Si vous cherchez de la monter en charge, pensez à utiliser des procédures stockées.
Question 1:
L'utilisation de DataSet typés devrait alléger le trafic mais surtout fiabiliser l'application, avec un peu de chance cela annulera la récupération du schéma.
Mais de mémoire un DataSet typés permet de ne plus récupérer le schéma.
Question 2:
Je ne vois pas de contre-indication sauf le fait qu'il faut synchroniser l'utilisation de l'objet entre les différents threads de l'application, et penser à libérer le plus rapidement possible les objets comme les commands ou les transactions. Mais je ne suis pas sur que cela empêchera la récupération du schéma. -- Paul Bacelar MVP VC++
"Gilles TOURREAU" wrote in message news:
Salut tout le monde !
J'ai une application qui contient actuellement 10 fenêtres différentes qui utilisent chacune 7 tables (les mêmes d'une fenêtre à l'autre). Les 7 tables sont dans un DataSet. Il y a 7 DbDataAdapter dans chaque fenêtre (1 pour chaques tables)
Ces fenêtres demandent à l'utilisateur de saisir des valeurs et met à jour automatiquement les tables.
Etant donné que je ne fais pas de Fill() du DataSet, la première fois que je fais Update(), le DbDataAdapter execute une instruction pour demander à SQL Server de renvoyer le schéma de la table :
SET FMTONLY OFF; SET NO_BROWSETABLE ON; SET FMTONLY ON;SELECT * FROM MaTable SET FMTONLY OFF; SET NO_BROWSETABLE OFF;
Si je ne dis pas de bétise, le DbDataAdapter récupère le schéma afin d'obtenir les informations nécessaires au mapping.
Comme les utilisateurs saisissent des valeurs dans une fenetre et la ferme après chaque validation le DbDataAdapter et crée et détruit à chaque ouverture/fermeture de la fenêtre.
Sur une application de 50 utilisateurs, ca fait un peu de trafic réseau...
Les 2 questions que je me pose :
- Est ce que l'on peut définir manuellement le mapping du DbDataAdapter afin que celui-ci ne demande plus à SQL Server le schéma de la table ?
- Est-ce conseillé (dans mon cas) de créer un DbDataAdapter commun à l'application qui est créer à l'ouverture de l'application et détruit à la fermeture de l'application ?
En vous remerciant par avance de vos lumières...
Cordialement
-- Gilles TOURREAU Responsable informatique
Société P.O.S Spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr
Si vous cherchez de la monter en charge, pensez à utiliser des procédures
stockées.
Question 1:
L'utilisation de DataSet typés devrait alléger le trafic mais surtout
fiabiliser l'application, avec un peu de chance cela annulera la
récupération du schéma.
Mais de mémoire un DataSet typés permet de ne plus récupérer le schéma.
Question 2:
Je ne vois pas de contre-indication sauf le fait qu'il faut synchroniser
l'utilisation de l'objet entre les différents threads de l'application, et
penser à libérer le plus rapidement possible les objets comme les commands
ou les transactions. Mais je ne suis pas sur que cela empêchera la
récupération du schéma.
--
Paul Bacelar
MVP VC++
"Gilles TOURREAU" <gilles.tourreau@pos.fr> wrote in message
news:mn.ec3e7d67359928d3.52180@pos.fr...
Salut tout le monde !
J'ai une application qui contient actuellement 10 fenêtres différentes qui
utilisent chacune 7 tables (les mêmes d'une fenêtre à l'autre).
Les 7 tables sont dans un DataSet.
Il y a 7 DbDataAdapter dans chaque fenêtre (1 pour chaques tables)
Ces fenêtres demandent à l'utilisateur de saisir des valeurs et met à jour
automatiquement les tables.
Etant donné que je ne fais pas de Fill() du DataSet, la première fois que
je fais Update(), le DbDataAdapter execute une instruction pour demander à
SQL Server de renvoyer le schéma de la table :
SET FMTONLY OFF; SET NO_BROWSETABLE ON; SET FMTONLY ON;SELECT * FROM
MaTable SET FMTONLY OFF; SET NO_BROWSETABLE OFF;
Si je ne dis pas de bétise, le DbDataAdapter récupère le schéma afin
d'obtenir les informations nécessaires au mapping.
Comme les utilisateurs saisissent des valeurs dans une fenetre et la ferme
après chaque validation le DbDataAdapter et crée et détruit à chaque
ouverture/fermeture de la fenêtre.
Sur une application de 50 utilisateurs, ca fait un peu de trafic réseau...
Les 2 questions que je me pose :
- Est ce que l'on peut définir manuellement le mapping du DbDataAdapter
afin que celui-ci ne demande plus à SQL Server le schéma de la table ?
- Est-ce conseillé (dans mon cas) de créer un DbDataAdapter commun à
l'application qui est créer à l'ouverture de l'application et détruit à la
fermeture de l'application ?
Si vous cherchez de la monter en charge, pensez à utiliser des procédures stockées.
Question 1:
L'utilisation de DataSet typés devrait alléger le trafic mais surtout fiabiliser l'application, avec un peu de chance cela annulera la récupération du schéma.
Mais de mémoire un DataSet typés permet de ne plus récupérer le schéma.
Question 2:
Je ne vois pas de contre-indication sauf le fait qu'il faut synchroniser l'utilisation de l'objet entre les différents threads de l'application, et penser à libérer le plus rapidement possible les objets comme les commands ou les transactions. Mais je ne suis pas sur que cela empêchera la récupération du schéma. -- Paul Bacelar MVP VC++
"Gilles TOURREAU" wrote in message news:
Salut tout le monde !
J'ai une application qui contient actuellement 10 fenêtres différentes qui utilisent chacune 7 tables (les mêmes d'une fenêtre à l'autre). Les 7 tables sont dans un DataSet. Il y a 7 DbDataAdapter dans chaque fenêtre (1 pour chaques tables)
Ces fenêtres demandent à l'utilisateur de saisir des valeurs et met à jour automatiquement les tables.
Etant donné que je ne fais pas de Fill() du DataSet, la première fois que je fais Update(), le DbDataAdapter execute une instruction pour demander à SQL Server de renvoyer le schéma de la table :
SET FMTONLY OFF; SET NO_BROWSETABLE ON; SET FMTONLY ON;SELECT * FROM MaTable SET FMTONLY OFF; SET NO_BROWSETABLE OFF;
Si je ne dis pas de bétise, le DbDataAdapter récupère le schéma afin d'obtenir les informations nécessaires au mapping.
Comme les utilisateurs saisissent des valeurs dans une fenetre et la ferme après chaque validation le DbDataAdapter et crée et détruit à chaque ouverture/fermeture de la fenêtre.
Sur une application de 50 utilisateurs, ca fait un peu de trafic réseau...
Les 2 questions que je me pose :
- Est ce que l'on peut définir manuellement le mapping du DbDataAdapter afin que celui-ci ne demande plus à SQL Server le schéma de la table ?
- Est-ce conseillé (dans mon cas) de créer un DbDataAdapter commun à l'application qui est créer à l'ouverture de l'application et détruit à la fermeture de l'application ?
En vous remerciant par avance de vos lumières...
Cordialement
-- Gilles TOURREAU Responsable informatique
Société P.O.S Spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr
