Page 3 of 3 FirstFirst 1 2 3
Results 31 to 43 of 43

Thread: autoincrement veld vullen via clientdataset

  1. #31
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    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?
    In een klantenbestand misschien niet, maar in een productiesysteem wel. Ondanks dat men in verschillende schermen werkt, kan men wel in de zelfde bestand muteren.
    Delphi is great. Lazarus is more powerfull

  2. #32
    In een productiesysteem is dit inderdaad zo. Het typische voorbeeld is een order die door een machine gaat.

    Op bijna hetzelfde moment wordt hetzelfde record aangepast door verschillende programma's, echter de velden zijn verschillend en daardoor heb je er geen last van. Vroeger deed ik dat niet en had heel wat problemen met deadlocks.

  3. #33
    Delphi & OO in Vlaanderen SamWitse's Avatar
    Join Date
    Sep 2007
    Location
    Brussel
    Posts
    833
    De hele discussie hier gaat over record locking technieken, en wat als een update gebeurt op data die ondertussen door iemand anders gewijzigd is.
    Met een CDS vergroot de kans op dit laatste enorm omdat je data lokaal bijhoudt.

    Ik zou het raar vinden mocht hierover geen allesomvattende documentatie bestaan met alle mogelijke technieken met voor- en nadelen.
    Kent iemand dergelijke info? Liefst in het Nederlands, of op z'n minst toch niet in het Duits.
    Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.

    Sam Witse.
    Delphi & OO in Vlaanderen

  4. #34
    senior member PeterVercruysse's Avatar
    Join Date
    Nov 2006
    Location
    Rijsel
    Posts
    1,608
    Ik laat de technieken van locking op de databases weg, daarvan is er genoeg documentatie te vinden.

    Voor de record-locking in combinatie met Delphi bestaan er een aantal technieken, verschillend van aard en allemaal met hun voor- en nadelen.

    1. Gebruik makend van de locking van de database: soms kun je er niet onderuit, maar veel programmeurs zijn hier niet echt gelukkig mee. Een van de voornaamste nadelen is dat de programmeur er zelf geen vat op heeft.

    2. Locking in de tabel: Er wordt een afzonderlijk veld gebruikt om te locken, in sommige gevallen is dit een bit ( boolean ) in de meer uitgebreide gevallen gaat men hier de naam gaan inschrijven van de lockende persoon, wat heel wat voordelen heeft. Soms gaat men werken met een afzonderlijk lockingtabel.

    Dit werkt wel prettig maar dit heeft enkele nadelen:

    >> Indien iemand naar huis gaat of te maken heeft met een abnormaal afsluiten van zijn programma, heeft het probleem dat zijn record gelocked blijft voor onbepaalde tijd. Op de lange duur is het programma niet meer werkbaar.

    >> Om te locken heb je supplementaire queries nodig.
    >> Een voordeel is dat batch-programma's, stored procedures, triggers intelligent genoeg kunnen gemaakt worden om met de locks te gaan rekening houden.

    3. Locking in de applicatie. Wat je nog moeilijk locking kunt noemen. Het principe komt op het volgende neer: Een record wordt opgehaald van de database, soms opnieuw opgehaald net voor het aanpassen en staat klaar om te worden gewijzigd. Bij het wegschrijven wordt het record maar net zo lang gelocked zodat het record veilig kan weggeschreven worden. Tenminste dat is de theorie.

    >> Het probleem heb je niet meer dat een record niet meer door anderen kan worden aangepast, maar wel dat iemand anders reeds gedaan heeft. Er bestaan hierbij een aantal technieken om daar op in te spelen:

    1. FetchBeforeEdit: Net voordat je gaan aanpassen wordt het record opnieuw opgehaald, dit zorgt er voor dat de tijd tussen lezen en schrijven korter wordt
    2. Controle bij het wegschrijven van het record: Indien je je record in zijn geheel gaat wegschrijven, kun je controleren op het record is gewijzigd. Dit kan heel eenvoudig door het controleren zijn DateTimeStamp. Indien dit zo is wordt een waarschuwing gegeven. In principe zouden enkel de gewijzigde velden mogen worden weggeschreven.
    3. Veld per Veld wegschrijven: Dit is hierboven ook aangehaald. Hierbij kan bij het veld per veld wegschrijven gecontroleerd worden op het veld gewijzigd is. Hierbij wordt het veld opnieuw opgehaald van de database en vergeleken. Dit is de meest flexibele oplossing, maar is wel zwaarder.
    Last edited by PeterVercruysse; 04-Feb-09 at 20:23.
    Gras groeit niet sneller door er aan te trekken

  5. #35
    Op bijna hetzelfde moment wordt hetzelfde record aangepast door verschillende programma's, echter de velden zijn verschillend en daardoor heb je er geen last van. Vroeger deed ik dat niet en had heel wat problemen met deadlocks.
    Het is natuurlijk de vraag of je een state van een product in zijn productiecyclus vast moet leggen in 1 record.

    Persoonlijk zou ik voor een product dat door een productiecyslus loopt kiezen voor een losse tabel in plaats van 1 record steeds aanpassen. In je business laag kun je dan makkelijk de state afleiden uit die records.

    Als je alles opslaat in 1 record, krijg je nooit een verifiieerbaar productieproces.

  6. #36
    De produktiestatussen zelf gebeuren door een append, niet een update. Maar het probleem waar ik mee geconfronteerd wordt is anders.

    Heel simplistisch voorgesteld zou ik het zo kunnen omschrijven. Stel nu dat je van een plaat de breedte en de lengte moet meten en dit inlezen. Het uitlezen van de breedte is altijd op hetzelfde tijdstip, het uitlezen van de lengte is afhankelijk van de lengte van de plaat. Het kan dus gebeuren dat ze beide terzelfdertijd worden aangepast.

    Zaken zoals lengte, breedte, gewicht, ... zitten samen in één record, wat logisch is. Ik ben niet van plan om mijn datamodel aan te passen omdat dit technisch beter uitkomt.

  7. #37
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Ik herken dit probleem
    Delphi is great. Lazarus is more powerfull

  8. #38
    De methode die ik beschreven heb werkt wel goed, tot nu toe geen problemen mee gehad. Ook niet in produktie, maar daar ga ik niet verifiëren of het record gewijzigd is, want in de praktijk kan dit zelfs niet.

    Ik heb nog niet op je post #1 geantwoord: Als ik een nieuw record toevoeg ( met bijvoorbeeld een append of via een query), dan wordt in autoincrement-veld de waarde die door de database gegenereerd is, automatisch ingevuld. Ik heb er dus nooit geen last van.

  9. #39
    Silly member NGLN's Avatar
    Join Date
    Aug 2004
    Location
    Werkendam
    Posts
    5,133
    Quote Originally Posted by jkuiper View Post
    Wat moet ik doen om toch records in mijn TClientdataset te zetten met een autoincrement veld?
    Hier kan met MS SQL Server een autonummeringsveld (Identity, Primary Key, Int) als volgt probleemloos ingevuld worden vanuit Delphi, ook bij meerdere records:

    - ADODataSet: CursorLocation = clUseClient, CursorType = ctKeySet, Locktype = ltOptimistic, ExecuteOptions = [] (dit is allemaal de standaard instelling, weet niet in hoeverre relevant), CommandText = SELECT * FROM View
    - DataSetProvider: UpdateMode = upWhereChanged, ResolveToDataSet = False, Options = [] (ook allemaal standaard)
    - ClientDataSet: StoreDefs = True, IndexDefs = {DEFAULT_ORDER, CHANGEINDEX} (zijn autom. aangemaakt, beide met standaard instellingen)
    - IDField: Attributes = ReadOnly, DataType = ftAutoInc
    Last edited by NGLN; 06-Feb-09 at 00:52. Reason: typo
    (Sender as TNLDUser).Signature := 'Groeten van Albert';

  10. #40
    Zaken zoals lengte, breedte, gewicht, ... zitten samen in één record, wat logisch is. Ik ben niet van plan om mijn datamodel aan te passen omdat dit technisch beter uitkomt.
    Dat zal wel van de specifieke situatie afhangen. Zelf zou ik zo'n record in productie automatisering in 1 keer wegschrijven. Als de data toch bij elkaar hoort en in 1 record zit heeft het volgens mij geen nut je consistentie op te offeren (je weet nu immers nooit de toestand van je database omdat je delen van een record muteert). Als je bijvoorbeeld een noodstop krijgt en vervolgens handmatig de plaat moet verwijderen uit je lengtemeetstation heb je meteen een inconsistente database.

    Maar goed jouw oplossing werkt kennelijk voor jou dus laten we maar niet verder afwijken van het oorspronkelijke onderwerp.

  11. #41
    De lengte- en breedte-meting zijn twee verschillende programma's, en daar zit net het probleem.

  12. #42
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Ik blijf een poging wagen om clientdatasets te combineren met T()Query om meerdere records weg te kunnen schrijven.
    Om niet alle problemen neer te zetten begin ik met de eerste.
    Mijn clientdataset steeds met deze melding als ik een tweede record wil toevoegen. De autoincrementveld wordt niet gevuld. Doe ik dat wel, dan gebruik de database die waarde en dat is niet de bedoeling.
    Delphi komt met de volgende melding
    message Code:
    1. ---------------------------
    2. Debugger Exception Notification
    3. ---------------------------
    4. Project horses.exe raised exception class EDBClient with message 'Key violation.'.
    5. ---------------------------
    6. Break   Continue   Help  
    7. ---------------------------
    Wat moet ik nu invoeren om toch twee records te krijgen zonder een keywaarde in te voeren. Om een select te maken buiten de primary key om is niet logisch. Om dan een record te updaten, maakt de T()Query gebruik van alle velden om tot een uniek record te komen, terwijl je dat toch met de primary key wil.

    PS. Ik heb de 10 PDF's van Carry Jensen gelezen, maar gaven mij niet de input die ik nodig had om verder te gaan.
    Delphi is great. Lazarus is more powerfull

  13. #43
    Je hebt helemaal geljk, dat blijft een vervelend probleem van het gebruik van ClientDataSets. Ik vul dan altijd de key met -RecNo zodat er in elk geval een waarde in de dataset staat en er geen Key violation meer komt. Aan de serverkant haal ik vervolgens de pfInUpdate weg van het betreffende veld zodat deze niet wordt meegestuurd in het INSERT statement.
    Marcel

Page 3 of 3 FirstFirst 1 2 3

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
  •