Discussion :

[hocine]

Bonjour,
je développe une application sous Delphi7. J'utilise accessapplication pour accéder à une base et adoconnection pour une autre (cas spécial). Mon application marche très bien, seulement si mon application est ouverte et je souhaite ouvrir une base quelconque : cette dernière ne s'ouvre pas.
accessapplication1.connectkind:=ckNewInstance;
Merci.

[ShaiLeTroll]

Tu mélange un pilotage d'ACCESS en OLE et une connexion ADO, c'est étrange, je n'aurais choisi que l'ADO
Ta base de donnée est dans un fichier, il est toujours là où c'est ton programme qui le stocke en ressource, l'extrait, le modifie et le réintègre en ressource comme une fausse base embarquée ?

[hocine]

merci ShaiLeTroll ,
voici le problème qui m'a poussé à cette utilisation étrange. j'ai une base volumineuse et quand je souhaité importer les données d'une table avec ado je devais parcourir toutes la table ce qui me prenait beaucoup de temps donc j'ai opté pour accessapplication qui me permet d'exporter les enregistrements de la table ou via requête ce qui me fait gagné énormément de temps.
donc j'ai trouvé la solution on travaillant avec des variants

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
implementation
  uses unitdm, Unit2,Unitdm1,Unitdm2,UnitDMetat;//,unitsplash;
{$R *.dfm}
var access,access1,access2:variant;
----
  Access := CreateOleObject('Access.Application');
  try
   Access.OpenCurrentDatabase (chemin1,false,mpasse);
  ...........//exportation des tables et requêtes
 finally
     
      //Access.Quit;
      Access:= unassigned;

    end;// fin try

vous remarquerez que j'ai annulé l'instruction access.quit car après son exécution microsoftaccess s'ouvre et devient visible et on annulant l'instruction il n'st pas visible.
Merci encore.

[SergioMaster]

Bonsoir,

j'ai toujours le même doute concernant votre approche du problème !

j'ai une base volumineuse et quand je souhaité importer les données d'une table avec ado je devais parcourir toutes la table ce qui me prenait beaucoup de temps donc j'ai opté pour accessapplication qui me permet d'exporter les enregistrements de la table ou via requête ce qui me fait gagné énormément de temps.

je me souviens bien de ce sujet même si je ne retrouve pas la discussion. Je reste persuadé que le problème ne viens pas d'une base volumineuse mais de votre façon de la traiter. Pire il me semble que vous vous enferrez dans une solution inadéquate.

Si j'ai bien compris votre démarche vous accéder a une base A géré par un SGBDR que nous décrirons comme externe (sur un serveur) au poste client
vous avez des problèmes de temps de connexion à votre base car la table à récupérer est trop "volumineuse"
la solution que vous apporter est de récupérer la table dans une base ACCESS pour ouvrir ensuite celle-ci.

Moi, je vois que ainsi votre programme récupère deux fois l'ensemble des données : une fois pour remplir la table access, une autre fois pour lire cette table !
Inconvénients dans un environnement multi-utilisateur , vous ne pouvez pas répercuter les modifications !

Si vous me retorquez à ce stade que votre base se trouve sur un réseau instable voire un réseau internet et que quelques fois il n'y a pas de connexion avec le serveur principal je vous dirais qu'il existe une technique : La réplication (cherchez ce terme en fonction de votre SGBDR)

S'il s'agit d'un réseau local stable,
ADO comme ACCESS n'ont jamais été ma tasse de thé mais à ADO, il y a des alternatives plus intéressantes proposant du CacheUpdate qui permet de travailler en mémoire et de réconcilier les données à moment voulus.
ACCESS est bien multi-utilisateur selon les dires de MS et de ses fans, mais selon vos indications vous l'utilisez comme une base mono-utilisateur (puisque servant à votre application en sorte de tampon de données) vous venez d'être confronté à ce problème (sujet de cette question) mais avez vous songé à mettre en place ce que MS indique pour être en multi-utilisateur (deux applications ou plus sur la même BD) ?