Discussion :

[slimjoe]

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
17
 
  with TADOQuery.Create(Self) do
  try
    ConnectionString := PJConnexion.connexionSTR
    SQL.Text := 'select * from '+tableName+' where '+filtreFieldName+'='+quotedStr(filtreValue);
    try
      Open;
      Edit
      fieldByName(fieldName).Value := Value;
      Post;
    except
      //raise; exception silencieuse
      Result := false;
    end;
  finally
    free;
  end;

Woah! On peut faire des Edit/Post sur des TADOQuery !

Merci Pascal!

[Pascal Jankowski]

Woah! On peut faire des Edit/Post sur des TADOQuery !

Merci Pascal!

Effectivement, on peut utiliser Post avec des Query. Cependant, il existe une limitation, comme je l'ai expliqué plus haut, cela fonctionne très bien dans le cas de requêtes simples. Par contre les requêtes utilisant par exemples des jointures ne renvoient que des ensembles de résultats en lecture seule ie dans ce cas le post ne fonctionne pas.

[Hauwke]

Bon,
Finalement, j'ai laissé tomber les TDatamodules... C'est un peu ennuyeux pour ma modularité mais pas dramatique. En ce qui concerne les composant d'accès aux données, j'ai découvert les Tadoquery, hier toute la journée.
Leur principal avantage, à mes yeux, reste également leur principal inconvénient:
A l'inverse d'une Tadotable, l'ensemble de données n'est pas présent en mémoire. La notion de "travail sur un ensemble vif" devient plus relative. Ce qui, certes, ménage les ressources machines mais pénalise, quelques fois, la rapidité de réponse d'autant qu'un grand nombre de données sont cryptées. Différents cryptages sont utilisés en fonction de la provenance et de la sensibilité de l'information et cryptage en double passe de la bases de données - y'a des paranos sur cette planéte! - Bref, c'est pas si simple et je m'oriente vers un compromis mal taillé entre les deux composants TAdotquery et TAdotable en fonction de mon besoin en terme de vivacité de réponse.
Je vous remercie de toute l'aide et des précieux conseils que vous m'avez apporté.
Je souhaite quand même trouvé une explication au probléme des Tdatamodule qui ne fonctionnent pas dans les Dll. J'aime pas abandonner un code simplement parce que j'y arrive pas!
Cordialement,
Hauwke

[Pascal Jankowski]

Une solution consisterait à utiliser non plus les TADOQuery mais les TClientDataSet. Midas/Datasnap peut être une solution à ton problème.

Passer par un serveur d'application et faire cette fois-ci du 3-tiers.
En utilisant cette fois-ci COM/DCOM, TCP/IP ou WEB pour la communication entre ton serveur d'application et ton client, cela te permettrait l'économie de certaines de tes dll, je pense, car tu pourrais y ajouter les méthodes que tu désires distribuer. Cela simplifie encore le contrôle de l'existance des dll par tes clients mais encore simplifie la gestion du versioning de ces dll.

Donc un serveur d'application fournit à la fois les données que tu récupères dans un TClientDataSet mais également des méthodes.

Côté client, cela nécessiterait moins de ressources. Seul, le serveur s'occupe de charger les tables en mémoire et de les décrypter puis de fournir les données à chaque client.
Inversement ton client fournit les données voire la requête. Charge donc au serveur de se débrouiller.

Dès que ton serveur d'application est enregistré grâce à un regserv sur la station du réseau qui l'accueille, plus besoin de s'occuper de lui. Ce n'est même pas la peine de le lancer. Dès qu'un client tente de solliciter le serveur (le client connaît l'ip ou l'url (si monté dérrière IIS) du serveur qu'il interroge) le serveur se lance immédiatement puis il fournit au client les informations désirées. Dès que tous les clients se sont refermés alors automatiquement le serveur d'application termine sa tâche. Son processus est automatiquement arrété.

J'ai éprouvé plusieurs fois cette solution, elle n'est pas très compliquée à mettre en place et en général c'est assez solide.
Le deployement et l'entretient est par contre un peu plus lourd que pour du 2-tiers.

Ensuite, il n'y a qu'un pas pour écrire la petite dll qui convient et la passer sur IIS par exemple et permettre à tes clients de se connecter de façon distante voir ajouter une solution client léger avec ASP par la suite.

Si tu désires plus d'infos n'hésite surtout pas.

Pascal

[LadyWasky]

Quand est-ce que tu dis que ça plante au juste ? Ça plante (exception) ou ça donne un résultat non valide ?

La curiosié est un vilain défaut !

==> Ca plante sur une histoire de Variant invalide (j'ai pas l'erreur exacte sous les yeux, mais je t'envois ça Lundi).

Bref une conversion de Variant qui coince. Ca doit dépendre de la façon dont le Locate est implémenté (où les fonctions/procédures auquel il fait appel) dans le descendant du TDataSet je pense.

C'est un peu comme l'histoire de RecordCount ce genre de chose...