Discussion :

[bluevelvet]

Avec quel type de curseur ai-je un cache. Par exemple avec clUSeClient + ctKeyset et ltBatchOptimistic. Y-a-t-il d'autre combinaison.
Si j'ai bien compris avec un curseur côté serveur, je reçois dans mon process un cache dont le nombre d'enregistrement varie en fonction du cache size.
Dans ce cas mon cache correspond à mon recordset côté client.
En fait je suis un peu dans le brouillard avec le recordset et le cache. Est-ce que tous deux me donnent accès aux méthodes ADO.
J'ai lu qq part qu'il n'est pas conseillé d'utiliser les méthodes du recordset et qu'il valait mieux utiliser les méthodes du dataset.
Bref si on pouvait un peu m'éclairer sur la différence entre le recordset et le cache et quand utiliser les méthodes ADO où celles du dataset.

[bidou]

Il y a toujours un cache, mais le réglage de sa taille ne sert que pour les curseurs serveurs.

[bluevelvet]

Tout d'abord merci à toi de répondre à mes questions.
Si on a toujours un cache, les données affichées dans un dbgrid par exemple proviennent du cache ou du recordset avec un cureur client ou alors le cache ne sert que du côté serveur.

[bidou]

C'est très difficile de répondre d'emblée.
La taille du cache correspond au nombre d'enregistrements présent dans le cache (mais ca tu t'en doutais ).
Globalement on peut dire que les enregistrements présent dans le cache sont la position actuelle + les caches enregistrements suivants.

Par exemple.
Je crée mon curseur et j'ouvre le recordset avec une taille de cache de 50.
Tant que je ne lis pas un enregistrement dont la position est égale à 51+, les enregistrements du cache ne change pas. Si d'un coup je lis la position 112; mon cache contiendra les enregistrements 112-162. Si je monte par contre enregistrement par enregistrements, il contiendra 100-150.
Sur un Datagrid, on essayes de régler la taille du cache sur le nombre de ligne visible.
Par expérience, je peux déjà te dire que ce genre d'optimisation sur un curseur client est souvent négligeable.

[bluevelvet]

Alors pour clôturer et profiter de tes excellentes connaissances, qu'en est-il de la mise à jour des données. Si mes données dans mon dbgrid proviennet du cache, quand j'ai modifié 1 ou pls valeurs et que je me positionne sur le 49e enregistrement, quand et comment sont mis à jour mes données dans mon cache et mon recordset et finalement dans ma table. Je sais que la méthode Post (qui par ailleurs est invoquée de manière implicite par des méthodes de positionnement du curseur) invoque en arrière plan une requête action UPDATE. Mais je ne vois pas très bien le cheminement depuis mon dbgrid jusque dans ma table pour la question de mise à jour.
Merci encore.
Ah oui encore une petite chose....

J'ai été surpris quand tu as dis qu'on avait toujours un cache car je pensais que celui-ci n'existait que dans certaines configurations du genre:

clUseClient + ctKeyset + ltBatchOptimistic
ou
clUseClient + ctStatic + ltBatchOptimistic

Ce qui permet de travailler en mise à jour groupée via :
UpdateBatch & CancelBatch + TAffectedRecords + TFilterGroup.

Je n'ose même pas imaginer si on initialise pas la cache et qu'on reste avec une taille de 1!

Bref cache or not to cache, that is the question
Merci d'éclairer ma lanterne à tout jamais sur ce point.

[bidou]

Commençons par la fin.
Quand je dis qu'il y a toujours un cache c'est que même les curseurs en avant seulement ont un cache de 1.
Le réglage de la taille du cache est un problème qui ne suit pas d'autres règles que de faire des tests selon les applications.

Tu confonds Cache et recordset coté client.
Supposes que mon cache ait une taille de 10 et que je rapatrie 1000 enregistrements. Si je fais appel au recordcount mon cache contiendra les 10 derniers enregistrements. Mon Recordset client lui contiendra bien les 1000. Ce n'est pas le cache qui permet de travailler par lot, c'est le moteur de curseur client.

Pour la mise à jour tout dépend de la nature du curseur.
Prenons le cas d’une mise à jour directe.
Soit la modification est transmise lors d’un appel explicite de la méthode post, soit l’action est engendrée par un mouvement du curseur. Que la donnée proviennent du cache (mise à jour directe) ou non (mise à jour par lot) la méthode de mise à jour dépendra ensuite du coté du curseur.

Je te conseille de lire http://bidou.developpez.com/tutoriels/Delphi/ADO/
pour mieux comprendre le fonctionnement