Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 16 to 30 of 43

Thread: autoincrement veld vullen via clientdataset

  1. #16
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Dat snap ik wel Benno, maar Hans haalt 1 record op, verandert deze en schrijft hem weer weg naar een tabel. Kortom: Open connectie naar database, sluit connectie, verander record, applyupdates, open connectie, sluit connectie. Heb je dan een voordeel met CDS?
    Bij een rechtstreekse verbinding naar een tabel is de connectie open en blijft open totdat de record weer is weggeschreven.
    Volgens mij was de bedoeling van een offline model om zo weinig mogelijk netwerkverkeer naar de database te krijgen.
    Delphi is great. Lazarus is more powerfull

  2. #17
    TDigitalTrain user Hans Brenkman's Avatar
    Join Date
    Mar 2002
    Location
    Weert
    Posts
    1,861
    Als het anders zou moeten zoals ik het nu doe, hoor ik het graag.

    Ik kan me er alleen weinig bij voorstellen dat je een CDS met een gehele tabel (of meerdere CDS-sen met gehele tabellen in geval van een master-detail relatie) in memory hebt, waaruit de gebruiker 1 record kiest om te bewerken.

    Ik gebruik wel een CDS met veel records (bijv. alleen klantnamen) als ik de gebruiker uit een scherm een record laat kiezen om te bewerken. Daarna haal ik dat ene record op voor een ander CDS.

    Ik ben ook in de veronderstelling dat 1 record wegschrijven naar de database (alleen de gewijzigde velden) en/of 1 record ophalen peanuts zijn voor zowel de database als het netwerkverkeer, maar misschien heb ik het mis.
    Testen kan niet de afwezigheid van fouten aantonen, slechts de aanwezigheid van gevonden fouten.

    Het is verdacht als een nieuw ontwikkeld programma direct lijkt te werken: waarschijnlijk neutraliseren twee ontwerpfouten elkaar.

  3. #18
    Ik haal inderdaad ook zoveel mogelijk een enkel record op, wijzig dat en schrijf het weer weg. Je moet niet teveel data ophalen, ten eerste omdat dat veel netwerkverkeer is, ten tweede omdat data oud is op het moment dat je het ophaalt.

    Dus ik geef de gebruiker over het algemeen een readonly lijstje met alle regels, maar een beperkt aantal velden waarmee de juiste regel gevonden kan worden. In een detailscherm worden dan alle gegevens van de betreffende regel (en alleen die regel) opgehaald, getoond en bij het sluiten weer opgeslagen.
    Marcel

  4. #19
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Natuurlijk niet Hans, je eigen manier is de beste manier en jij zal wel veel langer werken met CDS om te bepalen wat het beste is. Ik zie de reden ook niet om meerdere records te wijzigen om vervolgens een hele batch naar de database te sturen.

    Maar begrijp mij niet verkeerd. Het is niet de bedoeling om je onderuit te halen. Ik probeer continue het hele verhaal over CDS met zijn provider te volgen en spring niet altijd de discussie in. Maar ja, het is mijn eigen topic.

    Ik probeer nog steeds uit te vinden wat nu daadwerkelijk mijn winst is; door gebruik te maken van CDS of direct. Als ik 1 record ophaalt en deze weer wegschijft, zie ik daar geen winst in. Dat kan ik ook direct doen. Het enige nadeel wat ik hier zal ondervinden is de constante link van de dataset naar de tabel. Deze link wordt trouwens alleen maar gebruikt bij insert / update en delete. Wat ik dan ook raar vind (en dat verzin ik nu ter plekke, want dat komt in mij op) is dat je een connectie opent naar de database, de dataset van de query vult en deze weer doorgeeft naar de dataset van de CDS, zodat de dataset van de query weer gesloten kan worden. Maak ik dan niet te veel gebruik van resources om tijdelijk twee datasets te hebben om hetzelfde resultaat te krijgen als één dataset met een directe verbinding?
    Delphi is great. Lazarus is more powerfull

  5. #20
    TDigitalTrain user Hans Brenkman's Avatar
    Join Date
    Mar 2002
    Location
    Weert
    Posts
    1,861
    @jkuiper, ik ben op mijn werk al bijna 17 jaar de enige programmeur. "Sparren" met een ander is vrijwel alleen mogelijk via NLDelphi, waar ik dan ook dankbaar gebruik van maak. Daarmee wil ik ook aangeven dat ik open sta voor de mening van een ander, en als ik het doe op een onjuiste manier of iets kan beter, dan ga ik daar over het algemeen graag in mee. Waarom ? Omdat ik me wil conformeren waarvoor en hoe het bedoeld is om mee te werken. Uitwisseling van code hier op het forum en evt. voor een andere programmeur is daarmee een stuk gemakkelijker.

    Maar begrijp mij niet verkeerd. Het is niet de bedoeling om je onderuit te halen.
    Ik begrijp je niet verkeerd, zo had ik het zeker niet opgevat

    Ik weet eigenlijk niet beter, dan bij een RDBMS de CDS te gebruiken. Ik ben van "direct" afgestapt toen ik afscheid van Paradox-tabellen heb genomen.

    Ik heb toen behoorlijk wat gelezen over de CDS o.a. het artikel van Marcel en 10 uitgebreide artikelen van Cary Jensen over de CDS. Die zwerven nog wel ergens op codegear maar ze zijn niet gemakkelijk meer te vinden. Als je ze van mij wilt hebben (pdf's) dan moeten die op de een of andere manier wel bij jou te krijgen zijn (het 1e artikel heet "A clientdataset in every database application" )
    Testen kan niet de afwezigheid van fouten aantonen, slechts de aanwezigheid van gevonden fouten.

    Het is verdacht als een nieuw ontwikkeld programma direct lijkt te werken: waarschijnlijk neutraliseren twee ontwerpfouten elkaar.

  6. #21
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Ik heb toen behoorlijk wat gelezen over de CDS o.a. het artikel van Marcel en 10 uitgebreide artikelen van Cary Jensen over de CDS. Die zwerven nog wel ergens op codegear maar ze zijn niet gemakkelijk meer te vinden. Als je ze van mij wilt hebben (pdf's) dan moeten die op de een of andere manier wel bij jou te krijgen zijn (het 1e artikel heet "A clientdataset in every database application" )
    Nou, ik heb er wel oren na. Om dit moment maak ik bijna geen gebruik van CDS, omdat mijn werkgever recordlocking wilt en dat gaat nu eenmaal niet met CDS. Maar mijn volgende projecten wil ik er wel naar kijken en uitproberen.
    Delphi is great. Lazarus is more powerfull

  7. #22
    omdat mijn werkgever recordlocking wilt en dat gaat nu eenmaal niet met CDS
    Hmmm kan dat nog met moderne databases? Wat voor database gebruiken jullie John?

  8. #23
    TDigitalTrain user Hans Brenkman's Avatar
    Join Date
    Mar 2002
    Location
    Weert
    Posts
    1,861
    Ik heb je een prive-bericht gestuurd voor je mailadres voor de pdf's.

    Wat recordlocking betreft op een RDBMS; zover mij bekend is het lastig (of misschien zelfs onmogelijk), juist omdat je geen permanente open cursor naar een record in een tabel hebt.

    In de app waarin meerdere gebruikers snel achter elkaar hetzelfde record bewerken, heb ik dat "opgelost" door records die in behandeling zijn in een tabel te registreren (tabelnaam, record id, user, tijdstip). Zo kan ik doorgeven aan een persoon die juist dat record ook wil bewerken, wie en hoelang dat record al in gebruik heeft, zodat er geen 2 CDS-sen zijn (op 2 verschillende werkplekken) met data van hetzelfde record.
    Dit systeem is natuurlijk niet waterdicht. Als de pc crasht of zonder netjes af te sluiten uit wordt gezet, blijft het record volgens de tabel gelocked. Daarom laat ik 's nachts een job (de data staat in een Oracle database) draaien die de "locking"tabel leeg maakt en alle records in ieder geval de volgende dag weer beschikbaar zijn.
    Testen kan niet de afwezigheid van fouten aantonen, slechts de aanwezigheid van gevonden fouten.

    Het is verdacht als een nieuw ontwikkeld programma direct lijkt te werken: waarschijnlijk neutraliseren twee ontwerpfouten elkaar.

  9. #24
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Quote Originally Posted by Benno View Post
    Hmmm kan dat nog met moderne databases? Wat voor database gebruiken jullie John?
    MySQL 5.1
    Delphi is great. Lazarus is more powerfull

  10. #25
    Ik gebruik voor het locken een heel simpele en toch goede techniek: bij het aanpassen van bijvoorbeeld klantgegeven laat ik gewoon veld per veld wegschrijven naar de database.
    Op het moment van een "Start Edit" wordt het nieuwe record van de database gehaald. Telkens bij het aanpassen van een veld wordt dit weggeschreven naar de database. Indien dit reeds aangepast was door iemand anders, krijg ik een foutmelding. Dit is weinig werk en werkt altijd.

  11. #26
    TDigitalTrain user Hans Brenkman's Avatar
    Join Date
    Mar 2002
    Location
    Weert
    Posts
    1,861
    Hmmm, als ik je goed begrijp kun je wel zo met meerdere tegelijk hetzelfde record muteren. Het ligt er maar aan welke velden de ene persoon en de andere persoon muteerd. Doe je dan ook een refresh voor een ander als een persoon telkens een veld wijzigd, zodat de data op het scherm bij die ander actueel is ?

    Je blijft in ieder geval niet onverhoopt met gelockte records zitten die niet meer in gebruik zijn (door een crach van een pc ofzo), maar volgens een tabelletje wel gelocked zijn.
    Testen kan niet de afwezigheid van fouten aantonen, slechts de aanwezigheid van gevonden fouten.

    Het is verdacht als een nieuw ontwikkeld programma direct lijkt te werken: waarschijnlijk neutraliseren twee ontwerpfouten elkaar.

  12. #27
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Quote Originally Posted by Handsaeme View Post
    Ik gebruik voor het locken een heel simpele en toch goede techniek: bij het aanpassen van bijvoorbeeld klantgegeven laat ik gewoon veld per veld wegschrijven naar de database.
    Op het moment van een "Start Edit" wordt het nieuwe record van de database gehaald. Telkens bij het aanpassen van een veld wordt dit weggeschreven naar de database. Indien dit reeds aangepast was door iemand anders, krijg ik een foutmelding. Dit is weinig werk en werkt altijd.
    En wat is dan je performance ten opzichte van de hele record wegschrijven?
    Delphi is great. Lazarus is more powerfull

  13. #28
    Als je met tienduizend personen simultaan het personeelsbestand zit aan te passen, dan zal dit (misschien ) merkbaar wel zijn, voor een paar gebruikers maakt dit niets uit. werken met een registratietabel kost ook tijd.

    Laat dit duidelijk zijn, het gaat hier niet over de intensieve taak-verwerking, gewoon over occasioneel het aanpassen van een telefoonnummer of adresgegevens bij een klant, gewoon het omzeilen van het lock-gedoe.

  14. #29
    gewoon het omzeilen van het lock-gedoe.
    Het lijkt me op jouw manier wel riskant om je data consistent te houden. Meestal heb je regels die gelden voor de set data. Als je steeds een veld kunt aanpassen lijkt me dat lastig.

    Zelf lock ik zelden, meestal is het niet nodig. Vroeger met de files based databases moest je dat wel doen.

    Ik gebruik zelf meestal een timestamp die ik aan de serverkant test en vul. Is je eigen record gewijzigd in de database sinds jij ging editen, dan krijg je een melding. Je kunt dan kiezen toch de door een ander gewijzgde data te overschrijven.

  15. #30
    Hmmm, als ik je goed begrijp kun je wel zo met meerdere tegelijk hetzelfde record muteren. ... Doe je dan ook een refresh voor een ander als een persoon telkens een veld wijzigd, zodat de data op het scherm bij die ander actueel is ?
    Inderdaad, ik doe telkens een fetch van het actuele record in de dataset. Het is in veel gevallen soms echt nodig om verschillende velden terzelfdertijd te kunnen aanpassen, zoals in produktiesystemen.
    Op de werkvloer gebruik ik het ook, maar dan wegens een andere reden: de afwezigheid van de save-knop want die wordt altijd vergeten.

    Het lijkt me op jouw manier wel riskant om je data consistent te houden. Meestal heb je regels die gelden voor de set data. Als je steeds een veld kunt aanpassen lijkt me dat lastig
    Ik heb daar twee events voor: BeforeWriteField en AfterwriteField. Met het eerste event kan ik nog een cancel doen.

    Ik gebruik zelf meestal een timestamp ... data te overschrijven.
    Ik heb deze property vroeger ook gebruikt, maar nu laat ik dat achterwege. Wat is de kans dat je met twee personen terzelfdertijd bij dezelfde klant een andere telefoonnummer zit in te vullen?

Page 2 of 3 FirstFirst 1 2 3 LastLast

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
  •