Discussion :

[Mister Nono]

Comment connaitre le nombre d'enregistrements d'une table Paradox.

Par exemple comme :
i := Ma_TForm.Ma_TTable.Enregistrements_Count;

Merci.

[Seb]

Salut,

Regarde du côté de RecordCount.

A+,

Seb.

[Sylvain James]

Dans le cas d'un TTable RecordCount fonctionne car un le composant exécute un Select * From Table
mais le plus standard est un Query avec un Select Count(*) as NbEnreg From Table
ensuite on récupère le nb dans le TField.Name = NbEnreg

Sylvain

[Amenofis]

Salut,

le RecordCount renvoie le nombre d'enregistrements "actifs"... c'est à dire que si la table est filtrée par exemple, il ne donne que le nombre d'enregistrements filtrés et non le total de la table...

cela dit c'est pas un problème si on le sait...

la requete est, à mon avis aussi, le meilleur moyen ; surtout qu'elle peut être réduite à une fonction

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
Function NbRecord(NomTable:TTable):integer;
begin
With TQuery.Create(nil) do
   begin
   SQL.Add('SELECT COUNT(*) AS Total FROM "'+NomTable.TableName+'"');
   Open;
   if RecordCount<>0
      then result:=FieldValues[Total]
      else resull:=-1;
   Active:=false;
   end;
end;

il doit falloir ajouter dbTables dans la clause USES (sauf erreur et si c'est pas déjà fait... )

@+

[Sylvain James]

Le TTable est proscrit pour les développements, au début il était là uniquement pour prototyper rapidement les softs.
Ceci dit pour des petites applis desktop c'est pas forcément gênant mais c'est bien de prendre des bonnes habitudes dès le départ.

Pour filtrer, ajouter un clause Where à la requête SQL. Si le filtre s'effectue via la propriété Filter, ça veut dire que plus d'enregistrements auront été renvoyés par le serveur SQL, et donc plus de surcharge réseau.

Une exception à tout ça : le composant ClientDataSet qui se trouve en fin de chaîne de récupération des données provenant d'un serveur SQL. Il se comporte comme un TTable mais est designé pour fonctionner au sein d'une architecture n-tiers. Et là Filter et RecordCount sont très utilisés.

Sylvain

[Gege70]

Le TTable est proscrit pour les développements, au début il était là uniquement pour prototyper rapidement les softs.
Ceci dit pour des petites applis desktop c'est pas forcément gênant mais c'est bien de prendre des bonnes habitudes dès le départ.
.....

plus de précisions stp Sylvain

[serge-07]

Le TTable est proscrit pour les développements

je suis comme GEGE70, j'aimerai bien que Sylvain nous explique...

[Mister Nono]

Moi aussi.

Merci Sylvain.

Bye,

[Sylvain James]

Si vous voulez, le TTable peut-être considéré comme un TQuery masqué auquel on aurait fait exécuter la requête Select * From Table. En d'autres termes vous n'avez pas le choix, le TTable ramène toutes les données ainsi que les metas données d'une table.

Si la table en question comporte 300000 enregistrement dont certains sont des blobs par exemple, ça fait beaucoup de données... et avec un TTable on n'a pas le choix, tout est chargé en mémoire sur la machine cliente, et si le serveur est distant, les 300000 enregistrement passe par le réseau (merci du cadeau :-))

Or quel utilisateur a la capacité ou le besoin de visualiser 300000 enregistrements sur son écran ? Une interface cohérente va demander à l'utilisateur de fournir des clés de recherche ou des intervalles de visualisation, et en fontion on interrogera la base de données au fur et à mesure, mais pour ça il faut interroger le serveur SQL avec un Query, qui nous permettra d'envoyer des commandes plus précises que Select * From Table.

Par exemple :

Code :

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

1
2
3
Select IDPersonne, Nom, Prenom
From tbPersonnes
Where NOM Like 'L%'

Renverra toutes les personnes (et encore seulement le nom et le prénom)
dont le nom commence par L.
Lorsque l'utilisateur choisi un utilisateur on peut rebalancer une requête pour obtenir plus de précisions sur cet utilisateur, par exemple sa photo etc. :

Code :

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

1
2
3
Select Nom, Prenom, Adresse, Telephone, Photo
From tbPersonnes
Where IDPersonne = :IDPersonne

Ca évite de charger toutes les photos des 100000 personnes présentes dans la table par exemple.... et c'est une utilisation plus cohérente de la mémoire et le réseau s'en trouve beaucoup plus léger.

Ce n'est qu'un exemple assez grossier mais j'espère que vous comprenez le principe : Avec un TTable, on n'a pas le choix d'affiner les requêtes alors que ce n'est qu'un TQuery qui fait Select * From Table. Donc autant travailler avec des TQuery.

Sylvain

[serge-07]

Y'a du pour et du contre dans ton explication.
c'est pas parce qu'on a une table de 300000 enreg, qu'on est obligé de passer par un query.
vu de loin, et sans avoir vérifié, je pense que 80% de ton exemple peut etre résolu uniquement avec la propriété filter de TTable.
Tu n'as pas tort sur le fond, cependant la tendance qui consiste chez certains, à tout vouloir résoudre par des query, est parfois un peu énervante; surtout quand une bonne connaissance des tables permettent de régler le problème.
La réponse à la question posée est bien : recordcount, point final;
pas besoin de 2 ou 3 query pour ca , meme si la table est filtrée:
dans ce cas : filtered:= false; x= recordcount et filtered:= true; comme l'a indiqué un intervenant.
d'ailleurs si le clientdataset se comporte comme une table, comme tu le reconnais, c'est qu'une table a parfois bien des avantages, non ?
salutations.

[Sylvain James]

Y'a du pour et du contre dans ton explication.
c'est pas parce qu'on a une table de 300000 enreg, qu'on est obligé de passer par un query.
vu de loin, et sans avoir vérifié, je pense que 80% de ton exemple peut etre résolu uniquement avec la propriété filter de TTable.

Bien sur il n'y a aucune obligation, il s'agit juste d'un "Best Practice".
Il faut dire que j'ai simplifié et que dans certaines situations, ce que j'ai dit n'est plus vrai. Par exemple, le TTable est plus rapide avec le BDE qu'un TQuery. Par contre les filtres sont catastrophiques sur de grosses tables (normal, c'est un callback qui est appelé pour chaque enreg).

Tu n'as pas tort sur le fond, cependant la tendance qui consiste chez certains, à tout vouloir résoudre par des query, est parfois un peu énervante; surtout quand une bonne connaissance des tables permettent de régler le problème.

Je crois que tu soulèves le véritable problème : une bonne connaissance des tables permet d'en tirer profit mais à condition d'en connaître aussi les limites et que le choix prenne bien en compte les évolutions possibles de l'application. Seulement la plupart des développeurs qui utilisent les TTable sont des débutants et n'en connaissent pas les ecueuils et surtout apprennent à communiquer avec une base de données d'une mauvaise manière.
Grosso modo, il faut bien rappeler que le BDE est deprecated, et que la philosophie de développement avec des SGBD Fichiers est différente de celle des bases de données client serveur.

d'ailleurs si le clientdataset se comporte comme une table, comme tu le reconnais, c'est qu'une table a parfois bien des avantages, non ?
salutations.

Faut pas tout mélanger. Avantage oui, à condition que les inconvénients ne viennent pas tout saboter. La philosophie du clientdataset comporte toutes les facilités offertes par les TTables (et bien plus encore), sans les inconvénients (de par son indépendance d'un middleware déjà et sa parfaite intégration dans n'importe quelle architecture SGBD : locale, client-serveur, n-tiers, et même XML.

Sylvain

[serge-07]

Merci pour ta réponse. et comme le but d'un forum est entre autre de confronter des points de vue differents, je voudrais ajouter , concernant la phrase suivante :

Seulement la plupart des développeurs qui utilisent les TTable sont des débutants et n'en connaissent pas les ecueuils et surtout apprennent à communiquer avec une base de données d'une mauvaise manière.

qu' il ya beaucoup de developpeurs Confirmés qui utilisent des TTables ( certains ont même 25 ans d'informatique derriére eux ).

Grosso modo, il faut bien rappeler que le BDE est deprecated, et que la philosophie de développement avec des SGBD Fichiers est différente de celle des bases de données client serveur.

Je suis entiérement d'accord sur la différence de philosophie, mais :
ce n'est pas parce que le BDE est deperecated, que cela signifie que les SGBD fichiers Et les TTables sont morts;
Exemple :
- cela fait plus de 10 ans que DBase est deprecated, et ( je ne m'en réjouis pas ) on trouve toujours des tables DBases qui fonctionnent aujourd'hui.
- D'autre part, il existe des TTables qui fonctionnent SANS BDE, donc avec un simple delphi perso , et qui ont de très bonnes performances.
- tu oublies de signaler que l'excellent clientdataset qui represente effectivement une bonne synthese a cependant un gros défaut : il charge la totalité des données en Mémoire ;
comme quoi rien n'est parfait en ce bas monde.
Ravi d'avoir eu cet echange d'idée trés interessant.
Serge.

[Sylvain James]

qu' il ya beaucoup de developpeurs Confirmés qui utilisent des TTables ( certains ont même 25 ans d'informatique derriére eux ).

J'avais dit : la plupart sont des débutants.
Je veux bien te croire simplement, j'ai rien inventé, ça fait plusieurs années que je fréquente les forums Delphi en france et us et les borlanders pronent pour éviter les TTables qui n'apportent pas grand chose. Tiens ça n'a pas mis longtemps encore une question sur Delphi SGBD : http://www.developpez.net/forums/viewtopic.php?t=129759 où tu réponds, et où on peut encore constater qu'il est plus efficace d'interroger le serveur SQL soi même plutôt que de laisser un TTable faire ses propre traductions en SQL de toutes les propriétés renseignées. Ce qui montre bien encore qu'au lieu de faciliter la vie du développeur, on arrive au contraire dans certains cas et surtout qu'un développeur débutant est tout à fait capable de se servir d'un query, d'où le "Best Practice" énoncé ci avant.
De toute façon puisque le temps est à l'argumentation, je donne les éléments dont je dispose, c'est à chacun de prendre ce qui l'intéresse, je ne cherche pas à imposer. C'est bien aussi de recevoir des critiques et d'autres points de vue, c'est nécessaire.

- tu oublies de signaler que l'excellent clientdataset qui represente effectivement une bonne synthese a cependant un gros défaut : il charge la totalité des données en Mémoire ;

Tu as raison, il a été écrit pour mémoriser des données déjà extraites (donc en nb limité normalement) via un query ou autre composant d'extraction. On peut s'en servir aussi comme table autonome (ce que je fais dans certains cas :-)) mais en gardant à l'esprit l'inconvénient que tu cites.

Sylvain

[Mister Nono]

Merci à Amenofis qui m'a fournis l'information dont j'avais besoin :

Code :

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

1
2
 
le RecordCount renvoie le nombre d'enregistrements "actifs"... c'est à dire que si la table est filtrée par exemple, il ne donne que le nombre d'enregistrements filtrés et non le total de la table...

Pour répondre à Sylvain, je suis d'accord avec toi : il faut éviter le BDE et ses mécanismes associés. Sauf quand on me demande de reprendre une application existante qui justement utilise le BDE et pour laquelle il est inutile de réécrire le code source pour le plaisir de travailler avec IB ou une autre base de données transactionnelle. En fait il faut maintenir l'existant.

Merci à tous.

Bye,

[Bloon]

- D'autre part, il existe des TTables qui fonctionnent SANS BDE, donc avec un simple delphi perso , et qui ont de très bonnes performances.

Non, le composant TTable, défini dans DBTables, fait partie du BDE :

La classe TTable permet d'accéder aux données d'une table de base de données en utilisant le moteur de bases de données Borland (BDE).

Il peut exister des composants qui y ressemblent et qui héritent de TDataSet (indépendant du BDE, lui), mais TTable = BDE.

L'utilisation du TTable dans une application basée sur un SGBD est une erreur, et il n'y a aucune exception, 25 ans d'expérience ou pas !

Bloon

[serge-07]

Bonjour Bloon,

Je reviens dans la discussion pour apporter quelques précisions.
Quand je parlais des ttables ,sans BDE, je voulais parler de la meme chose que toi, lorsque tu dis

Il peut exister des composants qui y ressemblent et qui héritent de TDataSet (indépendant du BDE, lui)...

Je voulais simplement dire que tous les programmeurs qui utilisent le composant TTable, qui repose sur le BDE, ne sont pas tous des nuls, sous pretexte qu'ils utilisent un composant reposant sur le BDE !
il suffisait de dire à 'noelmaurice' qui posait la question : "Tu devrais laisser tomber ton Table.recordcount parce que le BDE est deprecated, et utiliser par exemple IBTable.Recordcount ", mais il le dit tres bien :
quand on a une appli BDE qui marche, pourquoi la réecrire?

Je suis d'accord avec toi pour dire que le BDE est deprecated, et qu'il ne faudra plus l'utiliser. Mais quand je lis sur ton site SQLView, que je trouve honnétement trés interessant que :

SQLView est un éditeur SQL basé sur le BDE de Borland.

, je me suis qu'on a encore tous du chemin à faire pour ne plus etre "dans l'erreur".

Tu peux d'ailleurs vérifié ma bonne foi en constatant sur mon site, que
j' utilise un composant "TSdTable", qui n'utilise pas le BDE, que j'utilise
un composant ThdbQuery adapté à mon SGBD, et que je n'hésiterais pas
une seconde à modifier ton SQLView (qui me semble interessant), pour l'adapter à mon petit SGBD en supprimant les références au BDE (deprecated) de ton SQLView ! (mais je n'ai pas vu si tu fournissais le code source ?)

Comme quoi, je travaille aussi d'arrache-pied, pour "sortir de l'erreur"
tous ces pauvres programmeurs, qui n'avaient que le BDE à se mettre sous la dent !

[Bloon]

Je suis d'accord avec toi pour dire que le BDE est deprecated, et qu'il ne faudra plus l'utiliser. Mais quand je lis sur ton site SQLView, que je trouve honnétement trés interessant que :

SQLView est un éditeur SQL basé sur le BDE de Borland.

, je me suis qu'on a encore tous du chemin à faire pour ne plus etre "dans l'erreur".

Je me suis peut-être mal exprimé, mais j'ai dit que c'était l'utilisation du TTable qui était une erreur, pas l'utilisation du BDE ! Ce que je voulais dire, c'est qu'il faut utiliser des TQuery plutôt que des TTable quand on accède à un SGBD. Le TTable est adapté aux tables paradox, dbase et foxpro, et encore, pour une utilisation locale.

Personnellement, j'utilise toujours le BDE lorsque je dois faire de l'odbc, sinon je préfère les composants natifs (IBExpress, etc...). Je n'ai pas encore franchi le pas dbExpress (par manque de temps)

je n'hésiterais pas une seconde à modifier ton SQLView (qui me semble interessant), pour l'adapter à mon petit SGBD en supprimant les références au BDE (deprecated) de ton SQLView ! (mais je n'ai pas vu si tu fournissais le code source ?)

Le code source n'est effectivement pas fourni.

Bloon

[jibe74]

Bonjour et bonne année !

En cherchant comment filtrer une TIBTable, je découvre ce post et ce débat fort intéressant sur les TTables... Me sentant "un peu" visé , je viens apporter mon témoignage : Je suis en effet développeur depuis environ 25 ans et j'utilise les TTable à outrance

Comme je suis comme tout le monde, qu'il faut bien que je trouve un responsable pour les fautes que je commets, je vais dire que c'est la faute à Borland

En fait, j'ai toujours développé seul dans mon coin et appris sur le tas. Je regrette de ne pas avoir utilisé plus tôt les forums et autres news : ça m'aurait permis de progresser plus vite et certainement dans un meilleur sens... Mais sans eux, il fallait bien que je me dém*** pour faire mon boulot et tenir mes délais. J'ai tenté de suivre tant bien que mal les évolutions de la technique (il y a 25 ans, on programmait soi-même de savantes méthodes de tri pour maintenir des fichiers d'index, les SGBD étaient inconnus !).

Quand C++Builder est apparu sur le marché, je l'ai ressenti d'une drôle de façon : Ca permettait effectivement de faire très vite certaines choses, mais la façon dont on le faisait ne me plaisait guère, et je trouvais que cela avait bien des inconvénients, surtout lorsque l'appli à développer ne se réduisait pas à un splendide cas d'école simplifié où il semble qu'un programme de facturation se réduit à quelques TTable et une ou deux relations maitre-détail qu'il est si simple d'afficher dans un TDBGrid ! On finit alors par s'en sortir par des acrobaties qui tiennent plus du bricolage que du développement professionnel...

Mais les impératifs de convivialité, de délais et de coûts poussent effectivement à se servir des TTable qui permettent de réaliser facilement de splendides IHM... On sent bien que quelque chose ne va pas, mais on n'a autre chose à faire qu'à se poser ce genre de questions, et on s'enferme peu à peu dans les solutions de facilités du RAD Borland, au point qu'on a du mal à en sortir quand on ne parvient plus à résoudre certaines difficultés qui, quand on regarde bien, ne sont posées que par une programmation assise sur de mauvaises bases...

Je dirai donc, pour conclure : oui, les TTables sont souvent bien pratiques. Et lorsqu'elles peuvent faire l'affaire (à chacun de bien juger quand c'est le cas ), pourquoi ne pas en profiter ? Mais attention au(x) pièges(s) ! Le plus gros étant celui que je viens d'évoquer, et pour lequel Sylvain James a émis une excellente mise en garde :

Le TTable est proscrit pour les développements, au début il était là uniquement pour prototyper rapidement les softs.
Ceci dit pour des petites applis desktop c'est pas forcément gênant mais c'est bien de prendre des bonnes habitudes dès le départ.

Dommage que Borland n'ait pas mis ça en rouge au début de l'aide sur TTable !

[okparanoid]

Excusez moi de deterer ce topic mais je l'ai decouvert par hasard et je l'ai trouve interressant...

En gros ca veut dire que des que je fais un matable.active je la charge en entiere en memoire et je sature le reseau ?

La vous parliez de consultation des donnees mais est-ce que pour l'ecriture il est aussi deconseille d'utiliser TTable. Si je me restreins a les utiliser (et les activer) que pour l'ecriture c'est bon, ou il vaut mieux aussi passer par des requetes sql ?

Merci pour vos reponses !

[Merlin]

Je viens mettre mon grain de sel...

Le TTable et ses copains (les émulations de TTable sous dbExpress, Interbase Expres..) sont à proscrire dans tous les cas.

Une base de données doit être pilotée en respectant sa nature et son fonctionnement. Une base de données n'est pas navigable par exemple. Donc un Ttable ou Tquery qui n'est pas unidirectionnel rajoute énormément de trucs inutiles qui surchargent la base.
Pour la navigation on charge dans un clientdataset ce qui est nécessaire à l'utilisateur et c'est tout, donc requête SQL à la main bien écrite (ce qui implique une bonne utilisation des index, des plans, etc).

Toute autre technique ne peut que présenter des dégradations de performances.

Quand je lis ici des choses du genre "tout régler par des query m'énerve" et des conseils du genre "ttable avec un filtre c'est mieux", ça me fait peur...

Si Borland a mis fin au BDE et à propose dbExpress avec le clientdataset c'est pas pour rien. Et si Microsoft dans ADO.NET reprend exactement le même principe (logique déconnectée à 100%, dataset en mémoire, requêtes unidirectionnelles saisies à la main (ou aidée par un expert), etc), c'est parce qu'on s'est bien rendu compte que c'est la seule façon efficace de programmer un SGBD.

Le TTable est le plus performant des composants... pour attaquer une base Paradox, base de données réseau et non pas serveur SQL. Point.
L'utiliser dans tout autre contexte c'est ne pas bien comprendre comment tout cela fonctionne.