Page 1 of 2 1 2 LastLast
Results 1 to 15 of 26

Thread: TClientDataSet

  1. #1
    [it]Ontvangen per e-mail:[/it]

    Naar aanleiding van de artikelen over
    TClientDataSet had ik wilen vragen:
    1.Iedereen schrijft over alle voordelen van TClientDataSet, maar welke
    nadelen kleven er aan: het feit dat alles in het geheugen plaatsvind (gaat
    dat met 'gewone' machines), is er een begrenzing qua tabel-grootte enz.
    2. Wat is slimmer: Calculated fields aanmaken op je gewone tabel en dan
    naar TClientDataset of Calculated fields meteen aanmaken op je
    TClientDataset?

  2. #2
    1.
    In principe is het feit dat alles in het geheugen gebeurt geen nadeel. Dat werd eigenlijk ook al met 'gewone' queries gedaan. Pas als cached updates aan werd gezet werd de data naar een tijdelijke Paradox tabel gekopieerd.

    De stelregel die eerder geldig was is dat nu dus nog steeds: zorg ervoor dat je je gebruiker niet opzadelt met een lijst data van honderden regels. Laat de gebruiker eerst de selecties uitvoeren en haal alleen die data op die hieraan voldoet.

    2.
    Calculated fields kun je het beste op je orginele dataset plaatsen. Als je wat verder gaat met een ClientDataSet zul je Midas gaan gebruiken, je query staat dan op een aparte applicatieserver. In de zin van scheiding user interface en logica hoort je calculated field bij de logica en dus op de applicatie server. Als je dan later verschillende ClientDataSets aan deze query koppelt hebben ze allemaal voordeel van het calculated field.

    Helpt dit je verder?
    Marcel

  3. #3
    Senior Member rieni's Avatar
    Join Date
    Mar 2001
    Location
    Br?©ttum bij Lillehammer, Noorwegen
    Posts
    342

    Thumbs up

    Bedankt voor het antwoord. Ik probeer hier wat collega's over te halen om TClientDataset te gebruiken. Naar mijn idee gaat zoeken, sorteren en filtreren veel sneller met TClientdataset. Vooral in een grid waar je op de titel van de kolom klikt. En zo willen de gebruikers het hebben. En dat is wat ze doen: zoeken, ophalen, filteren enz.
    << zorg ervoor dat je je gebruiker niet opzadelt met een lijst data van honderden regels >>

    OK, men dat zal wel moeten als de gebruiker in het hele adressenbestand wil zoeken.
    Onze grootste (dbf)-tabel heeft 20000 adressen, ong. 30 fields en is 5000 kb.
    Is dat dan eigenlijk veel te veel?
    Rieni

  4. #4
    Je argumenten om ClientDataSet te gaan gebruiken kloppen inderdaad. Er komt er nog één bij: Borland wil ons graag die kant op hebben en richt zijn ontwikkeling daar ook op.

    Als je kijkt naar dbExpress (zeg maar de opvolger van de BDE, zie nieuwspagina), dan zie je dat dat voor en groot gedeelte is gebaseerd op ClientDataSet technologie. De 'personal database' in Kylix (en aangekondigd voor Delphi 6) is prachtig, maar lijkt verdacht veel op een ClientDataSet met SaveToFile. Wist je trouwens SaveToFile('SomeName.xml') een bestand met het XML formaat opleverde? Nog een reden om naar ClientDataSet te gaan: XML is al voor een groot deel voorbereid.

    Je tabel met 20.000 adressen is geen probleem. Als je user-interface zo is opgezet dat je gebruiker al die 20.000 regels over het lijntje krijgt kon dat wel eens een probleem worden. Dat heeft niet zozeer met ClientDataSet te maken alswel met het feit dat je netwerk zwaar wordt belast. Bovendien krijgt de gebruiker wel erg veel data voor z'n kiezen. Ik kies er bij deze cijfers meestal voor om eerst een selectie te laten maken: 'geef iedereen in Oosterhout', 'geef iederen met een 5 in het telefoonnummer', of iets dergelijks.

    Suc6 in je strijd

    Marcel

  5. #5
    <<<Marcel: 1. In principe is het feit dat alles in het geheugen gebeurt geen nadeel. Dat werd eigenlijk ook al met 'gewone' queries gedaan. Pas als cached updates aan werd gezet werd de data naar een tijdelijke Paradox tabel gekopieerd.>>>

    Ik zie overduidelijk nadelen bij het update proces (zeker bij master-detaik), door het uitstellen van van updates kan afhandelen van fouten tijdens het update process ingewikkeld worden, vooral naar de gebruiker toe.

    <<<2. Calculated fields kun je het beste op je orginele dataset plaatsen. Als je wat...
    op een aparte applicatieserver. In de zin van scheiding user interface en logica hoort je calculated field bij de logica en dus op de applicatie server. Als je dan later>>>

    Het tweede argument klinkt goed, maar de TClientDataSet cahced toch de originele data in geheugen? Als je dan velden veranderd in de TClientDataSet waardoor de calculated field ook zou veranderen (een optelling bijvoorbeeld), triggered dan de OnCalcFields van de originele dataset en neemt de TClientDataSet deze nieuwe waarde(n) dan over? Ik ben nu net TClientDataSet aan het leren, maar mijn intuitie zegt dat ik het niet zo zou laten werken en ik vermoed daarom dat het ook niet zo werkt. Kan je hier meer over vertellen?
    Mark van der Hijden (Eindhoven)

  6. #6
    Member
    Join Date
    Nov 2001
    Location
    Hengelo (OV)
    Posts
    39
    Clientdatasets zijn inderdaad in veel situaties een goede oplossing. Deze datasets zijn echter alleen in de Enterprise versies van delphi, en vanaf 6 in pro, aanwezig. Wil je nu toch gebruik kunnen maken van een "clientdataset achtige" component terwijl je alleen de beschikking hebt over delphi 3/4/5 pro dan kun je gebruik maken van kbmmemtable, dit is een inmemory table component met dezelfde functionaliteit
    als een clientdataset (en nog meer, en in veel situaties zelfs sneller).
    Een verder voordeel is dat je nu niet de dbclient.dll/midas.dll mee moet deployen, deze dll moet op de client machine aanwezig zijn als je gebruikt maakt van ClientDatasets.

    Ps. In Delphi 6 is het nu echter wel mogelijk om deze dll mee te linken in je exe.

    kbmmemtable url :

    http://www.optical.dk/delphi/prod01.htm

  7. #7
    <<<kbmmemtable, dit is een inmemory table component met dezelfde functionaliteit
    als een clientdataset (en nog meer, en in veel situaties zelfs sneller).>>>

    Kan deze ook nested datasets verwerken?
    Mark van der Hijden (Eindhoven)

  8. #8
    Mark, ik ben zelf niet zo dol op nested datasets. De reden geef je eigenlijk zelf al aan: je moet je update zo lang uitstellen. In mijn ervaring werkt het een stuk soepeler om gewoon datasets naar de client te sturen en het master/detail gedeelte daar te regelen. Voorbeeld: klant en zijn orders. De klant dataset is een 'gewone' query, de order dataset is een query met een KlantID als parameter (allemaal nog op de server uiteraard).

    Op de client zorg je nu dat de parameter van de order dataset wordt gevuld met het juiste KlantID en je opent je order dataset. Deze manier is een stuk stabieler, je zadelt de client niet met een geforceerde master / detail relatie op en je kunt je order dataset ook openen zonder een koppeling naar de klant dataset. Dat laatste is dan weer belangrijk vanuit het oogpunt van hergebruik.

    De enige plaats waar ik wel nested datasets gebruik is bijvoorbeeld bij data die wordt klaargezet voor een rapport. Het kan dan handig zijn om de data volledig voor te bereiden op de server en die vervolgens in één of meerdere datasets naar de client te sturen. Dat is één geheel en hoort dus in één pakketje verstuurd te worden.
    Marcel

  9. #9
    Member
    Join Date
    Nov 2001
    Location
    Hengelo (OV)
    Posts
    39
    Kan kbmmemtable ook nested datasets verwerken ?

    Nee, volgens mij niet. Je kunt hem ook niet (automatisch) voor multi-tier
    ontwikkeling gebruiken, hij is alleen te vergelijken met een clientdataset
    wat betreft het inmemory houden van de records en de voordelen die dit
    opleverd.

  10. #10
    <<<Rob: Een verder voordeel is dat je nu niet de dbclient.dll/midas.dll mee moet deployen, deze dll moet op de client machine aanwezig zijn als je gebruikt maakt van ClientDatasets.>>>

    Voor zover ik kan overzien, hoef je bij gebruik van TClientDataSet's en providers, de genoemde dlls niet de deployen. Deze DLL's maken namelijk deel uit van Midas/DataSnap, maar de genoemde componenten horen hier niet bij, zo lang je geen gebruik maakt van de distributed multi-tier mogelijkheden. (Ik heb nog niet gedeployed, dus helemaal zeker weet ik het nog niet.)

    <<<Rob: kbmmemtable ... alleen te vergelijken met een clientdataset wat betreft het inmemory houden van de records en de voordelen die dit opleverd.>>>

    De TdxMemData TDataSet descendant van Developer Express lijkt me niet veel anders dan. Misschien kan kbmmemtable meer of beter of sneller, het component is me niet bekend. Maar Developer Express heeft aan mij z'n betrouwbaarheid al jaren bewezen en de TdxMemData wordt met Delphi meegeleverd, daarom kende ik deze reeds. Ken je TdxMemData en zo ja, kan je de verschillen toelichten?
    Mark van der Hijden (Eindhoven)

  11. #11
    <<<Marcel: je zadelt de client niet met een geforceerde master / detail relatie op en je kunt je order dataset ook openen zonder een koppeling naar de klant dataset.>>>

    Dit kan ik niet zo gebruiken, omdat ik per definitie een koppeling wil met de klant dataset. De geforceerde m/d relatie garandeer ik in software, dus mijn gebruikers merken hier niets van. Het is een kwestie van smaak en van design denk ik, al leent jouw opzet zich makkelijker voor three-tier scheidingen denk ik, maar ik heb nog nooit een three-tier app. hoeven maken, dus houd ik het in gedachte voor later.

    <<<Marcel: De enige plaats waar ik wel nested datasets gebruik is bijvoorbeeld bij data die wordt klaargezet voor een rapport. Het kan dan handig zijn om de data volledig voor te bereiden op de server en die vervolgens in één of meerdere datasets naar de client te sturen. Dat is één geheel en hoort dus in één pakketje verstuurd te worden.>>>

    Zoals je kan lezen in een andere post van mij over een probleem dat ik had met nested datasets, heb ik een M/D/D relatie, waarbij ook voor de tweede detail ALLE recordssets individueel moeten worden gecached inclusief hun veranderingen. Dit omdat waarden in de eerste detail en de master afhangen van wat wordt ingevoerd in de details. Ik weet dat je dit beter via db design kan vermijden, maar het was een must. Deze must zorgt ervoor dat ik m/d/d met TClientDataSet moest gaan gebruiken voor de caching en de uitgestelde updates binnen één snelle transactie. Dit had weer tot gevolg dat nested datasets dé oplossing zijn om met heel weinig code, t??ch de updates in de goede volgorde af te handelen. Of weet jij een alternatief voor de genoemde 'must'?
    Mark van der Hijden (Eindhoven)

  12. #12
    <<<Ikzelf: Voor zover ik kan overzien, hoef je bij gebruik van TClientDataSet's en providers, de genoemde dlls niet de deployen. Deze DLL's maken namelijk deel uit van Midas/DataSnap, maar de genoemde componenten horen hier niet bij, zo lang je geen gebruik maakt van de distributed multi-tier mogelijkheden. (Ik heb nog niet gedeployed, dus helemaal zeker weet ik het nog niet.) >>>

    Rob had gelijk. ??f meelinken, ??f meeleveren van de dll. :-)
    Mark van der Hijden (Eindhoven)

  13. #13
    Member
    Join Date
    Nov 2001
    Location
    Hengelo (OV)
    Posts
    39
    <<<De TdxMemData TDataSet descendant van Developer Express lijkt me niet veel anders dan. Misschien kan kbmmemtable meer of beter of sneller, het component is me niet bekend. Maar Developer Express heeft aan mij z'n betrouwbaarheid al jaren bewezen en de TdxMemData wordt met Delphi meegeleverd, daarom kende ik deze reeds. Ken je TdxMemData en zo ja, kan je de verschillen toelichten?>>>

    Klopt. Deze is zeker vergelijkbaar, en DevExpress maakt inderdaad componenten van hoogwaardige kwaliteit, toch denk ik dat de mogelijkheden van kbmmemtable uitgebreider zijn, en met de kwaliteit zit het ook wel goed. Zelf gebruik ik vaak nog een andere inmemory table van DBisam.

    Ps. Word TdxMemData bij Delphi meegeleverd ? Sinds Delphi 6 ? Ik dacht dat alleen
    geregistreerde gebruikers van 1 of meer DevExpress componenten deze er dan gratis bijkregen...

    Voor vragen over kbmmemtable kijk eens op de newsgroepen van :

    news.components4developers.com

  14. #14
    <<<Rob: Ps. Word TdxMemData bij Delphi meegeleverd ? Sinds Delphi 6 ? Ik dacht dat alleen geregistreerde gebruikers van 1 of meer DevExpress componenten deze er dan gratis bijkregen... >>>

    Het is een freeware component, als 'lokkertje' voor hun andere componenten. Hij wordt al meegeleverd sinds Delphi 4 of 5, en staat op de accompanion CD.
    Mark van der Hijden (Eindhoven)

  15. #15
    Member
    Join Date
    Nov 2001
    Location
    Hengelo (OV)
    Posts
    39
    Als we het toch over DevExpress hebben, heb je hun nieuwe framework, genaamd WebObjects, voor het maken van webapplicaties in combinatie met webbroker of websnap al gezien ? Zeer indrukwekkend!

Page 1 of 2 1 2 LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. TClientDataSet zonder provider. Hoe?
    By Markoez in forum Databases
    Replies: 2
    Last Post: 15-Oct-04, 12:53
  2. Is TClientDataSet de vervanger van TTable ?
    By Hans Brenkman in forum Databases
    Replies: 7
    Last Post: 14-Jun-04, 23:02
  3. Replies: 3
    Last Post: 05-Aug-03, 09:22
  4. Aflopend sorteren inhoud TClientDataSet
    By devreede in forum Databases
    Replies: 4
    Last Post: 15-May-03, 23:47
  5. Traagheid bij inladen TClientDataSet
    By Bas in forum Algemeen
    Replies: 3
    Last Post: 11-Jan-02, 23:05

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •