[delphi] committ/rollback di ibtransaction

[123delphi321]

ciao a tutti,

per favore chiaritemi le idee:

devo registrare un movimento di magazzino, quindi devo effettuare l'update su 2 tabelle che sono master e detail.

utilizzo InterBase ed entrambe le tabelle le ho legate alla medesima IBtransaction

chiaramente devo controllare che l'update vada a buon fine.

ho pensato di fare cosi:

procedure TForm1.okButtonClick(Sender: TObject);
begin
    try
     IBTableMaster.ApplyUpdates ;
     IBTableDetail.ApplyUpdates ;
     IBTransaction1.CommitRetaining ;
    except
     IBTransaction1.RollbackRetaining ;
    end;
end;

e' corretto in questa maniera, o ho sbagliato?

grazie

[alka]

Originariamente inviato da 123delphi321
e' corretto in questa maniera, o ho sbagliato?

Credo di capire quale sia il tuo intento. Non che si possa dire che sia giusto o sbagliato, dipende da quello che intendi fare.

Secondo la mia personalissima concezione, è sbagliato perchè gli errori che si possono verificare sono tutt'al più errori di validazione dei dati (campi non corretti o non completati, violazioni di chiave, ecc.) pertanto, se l'utente che inserisce i dati commette un errore, la Commit non deve essere eseguita (e il tuo codice è compatibile con questa situazione poichè CommitRetaining non viene richiamata se ApplyUpdates non va a buon fine), ma non si dovrebbe eseguire il Rollback in caso di errore, poichè "io" - utente - devo avere la possibilità di modificare i dati a segnalazione ricevuta e riprovare a salvarli, senza dover ripartire da capo (che, se non sbaglio, è l'effetto che ottieni richiamando la RollbackRetaining).

In definitiva, io chiamerei solamente in successione i metodi ApplyUpdates e CommitRetaining sulla pressione di OK: se il salvataggio delle modifiche non va a buon fine, esso non viene eseguito, la transazione conserva il suo stato ed è possibile correggere i dati e ritentare.

Se l'utente preme ANNULLA, in tal caso è manifesto il desiderio di interrompere l'inserimento dei dati, quindi dimenticare tutto quello che è stato digitato; in questo frangente, ha più senso richiamare RollbackRetaining e poi chiudere il form.

In linea di massima credo che la tua implementazione sia corretta, ma io starei attento a separare la modifica dei dati di testata da quelli di dettaglio...

Fatti la seguente domanda: se ApplyUpdates per i dati di testata va a buon fine ma, per qualche motivo, ApplyUpdates per i dettagli no, cosa succede?

Non ho la risposta a questa domanda, ma serve per costringerti a valutare una simile condizione e verificare che non accada nulla di indesiderato.

Solitamente, io utilizzo una finestra di dialogo per inserire dati di testata e dettaglio; quando si inserisce una nuova testata, non consento di proseguire fino a quando essa non è confermata; in caso affermativo, abilito i controlli per l'inserimento dei dettagli (quindi il record di testata, dopo essere stato inserito, entra nella fase di "Edit" piuttosto che di "Insert").

Fai qualche prova tecnica per verificare che tutto funzioni anche nei casi più...disperati.

Ciao!

[123delphi321]

per piacere spiegami questo....

nel seguente codice sta l'istruzione try/except

quindi cerco di eseguire 4 righe d'istruzioni...

se avviene un errore sulla "istruzione 2" le istruzioni 3 e 4 non vengono eseguite?

procedure TForm1.okButtonClick(Sender: TObject);
begin
    try
     istruzione 1;
     istruzione 2;
     istruzione 3;
     istruzione 4;
    except
     istruzione except;
    end;
end;

grazie

[alka]

Originariamente inviato da 123delphi321

procedure TForm1.okButtonClick(Sender: TObject);
begin
    try
     istruzione 1;
     istruzione 2;
     istruzione 3;
     istruzione 4;
    except
     istruzione except;
    end;
end;

se avviene un errore sulla "istruzione 2" le istruzioni 3 e 4 non vengono eseguite?

Quando ha luogo un'eccezione, un oggetto appropriato per identificarla viene creato e la routine si interrompe in quel punto per risalire lo stack alla ricerca del primo blocco di codice in grado di gestire tale eccezione, a partire dal punto in cui essa ha luogo.

Nel caso che hai presentato, l'istruzione 2 si trova in un blocco try...except, pertanto qualsiasi eccezione che dovesse scaturire da 1, 2, 3 e 4 viene gestita.

Se l'istruzione 2 genera un'eccezione, la routine si "interrompe" per cercare il primo blocco in grado di gestirla; in questo caso, essendo protetto con try...except, viene eseguito il codice incluso tra except...end che provvede pure ad "assorbire" l'eccezione, salvo la presenza di un'istruzione che la rilanci di nuovo (o ne rilanci un'altra).

Alla luce di tutto questo, la risposta è sì, in caso di eccezione su 2, le istruzioni 3 e 4 non vengono comunque eseguite, indipendentemente dalla presenza del try...except; il blocco try...except provvede comunque a gestire l'errore che si sarebbe altrimenti propagato in modo analogo a quello descritto alle routine chiamanti nello stack, fino ad arrivare al "gestore predefinito".

Ciao!