Results 1 to 6 of 6

Thread: Enkele master-detail vragen / clientdataset

  1. #1

    Enkele master-detail vragen / clientdataset

    Hi,

    Ik heb een eenvoudige master - detail opstelling waar ik vreemde zaken bespeur.

    Als ik scrol in de DBGrid (master gedeelte) krijg ik de melding key violation. Verder zie ik zeer frequent bij het scrollen de zandloper.
    Als ik een voor een "scroll" krijg ik geen key violation. Alleen als ik aan het muis scroll wheeld raai of een pijltjestoets ingedrukt houdt.
    Verder. Het "scrollen" in de master tabel lijkt heel traag te gaan. Telkens een zandloper. Het ophalen van detail gegevens, ook al is het 10000 stuks, gaat super snel.

    Mijn situatie

    DBX Query die SELECT * doet van een MySQL tabel. De poort van de MySQL tabel is wel geforward naar een remote locatie op het net via SSH/Putty/Tunnel. Echter, we hebben een snelle internet verbinding.
    Datasetpovider, clientdataset, datasource. Databse is inclusief key field.

    De detail query is een query met een parameter, naar de ID in de master tabel. Ook weer gekoppeld aan een provider en een clientdataset.

    Ik vraag me af of ik niet gewoon tables moet gebruiken. Het probleem is dat alleen bepaalde tabellen groot zijn of relatief groot: miljoen regels oid. Dat lijkt me overkill als het om een paar regels gaat die nodig zijn mbt het detail gedeelte.

    Dank!

    Rogier

  2. #2
    Het key violation verhaal: Op de detail clientdataset zit een filter. Als ik deze aanzet en ga scrollen komt de foutmelding. Het gekke is dat de filter niets anders is dat een datum filter.
    Ook lijkt het direct te ontstaan als een leeg resultaat moet worden gefiltered, tenminste, als je scrollt.

  3. #3
    Is je database goed opgezet, het klinkt of niet iedere detail een master heeft. Heb je een primary key op de master en een foreign key contraint?

    Wat gebeurd er als een paar master details handmatig test met SQL en een WHERE clause?

    Het kan ook zijn dat je de master-detail setup niet op het juiste veld hebt gedaan, waardoor het bij sommige scroll acties wel goed gaat en bij sommige niet.

    Misschien dat je in de logfiles van de database server iets kunt zien.

  4. #4
    HI,

    Dank voor het antwoord.

    Het key violation probleem heeft in ieder geval met de filter te maken. Ofschoon ik niet begrijp dat een filter een key violation kan creëren.

    Om eerlijk te zijn heb ik me nog nooit verdiept in een foreign key constraint. Dat is toch een speciaal soort index in de database zelf (buiten Delfphi) ?

    Master detail setup lijkt goed te staan.

    Test met een gewone query: super snel. Een JOIN is ook nog steeds super snel.

    De test Database bestaat uit 15 masterrecords en iets van 100.000 detail records (als test).

    Gevoelsmatig heeft het iets te maken met de verbinding naar de remote server.

    Als ik het detail gedeelte uitschakel is het scrollen betrekkelijk snel ofschoon ook niet super?

    DBGRID. Loopt dat component niet stiekem van alles te activeren dat dan door enige vertraging in een loop komt??

    Dank!

    Rogier

  5. #5
    Om eerlijk te zijn heb ik me nog nooit verdiept in een foreign key constraint. Dat is toch een speciaal soort index in de database zelf (buiten Delfphi) ?
    Een foreign key constraint zorgt ervoor dat een record in een kindtabel altijd een verwijzing heeft naar één record in de ouder tabel. Bijvoorbeeld een order hoort bij één klant en je kunt geen orders zonder klant hebben. Zonder foreign key constraint kun je dit niet afdwingen. Het gevolg is dan dat je orders krijgt zonder klant, wat je niet wilt.

    Echt wel even iets om naar te kijken als je bezig wilt gaan met databases. Ik kan je uit ervaring vertellen dat een goed ontworpen database een heel hoop gedoe scheelt.

    Ik zou echt eerst je database aanpassen met de juiste primary en foreign keys en dan kijken of je probleem nog bestaat. Het zou kunnen zijn dat het id veld van je master bijvoorbeeld meerdere keren voorkomt of dat er geen master bij een bepaalde detail hoort.

    Heb je op de master wel een primary key staan?

    De test Database bestaat uit 15 masterrecords en iets van 100.000 detail records (als test).

    Gevoelsmatig heeft het iets te maken met de verbinding naar de remote server.
    Als je ongeveer 6 á 7 duizend records hebt in de detail, dan kan dat wel even duren. Het is volgens mij niet gebruikelijk om zoveel details op te halen... Zeker als je door de master gaat scrollen vertraagt dit de boel enorm.

  6. #6
    Het voordeel van een foreign key constraint is dat je bijvoorbeeld ON DELETE CASCADE kunt doen. Dan worden bijvoorbeeld bij het verwijderen van een relatie ook automatisch alle contactpersonen daarvan verwijderd. Dan hoef je dat dus niet zelf in code te doen. Voor een Order / Klant relatie zou ik dat natuurlijk niet doen. Laat de database maar een mooie foutmelding geven als je een Klant probeert te verwijderen waar nog een order aan hangt.

    (Dat is overigens ook de reden waarom wij aan klanten een "zichtbaar" veld hebben hangen. Dan kunnen we die wel verbergen zonder de orders te hoeven verwijderen.)

Thread Information

Users Browsing this Thread

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

Tags for this Thread

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
  •