Discussion :

[gduo200]

J'ai trouvé beaucoups de composants ou de d'ensembles de composants qui permettent d'accéder de manière native a différents formats de fichiers de données, en plus des composants qui permettent d'importer ou d'exporter des fichiers et des Dataset.

Je rêve de celui qui me permettera d'interroger directement un TClientDataSet. Quelqu'un en connait - il ?

[ShaiLeTroll]

le TClientDataSet sert de d'objet de base pour communiquer avec un Provider via un Echange de Donnée qui contient la description de l'ensemble et ses données ... c'est pour faire du 3-tiers, ce que l'on ne fait pas avec ADO utilisé directement dans l'appli client (~client-serveur)

Ainsi, tu as ta DB sur un serveur, un service sur un autre serveur qui recoit le SQL, lance les commandes via ADO par Exemple, puis fourni un Provider qui envoi ses packets à un TClientDataSet sur la machine client... cela fonctionne par Variant ou XML, il me semble ... je ne sais pas ce qui transite sur le réseau, XML ou directement la Mémoire des Variants ? Vu mon expérience délicate à ce sujet, la seconde solution est plus que probable car économique en mémoire et en CPU ...

J'en ai utilisé durant deux ans dans mon ancienne boite, il y avait bcp d'objet qui héritait du TClientDataSet (TMemDataSet ou TSchemaQuery de MK Query par exemple), mais je n'ai JAMAIS vu le code côté serveur, ce qui est bien dommage, et j'avoue n'avoir pas non plus compris grand chose à partir du moment ou débarquait trop souvent IProvider & IConnectionBidule ... tout l'architecture de l'application était un Main qui contenait les connections, et tout était séparé en quelques milliers d'activeX, voire même un DCOM ou COM+ qui je crois trainait sur les serveurs ...

Regarde les exemples dans "...\Borland\Delphi7\Demos\Db\SQLClientDataset\"

Après pour ton histoire de requête, je ne vois pas trop ce que tu veux dire, je n'ai jamais utilisé le TClientDataSet en direct, donc je connais les bases que l'on a bien voulu m'expliquer à mon ancien bureau (j'en ai oublié et pire déformé quelques principes si cela se trouve, il n'y a pas un tutoriel ce composant ?)

Sur le TClientDataSet tu peux faire des Filter, Locate, Master/Detail ... tout ce qui est possible sur un DataSet Standard que demandé de plus ? et le SQL passe par CommandText (dans mon utilisation TSchemaQuery aidait BCP à son utilisation)

[gduo200]

Merci pour ta réponse.

TClientDataSet est en effet trés puissant. Il m'interesse en tant qu'outil
pour accéder à des tables / fichier sur disque local, mais aussi via un provider à des tables de divers formats.

En l'occurrence, par exemple, il s'agit d'un Add Onn qui doit être aussi léger que possible ( 1 executable dans l'idéal ) pour une ancienne application dont les tables sont stockés sous format .... dBase !

Les composants Degisy me permettent un accès natif ( Sans BDE ) aux tables. Tables aux quelles j'accède ensuite via un Provider par un ClientDataSet qui me permet d'avoir des agrégats et d'autres facilités.

Les composants Degisy ne comprennent pas de Requête. Et je veux pas mettre en branle un SGBD même léger ( tel que Absolute ) pour éviter la mutiplication des données en mémoire ( et un peu par coquetrie ).

J'ai pourtant besoins de regroupements sur les enregistrements de l'une des tables et je veux éviter de le faire par code par souci de performance. ( j'ai d'ailleurs un post à ce sujet sur le quel j'espère des réponses).

Voilà pourquoi dans ce cas, par exemple, j'aimerais pouvoir interroger par sql le ClientDataSet lui-même.

Il me semble avoir compris d'après la doc delphi que les ClientDataSet et d'autres DataSet utilisent SQL pour communiquer avec les ensembles source même quand ces sources ne sont pas issues de SGBD, voila pourquoi j'ai imaginé qu'il y avait une sorte de 'couche sql' innaccessible. De la à espérer que certains aient su l'exploiter il n'y avait qu'un pas.

[ShaiLeTroll]

Essaye de voir si tes composants Degisy propose une propriété DataSource (c'est inclu dans le DataSet mais tous en l'implémente pas), ainsi tu pourrais gréffer une Query Degisy et tu mets dans DataSource de la Query un DataSource relié sur un TClientDataSet, ainsi tu pourras faire du SQL en direct sur le sous Ensemble ...

[gduo200]

Merci d'avoir répondu, ShaiLeTroll.

Degisy VCL est une suite de 6 composants permettant l'accès natif à 4 formats de tables Clarion, Paradox, DBase et DDa (?) et des Tables Mémoires
(pour ceux que ça intérèsse). C'est pratique pour intervenir sur d'anciennes applications, mais sans plus, surtout qu'il n'y a pas de composant de type Query.

Pour mieux comprendre la solution que tu me propose j'ai besoins de savoir si la propriété DataSource qui permet à une Query de recevoir des paramètres existe aussi des TDataSet autres que Query ? Dans ce cas là que représente-elle ? La doc sur ce point est claire mais forcément succinte.

[gduo200]

- Je dévellope en [D7 Entreprise] sous [XP], une application qui devra fonctionner sous [W95] à [Vista].
- L'application est monoposte, mais j'espère la passer en client / serveur dans un second temps. Je l'y prépare du mieux de mes conaissances.
- La structure des tables est imposées ainsi que leur format : DBase.

J'ai choisi de réunir les accès au tables dBase dans un Module de données qu nous appellerons DM0 :
- Un composant tDsDataBase me connecte à la base (le dossier dans ce cas) et les composants TDsDbfTables aux tables. Se sont des composants de la suite Degisy Data.
- Chacune des Tables est reliée à un DataSetProvider standard
- Ces provider son mis à la disposition des autres modules de données par une LocalConnection.
- C'est ce module de données qui sera modifié (ou remplacé) par un module données distant, si l'application doit changer en Client/serveur. (C'est du moins ce que j'espère).

D'autres modules de données contiennent des ClientDataSet "fournis" par les DataSetProvider du module de données DM0. Ils constituerons eventuellement la partie "client".

Les traitements sont minimes et classiques, il s'agit principalement de réprésenter le plus clairement possibles des relation maitres-détails et quelques agrégats.

On peux faire bien des choses en clonant les curseurs ou en utilisant la propriété TClientDataSet.Data mais je suis confronté au problèmes suivant :

Comments me passer d'un SGBD pour :

1 - effectuer des regroupements d'enregitrements sur certains champs.
Il y a bien TCLientDataSet.GetGroupState mais je n'y arrive pas : voir ce post

2 - obtenir des tris sur des champs de référence sachant qu'on ne peux indexer sur ce type de champs.

Pour être complêtement honnête je dirai que je cherche en fait à améliorer la solution que j'ai retenu et qui fait appel à un SGBD léger ( Absolute Database) :

- Dans le Module DM0 des tables mémoire TAbsTables ( Absolute ) importent les tables TDsDbfTable ( Degisy) puis des requêtes sont effectues sur les TAbsTables. C'est à ces requêtes que sont reliés les DataSetProvider. Les ClientDataSet recoivent ainsi des champs que l'on peux manipuler sans contrainte.
Les inconvénients sont les suivants :
- Les opérations d'importations ralentissent le lancement du programme.
- La mise à jour des tables est acrobatique puisqu'il faut pour chaqu'une un provider supplémentaire, qu'on appelle directement par sa méthode ApplyUpdates en lui fournissant un Journal des modifications (Delta) !


J'aimerai un maximum d'avis sur ce que je viens de présenter, pour peu que cela interesse quelqu'un.

merci

[ShaiLeTroll]

Cela devait être l'architecture chez mon ancien employeur, avec des Clients TClientDataSet surchargé en TMemDataSet puis en TMKQuery, qui tous connecté sur un Provider (variable globale de l'environnement d'un FrameWork propriétaire), ... le côté server, là je ne sais rien ... mais on avait bcp d'échange de Data, car tout était fait en ActiveX (il y en avais plus de 1500, si ils ont continué, cela doit dépasser les 2000 ActiveX contenant pour certains les traitements IO métier et d'autres contenant 1 ou plusieurs écrans ...) et je trouvais personnellement, les traitements assez correct, par exemple créé un dictionnaire de mot à partir d'un fichier NX (CCAM) devait prendre 1 minute pour être calculé (Analyse de Texte, Hierarchisation et Indexation, Synonyme, ....) mais mettait 1 heure à être insérer dans la Base (800 000 insert dans une table, et 10 000 dans une autre) donc 4ms par insert, j'ai vu pire mais bien mieux aussi ...


Tout cela dépasse de loin mes connaissances en TClientDataSet moi je suis plus TTable, TIBQuery ou TMyQuery (MyDAC CoreLab), ... je sais utilisé les DataSet très simplement (très peu de Master Detail auto), je fais presque tout à la main, via des Jointures, ou via une Couche de Persistance de mon cru (dans le genre InstantObjects) qui finalement gènère du SQL donc des jointures ... de toute façon, je ne fait actuellement que maintenir de vieille appli avec un passif DBase migré sur MySQL avec peu de subtilité ...

[gduo200]

En fait j'en connais beaucoup moins que toi sur le dévellopement client / serveur, j'ai juste fouillé de fond en comble les possibilités de TClientDataSet.

J'étais d'ailleurs en train de me dire que si j'était seul à chercher ce genre d'outils (j'en suis toujours à ma TQuery pour dataSet), c'est que mon approche n'était tout simplement pas bonne quand ...

Je suis tombé là-dessus ! Voilà mon ego rassuré mais je ne suis pas plus avancé vu qu'ils ne proposent rien pour Delphi.

[gduo200]

Il existe bien un composant qui permet d'effectuer des requêtes sur des DataSet et descendants c'est "TxQuery" mais il est payant.