J'ai une application Access qui arrive à sa limite de confort d'utilisation
(41 tables ayant de 10-15 lignes à 30-35000 lignes sur 4 postes). je réécris
l'appli avec c#, MSDE et ADO.net et je ne comprend pas très bien
l'utilisation des datasets. Me faut-il un seul dataset fortement typé que je
charge à l'initialisation de l'appli ? ou un dataset par formulaire ? ou
un dataset avec des données semi-statiques pour l'application et des
datasets de données modifiées fréquement pour chaque formulaire ?
Si le dataset est un clone de la base de données, quel est l'intéret d'avoir
un gros serveur dédié si c'est chaque client qui se tape la résolution des
réquêtes (dans le cadre d'un base de données volumineuse bien-sûr) ?
Dans le cas d'un seul dataset, est-ce que la méthode .fill() des
dataadaptaters recharge l'intégralité des données, ou seulement les
données ajoutées/mises à jour/ effacées.
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
Lebrun Thomas
> Si le dataset est un clone de la base de données, quel est l'intéret
d'avoir
un gros serveur dédié si c'est chaque client qui se tape la résolution des réquêtes (dans le cadre d'un base de données volumineuse bien-sûr) ?
Le dataset n'est pas un clone de la base de donnée. Il contiet le contenu d'une requête SQL executée sur la base de données. Ce que tu ne dois pas oublier, c'est :1 dataset = source de données.
A+
-- LEBRUN Thomas http://morpheus.developpez.com
"Charles BERTIN" wrote in message news:ceij51$ie$
J'ai une application Access qui arrive à sa limite de confort
d'utilisation
(41 tables ayant de 10-15 lignes à 30-35000 lignes sur 4 postes). je
réécris
l'appli avec c#, MSDE et ADO.net et je ne comprend pas très bien l'utilisation des datasets. Me faut-il un seul dataset fortement typé que
je
charge à l'initialisation de l'appli ? ou un dataset par formulaire ? ou un dataset avec des données semi-statiques pour l'application et des datasets de données modifiées fréquement pour chaque formulaire ?
Si le dataset est un clone de la base de données, quel est l'intéret
d'avoir
un gros serveur dédié si c'est chaque client qui se tape la résolution des réquêtes (dans le cadre d'un base de données volumineuse bien-sûr) ?
Dans le cas d'un seul dataset, est-ce que la méthode .fill() des dataadaptaters recharge l'intégralité des données, ou seulement les données ajoutées/mises à jour/ effacées.
Merci de vos lumières
> Si le dataset est un clone de la base de données, quel est l'intéret
d'avoir
un gros serveur dédié si c'est chaque client qui se tape la résolution des
réquêtes (dans le cadre d'un base de données volumineuse bien-sûr) ?
Le dataset n'est pas un clone de la base de donnée. Il contiet le contenu
d'une requête SQL executée sur la base de données.
Ce que tu ne dois pas oublier, c'est :1 dataset = source de données.
A+
--
LEBRUN Thomas
http://morpheus.developpez.com
"Charles BERTIN" <cbertin@yahoo.com> wrote in message
news:ceij51$ie$1@news.tiscali.fr...
J'ai une application Access qui arrive à sa limite de confort
d'utilisation
(41 tables ayant de 10-15 lignes à 30-35000 lignes sur 4 postes). je
réécris
l'appli avec c#, MSDE et ADO.net et je ne comprend pas très bien
l'utilisation des datasets. Me faut-il un seul dataset fortement typé que
je
charge à l'initialisation de l'appli ? ou un dataset par formulaire ? ou
un dataset avec des données semi-statiques pour l'application et des
datasets de données modifiées fréquement pour chaque formulaire ?
Si le dataset est un clone de la base de données, quel est l'intéret
d'avoir
un gros serveur dédié si c'est chaque client qui se tape la résolution des
réquêtes (dans le cadre d'un base de données volumineuse bien-sûr) ?
Dans le cas d'un seul dataset, est-ce que la méthode .fill() des
dataadaptaters recharge l'intégralité des données, ou seulement les
données ajoutées/mises à jour/ effacées.
> Si le dataset est un clone de la base de données, quel est l'intéret
d'avoir
un gros serveur dédié si c'est chaque client qui se tape la résolution des réquêtes (dans le cadre d'un base de données volumineuse bien-sûr) ?
Le dataset n'est pas un clone de la base de donnée. Il contiet le contenu d'une requête SQL executée sur la base de données. Ce que tu ne dois pas oublier, c'est :1 dataset = source de données.
A+
-- LEBRUN Thomas http://morpheus.developpez.com
"Charles BERTIN" wrote in message news:ceij51$ie$
J'ai une application Access qui arrive à sa limite de confort
d'utilisation
(41 tables ayant de 10-15 lignes à 30-35000 lignes sur 4 postes). je
réécris
l'appli avec c#, MSDE et ADO.net et je ne comprend pas très bien l'utilisation des datasets. Me faut-il un seul dataset fortement typé que
je
charge à l'initialisation de l'appli ? ou un dataset par formulaire ? ou un dataset avec des données semi-statiques pour l'application et des datasets de données modifiées fréquement pour chaque formulaire ?
Si le dataset est un clone de la base de données, quel est l'intéret
d'avoir
un gros serveur dédié si c'est chaque client qui se tape la résolution des réquêtes (dans le cadre d'un base de données volumineuse bien-sûr) ?
Dans le cas d'un seul dataset, est-ce que la méthode .fill() des dataadaptaters recharge l'intégralité des données, ou seulement les données ajoutées/mises à jour/ effacées.
Merci de vos lumières
diggingbill
"Charles BERTIN" a écrit dans le message de news:ceij51$ie$
J'ai une application Access qui arrive à sa limite de confort
d'utilisation
(41 tables ayant de 10-15 lignes à 30-35000 lignes sur 4 postes). je
réécris
l'appli avec c#, MSDE et ADO.net et je ne comprend pas très bien l'utilisation des datasets. Me faut-il un seul dataset fortement typé que
je
charge à l'initialisation de l'appli ? ou un dataset par formulaire ? ou un dataset avec des données semi-statiques pour l'application et des datasets de données modifiées fréquement pour chaque formulaire ?
Pour faire dotNet, essaies ceci : 1- Ajoute un composant à ton projet, et dans ce composant tu y créé le fameux dataSet (typé !) avec TOUTES les tables de ta base. Pour chaque table, tu as un Adaptateur qui en est responsable éventuellement suivant une requête personnelle que tu écris sinon VS.NET te génère cela. 2- Dans chaque fenêtre tu instancies ton composant ; tu ajoutes un dataSet basé sur ton dataSet typé et tu appelles uniquement les méthodes qui concernent les tables manipulées par cette fenêtre. Tu verras c'est très simple (et plus long à expliquer !). De plus cette approche te centralise tous tes accès aux données.
Reportes-toi à l'aide de VS.NET, utilisation de composant, je n'ai pas dis n-tiers, juste l'utilisation d'un composant. C'est beaucoup plus simple qu'il n'y paraît, et crois moi j'ai galérer avant de tomber par hasard dessus un jour que je me suis décidé à consulter la documentation en ligne, voilà, voilà.
Si le dataset est un clone de la base de données, quel est l'intéret
d'avoir
un gros serveur dédié si c'est chaque client qui se tape la résolution des réquêtes (dans le cadre d'un base de données volumineuse bien-sûr) ?
C'est pas tout à fait exact. Quand tu auras pigé le truc que je t'explique ci-dessus, tu ne te poseras plus cette question. Il est souhaitable que tous les traitements soient exécuté par le moteur de base de données, il a été conçu pour ça ! Quand tu seras un peu plus armé, tu t'essayeras au SP que tu appelleras par exemple avec Data Access Application Bloc (toujours dans ton composant pour ne pas s'égarer).
Dans le cas d'un seul dataset, est-ce que la méthode .fill() des dataadaptaters recharge l'intégralité des données, ou seulement les données ajoutées/mises à jour/ effacées.
pour comprendre ce qui se passe, essaye ceci : créé un projet bidon at accepte tous les paramètres par défaut qu'il te propose. Puis ajoute un formulaire WinForm en mode fiche mais en faisant appel à l'ASSISTANT de VS.NET. Etudie le code qu''il a généré, en particulier le code des boutons, il est riche d'enseignements et répondra de manière claire à ta question.
Merci de vos lumières
En espérant t'avoir donné un chemin où chercher, d'ou mon pseudo "digging".
"Charles BERTIN" <cbertin@yahoo.com> a écrit dans le message de
news:ceij51$ie$1@news.tiscali.fr...
J'ai une application Access qui arrive à sa limite de confort
d'utilisation
(41 tables ayant de 10-15 lignes à 30-35000 lignes sur 4 postes). je
réécris
l'appli avec c#, MSDE et ADO.net et je ne comprend pas très bien
l'utilisation des datasets. Me faut-il un seul dataset fortement typé que
je
charge à l'initialisation de l'appli ? ou un dataset par formulaire ? ou
un dataset avec des données semi-statiques pour l'application et des
datasets de données modifiées fréquement pour chaque formulaire ?
Pour faire dotNet, essaies ceci :
1- Ajoute un composant à ton projet, et dans ce composant tu y créé le
fameux dataSet (typé !) avec TOUTES les tables de ta base. Pour chaque
table, tu as un Adaptateur qui en est responsable éventuellement suivant une
requête personnelle que tu écris sinon VS.NET te génère cela.
2- Dans chaque fenêtre tu instancies ton composant ; tu ajoutes un dataSet
basé sur ton dataSet typé et tu appelles uniquement les méthodes qui
concernent les tables manipulées par cette fenêtre. Tu verras c'est très
simple (et plus long à expliquer !).
De plus cette approche te centralise tous tes accès aux données.
Reportes-toi à l'aide de VS.NET, utilisation de composant, je n'ai pas dis
n-tiers, juste l'utilisation d'un composant. C'est beaucoup plus simple
qu'il n'y paraît, et crois moi j'ai galérer avant de tomber par hasard
dessus un jour que je me suis décidé à consulter la documentation en ligne,
voilà, voilà.
Si le dataset est un clone de la base de données, quel est l'intéret
d'avoir
un gros serveur dédié si c'est chaque client qui se tape la résolution des
réquêtes (dans le cadre d'un base de données volumineuse bien-sûr) ?
C'est pas tout à fait exact. Quand tu auras pigé le truc que je t'explique
ci-dessus, tu ne te poseras plus cette question. Il est souhaitable que tous
les traitements soient exécuté par le moteur de base de données, il a été
conçu pour ça ! Quand tu seras un peu plus armé, tu t'essayeras au SP que tu
appelleras par exemple avec Data Access Application Bloc (toujours dans ton
composant pour ne pas s'égarer).
Dans le cas d'un seul dataset, est-ce que la méthode .fill() des
dataadaptaters recharge l'intégralité des données, ou seulement les
données ajoutées/mises à jour/ effacées.
pour comprendre ce qui se passe, essaye ceci : créé un projet bidon at
accepte tous les paramètres par défaut qu'il te propose. Puis ajoute un
formulaire WinForm en mode fiche mais en faisant appel à l'ASSISTANT de
VS.NET. Etudie le code qu''il a généré, en particulier le code des boutons,
il est riche d'enseignements et répondra de manière claire à ta question.
Merci de vos lumières
En espérant t'avoir donné un chemin où chercher, d'ou mon pseudo "digging".
"Charles BERTIN" a écrit dans le message de news:ceij51$ie$
J'ai une application Access qui arrive à sa limite de confort
d'utilisation
(41 tables ayant de 10-15 lignes à 30-35000 lignes sur 4 postes). je
réécris
l'appli avec c#, MSDE et ADO.net et je ne comprend pas très bien l'utilisation des datasets. Me faut-il un seul dataset fortement typé que
je
charge à l'initialisation de l'appli ? ou un dataset par formulaire ? ou un dataset avec des données semi-statiques pour l'application et des datasets de données modifiées fréquement pour chaque formulaire ?
Pour faire dotNet, essaies ceci : 1- Ajoute un composant à ton projet, et dans ce composant tu y créé le fameux dataSet (typé !) avec TOUTES les tables de ta base. Pour chaque table, tu as un Adaptateur qui en est responsable éventuellement suivant une requête personnelle que tu écris sinon VS.NET te génère cela. 2- Dans chaque fenêtre tu instancies ton composant ; tu ajoutes un dataSet basé sur ton dataSet typé et tu appelles uniquement les méthodes qui concernent les tables manipulées par cette fenêtre. Tu verras c'est très simple (et plus long à expliquer !). De plus cette approche te centralise tous tes accès aux données.
Reportes-toi à l'aide de VS.NET, utilisation de composant, je n'ai pas dis n-tiers, juste l'utilisation d'un composant. C'est beaucoup plus simple qu'il n'y paraît, et crois moi j'ai galérer avant de tomber par hasard dessus un jour que je me suis décidé à consulter la documentation en ligne, voilà, voilà.
Si le dataset est un clone de la base de données, quel est l'intéret
d'avoir
un gros serveur dédié si c'est chaque client qui se tape la résolution des réquêtes (dans le cadre d'un base de données volumineuse bien-sûr) ?
C'est pas tout à fait exact. Quand tu auras pigé le truc que je t'explique ci-dessus, tu ne te poseras plus cette question. Il est souhaitable que tous les traitements soient exécuté par le moteur de base de données, il a été conçu pour ça ! Quand tu seras un peu plus armé, tu t'essayeras au SP que tu appelleras par exemple avec Data Access Application Bloc (toujours dans ton composant pour ne pas s'égarer).
Dans le cas d'un seul dataset, est-ce que la méthode .fill() des dataadaptaters recharge l'intégralité des données, ou seulement les données ajoutées/mises à jour/ effacées.
pour comprendre ce qui se passe, essaye ceci : créé un projet bidon at accepte tous les paramètres par défaut qu'il te propose. Puis ajoute un formulaire WinForm en mode fiche mais en faisant appel à l'ASSISTANT de VS.NET. Etudie le code qu''il a généré, en particulier le code des boutons, il est riche d'enseignements et répondra de manière claire à ta question.
Merci de vos lumières
En espérant t'avoir donné un chemin où chercher, d'ou mon pseudo "digging".
