je voudrais savoir si access garde en memoire les precedentes requetes qui ont ete faite ainsi que les resultats de ces requetes.
 
si oui, comment le forcer a ne pas utiliser cette memoire cache?
en d'autre terme, j'utilise une base de données access avec ADO sous visual c++ et quand j'ajoute un element puis que je fais une requete pour recuperer tous les element de ma base, ma base me renvoie des elements obsoletes, si je fais une deuxieme fois l'operation, la base me renvoie les bonnes valeurs ..
 
si qq un à une solution je suis preneur ..
merci d'avance

up

une requete est conservée afin de pouvoir
la réexécuter rapidement
 
mais si les données changent, le résultat de la requête doit changer
 
est-tu sur d'avoir fait un Commit après ta mise à jour?

c koi cette instruction ....??

Salut !
une idée en passant... t'as vérifié la valeur du paramètre autocommit dans le profil de conenxion à ta base ?

voici comment je me connecte :
 
HRESULT CConnectID::ConnectToDB(CString Path)
{
 // Chaine de Connexion
 HRESULT Result;
 CString tmp;
 tmp = IDS_STRCONNECTION;
 str_Connection.Format("%s%s%s" ,tmp
         ,Path
         ,";" );
 // -----------------------------
 // Tentative de connexion
 try{
  // Connection à la source de données
  Result = pConn->Open( _bstr_t(str_Connection),"","",NULL);
 }
 // -----------------------------
 // Traitement des erreurs
 catch(_com_error &err){
  // Affichage du message d' erreur
  CATCH_COM_ERROR(err);
 }
 return Result;
}

il me manque une methode à un endroit precis ???

 
 
On dirait que tu connais pas les transactions, & il semble que ton pb soit un pb de transaction...
Une transaction, c'est une unité de mise à jour dans la base. Elle commence par une instruction du type

Les maj sont validées par une commande  

ou annulée par une commande

.
 
L'idée est qu'il y a une situation avant maj, une situation après, mais pas d'état intermédiaire, et ce pour tous les utilisateurs de la base.
 
Donc, situation :
1. tu fais un update quelconque ds la base
2. tu refais un select & tu obtiens les données avant mise à jour.
 
Première possiblité : tu relis pas, ou bien tu relis & tu affiches pas les bonnes données ; à vérifier dans ton code C ; peu probable.
 
Seconde possibilité : tu as pas terminé de transaction après ton update & tu es à un niveau de transaction 2 ou 3 : tant que ta transaction est pas terminée, tu relis les données non modifiées.
Dans ce cas, il te faut valider une transaction par un commit après ton update (le + probable) ; si tu gères déjà tes transactions & que tu as toujours le problème, il se peut que dans les paramètres de connexion à ta base, tu aies un autocommit à false. Si autocommit est à false, un commit explicite doit être effectué pour valider les majs (- probable).
 
Mais avant tout, pour que ton appli tienne la route, il te faut définir tes unités de maj, & donc tes transactions...

okk .. merci .. je crois bien que le probleme vient de la (seconde possibilité)
 
qqu'un aurait il un bout de code à me montrer sur ce type de transaction ??
 
merci d'avance

Ben, la syntaxe dépend de ton sgbd...
Exemple sur sybase sql server :

 
En annexe, les notes que j'ai compilées concernant les transaction et les niveaux d'isolement (isolation level) :
   
Les niveaux d’isolement ANSI
Le standard ANSI SQl92 définit quatre niveaux d’isolement pour les transactions. Chacun de ces niveaux établit la liste des actions qui ne sont pas permises durant des transactions concurrentes. Chaque niveau inclut les restrictions des niveaux précédents :
 - Le niveau 0 permet a lecture de données modifiées. Il empêche que d’autres transactions ne changent des données qui ont déjà été modifiées par une transaction non encore terminée : les autres transactions sont bloquées tant que dure la transaction. Ces autres transactions peuvent cependant toujours lire les données, ce qui provoque des lectures sales (dirty reads).
 - Le niveau 1 empêche les lectures sales. De telles lectures se produisent lorsqu’une transaction modifie une ligne, puis qu’une seconde transaction lit cette ligne avant que la première transaction n’ait validé ses modifications. Si la première transaction est annulée, la donnée lue par la seconde transaction n’est plus correcte. Le niveau 1 garantit qu’une valeur lue à un instant donné dans une transaction est une valeur réelle qui ne peut être annulée.
 - Le niveau 2 empêche les lectures non répétables. De telles lectures se produisent lorsqu’une transaction lit une ligne et qu’une seconde transaction modifie cette ligne. Si la seconde transaction est validée, les lectures effectuées par la première transaction après cette validation donnent un résultat différents de celui de la lecture initiale. Le niveau 2 garantit que deux lectures de la même ligne au sein d’une transaction renvoient les mêmes données.
- Le niveau 3 empêche les lignes fantômes. Les fantômes se produisent lorsqu’une transaction lit un ensemble de lignes répondant à un critère de sélection, puis qu’une seconde transaction modifie les données. Si la première transaction réitère la lecture avec les mêmes critères, elle obtient un ensemble de lignes différent du premier. Le niveau 3 garantit que deux lectures d’un ensemble de lignes avec un critère de sélection au sein d’une transactions renvoient les mêmes ensembles de lignes.

Quelques précisions supplémentaires :
 
Le niveau d'isolement par défaut de ton sgbd est normalement un paramètre fourni lors de la connexion.
Il doit exister un niveau d'isolement par défaut, & un niveau d'isolement associé aux instructions

.

ok merci je regarde ca
merci de ton aide ... je te tiens au courant

up
 
j'ai encore besoin d'aide
il me faudrait un bout de code pour la connexion avec ADO sous VC++ ..