[DELPHI] Transazione master/detail su database FireBird

[123delphi321]

Ciao a tutti,

Avrei questo dubbio.

in una form inserisco dati relativi ad una fattura, quindi scrivo su 2 tabelle master e detail.
per entrambe uso la stessa transazione ed ogni volta che effettuo il POST eseguo anche il commitreatening in modo da rendere disponibili le variazioni a tutti gli utenti....

funziona discretamente bene...

vorrei, pero', dare la possibilita all'utente di confermare o annullare ''in ultimo'' tutti i dati sia del Master che del Detail.

come posso risolvere???

se dopo il post non effettuo il commit gli altri utenti ottengono errore di deadlock.

grazie in anticipo

[alka]

Originariamente inviato da 123delphi321
vorrei, pero', dare la possibilita all'utente di confermare o annullare ''in ultimo'' tutti i dati sia del Master che del Detail.
come posso risolvere???

Evita di chiamare il Commit.

Originariamente inviato da 123delphi321
se dopo il post non effettuo il commit gli altri utenti ottengono errore di deadlock.

C'è qualcosa che non quadra nella progettazione del database, in qualche stored procedure o nella visibilità attribuita alla transazione.

Non ci sono molti elementi per fare una valutazione completa.

[123delphi321]

Ciao,

ho fatto delle prove, anche con IbExpert, credo che il problema si riduca a quando due utenti modificano uno stesso record.... credo che sia questo il problema.

come posso fare per evitare che 2 utenti lavorino lo stesso record?

posso solo utilizzare try...except sull'evento 'post' o puoi suggerirmi un modo più pratico?

grazie in anticipo

[alka]

Originariamente inviato da 123delphi321
come posso fare per evitare che 2 utenti lavorino lo stesso record?

In teoria, non dovresti affatto impedire questa situazione, poiché è una delle caratteristiche peculiari dei sistemi client/server: evitare il blocco dei record.

[123delphi321]

allora devo solo controllare cosi?

try
post;
except
....altro utente sta operando sul record
end;

in questo modo il l'utente 2 per poter postare le modifiche deve attendere che l'utente 1 effettui la commit.

devo utilizzare questa tecnica?

[alka]

La "tecnica" da usare dipende dall'effetto che si vuole ottenere.

Non comprendo bene il tuo codice, dato che in generale dovresti sempre avere la possibilità di effettuare un Post anche se un altro utente sta lavorando sullo stesso record proprio perché non è necessario imporre tale blocco.

Forse i componenti IBX, che suppongo sia quelli che stai utilizzando, agiscono in modo differente.

Io generalmente uso i componenti della libreria dbExpress, accoppiati al componente TClientDataSet (che può essere adoperato anche con gli IBX, però) in modo da consentire all'utente di lavorare sempre con una "cache disconnessa" dei dati, per poter effettuare i salvataggi e le operazioni di Commit in blocco, senza comunque imporre dei "blocchi" sui record tra utenti.

[123delphi321]

ciao,

l'effetto che voglio e' quella di dare all'utente la possibilita di registrare una fattura, quindi 2 tabelle contemporaneamente Master e Details, e poi alla fine effettuarne il commit o il rollback contemporaneamente.

faccio una prova molto dettagliata e ti faccio sapere....

grazie

[alka]

Originariamente inviato da 123delphi321
l'effetto che voglio e' quella di dare all'utente la possibilita di registrare una fattura, quindi 2 tabelle contemporaneamente Master e Details, e poi alla fine effettuarne il commit o il rollback contemporaneamente.

E' sufficiente aggiungere un componente per tabella, instaurare il collegamento master/detail, avviare una nuova transazione quando si sta per inserire il documento, effettuare l'operazione di Post del record di testata, quando completo, e successivamente inserire i singoli record di dettaglio, sempre seguiti da un Post.

Si otterranno quindi un record di testata e tanti record di dettagli, memorizzati sul DB e legati alla transazione ancora attiva.

Facendo l'operazione di Commit, tutte le modifiche (inserimento del record di testata e di dettaglio ed eventuali loro alterazioni successive) verranno confermate atomicamente (o tutte o nessuna), rendendo definitivamente presenti e disponibili a tutti gli altri utenti il nuovo record di testata e i record di dettaglio correlati.