Discussion :

[0redd]

Bonsoir
est t'il possible de combiner entre le mode connecté et déconnecté dans un meme projet? est-ce normal ? y'aurai t'il des bugs ou trucs du genre?
car d'après ce que j'ai compris, avec les dataset ,je peux rapidement mettre à jour les tables et supprimé .. , mais je ne peux pas écrire mes propres requetes sql ? ( et c là ou j'ai besoin de travaillé avec le mode connecté )
Merci

[cinemania]

encore un qui n'a mais absolument rien compris au mode connecté/déconnecté de dotnet.

Pour faire simple que tu utilise ou non les DataSet, dans tous les cas tu va manipuler des REQUETES SQL...

Que tu bosse en mode connecté ou déconnecté, tu t'adresse toujours à une base de données, tu as donc une connexion ouverte avec celle-ci, c'est la moindre des choses pour pouvoir lui transmettre une requête et obtenir un résultat... on a essayer la communication par le saint esprit avec les bases de données, mais les résultats ne sont pas encourageant... un peu de logique que diable...

Déconnecté ne signifie pas que tu ferme systématiquement la connexion et que tu cause pas à la base ... tu peux avoir une appli qui fonctionne en déconnecté et qui a une connexion à la base ouverte pendant tout son temps d'exécution.

je reconnais toutefois que les termes sont mal choisis... mais ca sera ni la première ni la dernière fois, donc autant s'y faire et essayer de rester logique.

Mode connecté : ce mode est le mode de fonctionnement des langages comme PHP... tu traite le résultat d'une requête pendant que la connexion est ouverte, cela sous-entend qu'a chaque fois que tu travail sur le résultat d'une requête il y a un trafic réseau entre toi et la base de données, notamment pour récupérer la ligne suivante.
On peut utiliser ce mode avec les DataReader. Il va être pratique d'utiliser ce mode pour contrôler soit même le fenêtrage des données lues par exemple. Avec ce modèle, la requete est généré par la base, et le résultat attend sagement sur la base que tu vienne le lire, ce que tu va faire entrée par entrée, et traiter cette entrée directement.

Mode déconnecté : Spécificité "inhérente" aux DataSet/DataTable, ce mode récupère les données en mode connectés, mais ne t'y donne accès que lorsque tout le résultat de la requête a été traité, une fois le résultat totalement récupéré et placé dans le DataSet, la requête ouverte et le résultat associé sont détruits au niveau de la base, mais la connexion à celle-ci n'est pas close.

Voilà la différence entre mode connecté/déconnecté... rien avoir avec la connexion TCP/IP ou named/pipe ouverte avec la base, mais plus avoir sur la façon dont on récupère les données d'une requête...
soit on récupère les données une par une et on les traite au fur et à mesure et on se doit à la fin du traitement de clore et libérer le résultat (reader) sur la base pour libérer les ressources ouvertes du coté de la base.
soit on considère que la mémoire du pc est faite pour être utilisé, et on laisse ADO.NET récupérer chaque ligne de résultat et les stocker dans un ensemble de tables en 2 dimensions (une ligne de cette table correspond à un enregistrement de résultat, et une colonne à un champ) et fermer/libérer proprement, ce qui a été ouvert pour récupérer les résultats.

Pour finir, il est tout à fait possible d'utiliser les deux mode de fonctionnement conjointement, mais le mode connecté à quelques inconvénients qu'il ne faut pas oublier lorsque l'on travail avec, comme le fait qu'il ne faut pas oublier qu'il ne peut y avoir plusieurs utilisations de datareader simultanées sur une même connexion... il faudra en ouvrir plusieurs (et donc penser à les clores également...)
Lorsqu'une requête comme un update ou insert ou exécution de procédure stockée n'attend pas de résultat elle est traitée naturellement hors de toute notion de connecté/déconnecté, qui encore une fois ne concerne que la façon de recouvrir les données.

[0redd]

Et pour une application qui est utilisé par 2 - 4 personnes dans un lan, c'est laquelle des méthodes qui serai la plus performantes?
Le fait de chargé les données dans la mémoire, ça ne rendrai pas l'application plus lourde?

[cinemania]

tout dépend de la volumétrie dont on parle ...

les machines actuellement on de la mémoire à revendre mais bon faut pas pousser mémé dans les orties non plus.
disons que si la volumétrie à remonter par ta requête excède 500mo il sera toujours temps de te dire qu'il vaudrait mieux procéder en connecté.

mais disons que si ta requête remonte 500mo de données, je serais toi je me demanderais si j'ai pas fait une faute conceptuelle quelque part

[0redd]

500 mo, c'est plus grand que la taille de la base de donnée toute entière ,
voilà mercii.

[sinople]

Il y a quand même 2 ou 3 trucs que tu oublies avec le modèle déconnectés.

Si la connection reste ouverte après l'utilisation de datareader pour peupler les datatables d'un dataset (ce dont je doute assez fortement mais soit...) Il faut savoir qu'il n'y a plus aucun traffic avec la base de donnée jusqu'à ce qu'une fonction mette à jour la base de donnée (Update) ou ton dataset (fill/merge).

C'est à dire que si tu ajoutes/modifie un enregistrement dans ton application et que tu appelles la fonction de mise à jour 1 heure plus tard. Les autres utilisateurs ne verront la modification que ...X (ou x est plus grand que 1) heures plus tard car il devront encore charger "manuellement" sur l'application les modifications.

Ceci fait qu'il peut y avoir un certains nombre de problème au niveau de la synchronisation des données qu'il faut prévoir de gérer !

Concernant l'explosion de la mémoire à cause de la copie de la base de donnée, il existe des mécanisme chargeant les données à mesure qu'on en a besoin.

Et sachant que plus une donnée dans le dataset est veille, plus elle est suceptible d'être fausse par rapport à la base de donnée. On comprend rapidement que de copier en local l'entier de la base de donnée n'est pas forcément la meilleur stratégie (bien que au début pour apprendre ADO.Net copier tout au chargement et renvoyer tout à la fermeture c'est acceptable).

Mais quand le système est utilisé par 5 utilisateurs en parallèle et qu'ils sauvegardent tous leur modifications à 17h avant de partir ça va pas le faire... (tu vas recevoir 4 coup de fill à 17h01 pour faire simple).

Au passage la comparaison avec PHP est tandancieuse car même si dans l'interne d'un script on est bien en mode connecté avec la base de donnée, le serveur et le client (navigateur web) ne reste pas connecté eux... (encore que moi en php je crée des objets à partir de la bd, puis modifie/utilise mes objet et finalement les sauvegardes dans la bd, j'appelle pas ça du connecté...) ce qui fait au final qu'on a les même problématiques de synchronisation entre ce qui est affiché à l'écran et sur la base de donnée.

Si tu veux comparer avec du vrai connecté regarde plutot la technologie DAO et ses fameux recordsets (c'est vieux mais encore utilisé pour des raisons historiques dans pas mal d'applications)

Après faut voir si ton application c'est du web (asp.net) ou du client lourd (vb, c#, etc.)...

[WOLO Laurent]

Bonsoir
est t'il possible de combiner entre le mode connecté et déconnecté dans un meme projet?

Oui

y'aurai t'il des bugs ou trucs du genre?

Non, pas de rapport avec les modes

car d'après ce que j'ai compris, avec les dataset ,je peux rapidement mettre à jour les tables et supprimé ..

Non, tu peux executer une requête et recevoir la réponse via un dataset (tu utilse un dataadapter) tout comme via un DataReader

mais je ne peux pas écrire mes propres requetes sql ? ( et c là ou j'ai besoin de travaillé avec le mode connecté )

Tu comprends vraiment que c'est faut.

[sinople]

Essaye quand même d'éviter un mix foireux de connecté // déconnecté qui consiste à charger un dataset puis à lancer des requête de mise à jour directement à la base de donnée puis plus tard des requêtes de mise à jour à partir du dataset...

[WOLO Laurent]

D'une manière générale, utilise :

Le mode connecté (cmd.ExecuteNonQuery, DataReader ...) pour travailler avec des données via des requêtes SQL directement et en maintenant la connexion ouverte pendant la durée de vie la plus courte possible. Ne manipulez pas directement les données pendant la lecture via DataReader.
Ce mode offre généralement les meilleurs performances.

Le mode déconnecté, pour ma part me sert à lire des données et à appliquer des traitements pour ensuite les afficher. sachant la connxion a déjà été restituée au pool de connexion.