[Delphi] Cached Updates en requestlive onduidelijkheden

[Verwijderd]

Ik heb een programma dat gebruik maakt van cached updates, maar de werking van een aantal functies omtrend cached updates en het gebruiken van requestlive zijn mij nog niet helemaal duidelijk na het lezen van de betreffende borland delphi help:

Delphi:

procedure TForm1.ApplyButtonClick(Sender: TObject);
begin
  with CustomerQuery do
  begin
  Database1.StartTransaction;
    try
      ApplyUpdates; {try to write the updates to the database};
      Database1.Commit; {on success, commit the changes};
    except
      Database1.Rollback; {on failure, undo the changes};
    raise; {raise the exception to prevent a call to CommitUpdates!}
    end;
  CommitUpdates; {on success, clear the cache}
  end;
end;

Dit is hoe ik het begrijp:

1) Commit, rollback en commitupdates worden alleen gebruikt als er gebruik wordt gemaakt van transacties.

2) Post wordt alleen gebruikt als er geen gebruik wordt gemaakt van cached updates en doet ongeveer hetzelfde als applyupdates.

3) Een functie als bijv InsertRecord is gelijk aan:
Insert + SetFields + Post

4) Voor een insert mbv cached updates is een InsertRecord en een applyupdates nodig.

Graag commentaar op deze punten, want ben beetje in de war 
Is het verder by cached updates nog nodig om na applyupdates de cache te legen met bijv CancelUpdates?

[Verwijderd]

Het topic lijkt me toch vrij duidelijk en ik weet zeker dat genoeg mensen hier een antwoord op hebben, aan de hand van andere topics die ik gelezen heb. Vandaar dat ik 'm na twee dagen toch even schop

[Tomatoman]

Cached updates gebruik je in twee gevallen:

• als je verbinding met de database traag is en je de gegevens locaal aanwezig wilt houden;
• als je een aantal samenhangende handelingen in één keer wilt uitvoeren zonder de kans dat ze halverwege worden onderbroken.

Het eerste lijkt me duidelijk: als je vaak gegevens wijzigt, is het een stuk handiger om alle wijzigingen locaal op te slaan en ze daarna in één keer te versturen. Dat beperkt het netwerkverkeer en voorkomt onnodige vertragingen.

Het tweede punt is uit te leggen aan de hand van een overboeking per bank. Stel je voor dat de server van de bank een bedrag van rekening A naar rekening B moet overschrijven. Je wilt natuurlijk voorkomen dat er iets halverwege misgaat: dan zou A zijn geld al kwijt zijn en het werd bij B nog niet bijgeschreven. Daarom verpak je beide handelingen in een transactie, waarmee óf beide handelingen worden uitgevoerd óf geen van beide. Voor het toepassen van transacties heb je cached updates nodig.

Hieruit volgt het principe van een transactie:

1. transactie starten
2. doe handeling A (wordt bewaard in cache)
3. doe handeling B (wordt ook bewaard in cache)
4. transactie committen (gegevens uit cache naar database server sturen)
5. transactie gelukt? Zo ja, de cache wordt automatisch leeggemaakt. Zo nee, foutafhandeling.

Ook kun je cached updates gebruiken om een gebruiker eerst een aantal wijzigingen te laten doen en die pas te committen als de gebruiker op Save drukt.

[Verwijderd]

Bedankt voor het (uitgebreide) antwoord, alleen het was echter niet mijn vraag, ik weet wel wat een transactie is en waarvoor cachedupdates gebruikt worden. misschien was ik niet echt duidelijk. Even de punten toelichten:

1) Worden die functies ALLEEN gebruikt als je daadwerkelijk gebruik maakt van transacties?
2) Is bij gebruik van cachedupdates (zonder transacties). een Post nodig of is bijv "InsertRecord(blabla) en ApplyUpdates" voldoende?

Van de genoemde punten wil ik alleen even weten of ze correct zijn

Oja, ik wil eigenlijk geen Cached Updates gebruiken, maar moet wel aangezien het anders niet goed werkt om een of andere reden, zie: [rml][ Delphi] Insert probleem, query refreshed niet goed[/rml]

[ Voor 5% gewijzigd door Verwijderd op 16-09-2003 19:29 ]

[BoomSmurf]

NB: ik heb nauwelijks ervaring met CachedUpdates (ze zijn evil - ofwel in mijn situaties is het nooit nodig geweest ze te gebruiken), dus houd daar rekening mee.

1) Commit en Rollback worden inderdaad alleen gebruikt bij transacties. Ik weet niet hoe je met je database connect en met welke compenenten. Vrijwel alle databases werken met transacties (lees: de meeste kunnen niet eens zonder transacties werken). Als je met zo'n database werkt via de BDE, dan zal de BDE automatisch een transactie voor je starten en committen, alleen merk jij daar zelf niks van. (StartTransaction, CommitRetaining en RollbackRetaining horen trouwens ook bij het rijtje Commit en Rollback)

2) Post wordt altijd gebruikt om een gewijzigd record 'vast te leggen'. Ofwel in de cache bij CachedUpdates (IIRC) ofwel in de database zelf. Dit is volgens mij bij InsertRecord niet nodig, als ik het me goed herrinner is jouw punt 3 nl. correct in is de post daarbij al inbegrepen. Post gebruik je dus heel erg vaak (als je niet met direct SQL records in de DB verandert en niet constant InsertRecord gebruikt).

3) IIRC, is dit correct

4) De ApplyUpdates of CommitUpdates zijn nodig om je wijzigingen permanent in de database vast te leggen.

Als je liever geen CachedUpdates wilt gebruiken zul je toch je andere probleem op moeten lossen. Let wel, ik weet ook niet wat het probleem. Zelf maak ik voornamelijk gebruik van IBX dus met de quirks van de normale database componenten ben ik niet zo bekend.

Je wilt de open/close niet gebruiken, omdat je je cursor niet kwijt wilt raken? Ook hier is een workaround voor, 't is niet pretty, maar zolang je dataset's niet zo groot zijn kun je het volgende doen:

code:

var PrimaryKey: String;
begin
  DataSet.DisableControls; { zorgt ervoor dat je controls dalijk niet zomaar 'switchen' van content }
  PrimaryKey := DataSet.FieldByName('mijnPK').AsString;
  DataSet.Close;
  DataSet.Open;
  DataSet.Locate(PrimaryKey, Flags); { effe de flags die voor jou van toepassing zijn locaten }
  DataSet.EnableControls; { controls op je scherm updaten }
end;

Hopelijk kun je met dit alles wat

[Verwijderd]

Kan ik zeker wat mee, bedankt voor het uitgebreide antwoord.

Proggen dan maar weer