[SQL/Delphi] Record veranderd?

[jelmervos]

Ik wil weten of de gegevens die de gebruiker kan bewerken anders zijn dan de gegevens in de database (een record).

De gebruiker kan bepaalde gegevens veranderen, bijvoorbeeld klant gegevens. Maar als hij dan bijvoorbeeld iets doet waardoor de wijzigingen verloren kunnen gaan (programma sluiten) dan moet hij zeggen of de wijzigingen doorgevoerd moeten worden of niet.
Ik moet dus controleren of de gegevens die op het scherm staan anders zijn dan in de database.
Hoe kan ik dit het beste doen?

Alvast bedankt.

[whoami]

Je wilt dus controleren of een gebruiker zelf zijn gegevens heeft veranderd die hij op het scherm staan heeft, of wil je kijken of een andere gebruiker de gegevens reeds gewijzigd heeft die nu nog open staan bij die gebruiker? (Hoop dat je dat laatste snapt ). Volgens mij is dat laatste niet mogelijk doordat de database de records gaat locken, dus beperk ik me maar tot het eerste geval.

Ik hou altijd een boolean variable FHasChanged ofzo bij. Bij het oproepen van het scherm (de gegevens komen net uit de databank en worden getoond), zet ik die variable op False. In de OnChange event-handler van al m'n textboxen en andere controls zet ik die variable op True.
Zo weet je of hij de gegevens veranderd heeft en of ze moeten gesaved worden.

[jelmervos]

Het gaat idd om het eerst: single user systeem.

Dat OnChange idee snap ik, heb ik ook vaak gehanteerd. Maar het heeft als nadeel dat je elke tekst box die zelfde event moet geven. En verder moet je bij een nieuwe tekst box er om denken die event er aan toe te kennen.

Zou het niet mooier zijn om gewoon te checken of de gegevens veranderd zijn door middel van de database? Dus zoiets als dit: gewoon een select doen met de misschien veranderde data als WHERE, en zodra RecordCount = 0 dan is er veranderd. Er moet dan wel een ID per record zijn, maar dat is geen probleem.

Wat ook een oplossing is, is een eigen TEdit maken die bijvoorbeed automatisch een bericht stuurt naar de form zodat die een boolean op true (IsChanged) kan zetten. Maar dit is in mijn ogen een beetje overkill.

[whoami]

Op dinsdag 28 mei 2002 14:37 schreef jelmervos het volgende:

Dat OnChange idee snap ik, heb ik ook vaak gehanteerd. Maar het heeft als nadeel dat je elke tekst box die zelfde event moet geven. En verder moet je bij een nieuwe tekst box er om denken die event er aan toe te kennen.

Tja, als programmeur moet je an zoveel denken

Je kan toch alle OnChange event-handlers naar dezelfde functie laten wijzen? En het is eigenlijk de taak van de programmeur om dat niet te vergeten dat er een bepaalde property ed moet gezet worden.

Zou het niet mooier zijn om gewoon te checken of de gegevens veranderd zijn door middel van de database? Dus zoiets als dit: gewoon een select doen met de misschien veranderde data als WHERE, en zodra RecordCount = 0 dan is er veranderd. Er moet dan wel een ID per record zijn, maar dat is geen probleem.

Ik vind van niet. Zo heb je iedere keer weer een query nodig vooraleer je wilt gaan saven.

[jelmervos]

Dus dan toch maar een standaard OnChange event toekennen.
Alleen is dat ook een beetje onhandig als je daar voor 1 Edit een eigen event aan toe wilt kennen. Maar is uiteraard ook op te lossen.

Ik kies eerst deze oplossing wel.

Bedankt voor je reacties en mening.

[Verwijderd]

Wat ik ook wel doe is het volgende:

Ik maak een record met dezelfde structuur als een record in de database dus bv:

code:

  type
    TMyData = record
    RID: Integer;
    RName: string;
    RDescription: string;
    end;

[Ik prefix record-fields met R]
Als een gebruiker dan een record wil veranderen; lees ik die record in en zet de data bv in een var OldData van type TMyData. OldData gebruik ik dan om de visuele componenten te vullen.

Drukt de gebruiker dan op OK oid dan vul ik een nieuwe var [bv NewData] met de gegevens in de visuele componenten. Deze NewData vergelijk ik met OldData, etc.

[Delphi32]

Ik gebruik ongeveer een mengvorm van de methode-whoami en methode-DiFool

Ik maak meestal classes aan die de database-tabellen gaan representeren. Voordeel is dat ik dan van class- en objecttechnologie gebruik kan maken in iets wat uit de database afkomstig is. Object-relational mapping zeg maar.

Dan gebruik ik de OnChange-handlers van de editboxen op mn scherm om de door de gebruiker ingevoerde waarden terug te zetten in mn object. In de write-methode van de properties van de class zorg ik dat de state van het object wordt bijgewerkt. Oha is dat dan iets van

code:

TObjectState = (osLoaded, osNew, osChanged, osDeleted);

Naast deze class heb ik dan 1 class (vaak een DataModule) die de persistentie van deze class gaat regelen. De DataModule levert dan op aanvraag 'geladen' objecten, of juist nieuwe(lege), en is in staat ze op correcte wijze op te slaan.

Voordeel: niet gebonden aan een zekere table definition, niet gebonden aan db-aware controls, de mogelijkheid om business logica in mn business objecten te stoppen, retesnel, superflexibel.
Nadeel: iets meer code dan gewoon gebruik maken van TDataSet, TDataSource en TDBEdit.

Bij kleinere projecten wil ik wel een iteratieve methode gebruiken: ik zet een eerste versie in elkaar die van db-aware controls aan elkaar hangt (snelle controle of alles qua datastructuur een beetje klopt), en in de tweede versie bouw ik alles weer net zo hard om in classes (als de GUI werking aan de beurt komt)

[whoami]

Ik moet zeggen, dat is een mooie oplossing.