Newsgroup: it.comp.lang.vo-clipper
Titolo: [VO] Tema: Transazioni e Rollback

Ciao a tutti,
prima di occuparmi dell'oggetto suindicato vorrei ringraziare personalmente
tutti quelli che hanno aderito alla mia iniziativa.
Ho inserito la parola "tema" nell'oggetto per segnalare che il contenuto del
messaggio non è una richiesta d'aiuto.
Quando parliamo di database è impossibile non parlare di transazioni. Non so
se il termine è esatto, per transazione intendo un processo a cascata con il
quale vengono aggiornati due o piu archivi.
Esempio:
Un'operazione di vendita (n. 2 PC) determina lo scarico dal magazzino del
prodotto ceduto.
Se usiamo un archivio per i movimenti di magazzino e un archivio per le
quantità in giacenza (n. 8 PC), dopo aver fatto l'operazione nel primo
archivio, dovremo aggiornare la quantita in giacenza memorizzata nel secondo
archivio (n. 6 PC).
Eliminando il record di movimentazione nel primo archivio, la giacenza
indicata nel secondo archivio dovrebbe essere ripristinata (n. 8 PC).
Per avere i saldi dei prodotti in giacenza potremmo anche eliminare il
secondo file ed eseguire il conteggio sui record del primo archivio.
Procedura, quest'ultima, sicuramente meno rapida ma facile da gestire. Sono
sicuro che i totali sono esatti.
Se invece uso la tecnica dei due file, devo essere sicuro che i totali
contenuti nel secondo file siano correttamente aggiornati aggiungendo,
modificando ed eliminado i record del primo archivio.
Le vostre considerazioni !!!
Ciao

 modificando ed eliminado i record del primo archivio.
Esattamente. Ma in mancanza di un supporto diretto del linguaggio temo
che la cosa sarebbe troppo onerosa. O no? Qualcuno ha già implementato
qualcosa del genere? Esempio:
BEGIN TRANSACTION
    // Eseguo le operazioni sugli archivi
RECOVER
    ROLLBACK
END TRANSACTION
o qualcosa di simile...
EMG

 
Tutto quello che dici č vero.
Io ad esempio per una gestione della produzione ho:
OU	testata conferma d'ordine
OU_R	dettaglio conferma d'ordine
MAG	schede articoli di magazzino
MAG_A	movimenti di magazzino
BU	testata DDT
BU_R	dettaglio DDT
Quando faccio un DDT da ordine permetto all'utente di selezionare alcune
rige del dettaglio conferma d'ordine (OU_R) e creo righe di dettaglio
DDT (BU_R) e alla conferma del documenti dopo la stanpa dello stesso
effettuo gli aggiornamenti:
- ogni riga di conferma d'ordine (OU_R) ha uno scarico parziale o totale
in righe di vendita (BU_R) e   MAG_A)
- ogni scheda articolo (MAG) ha un aggiornamento per quanto riguarda:
      - esistenza = esistenza - mag_a->scarico
      - impegnato = impegnato - mag_a->scarico
Io in questo modo ho:
OU_R č un dettaglio di OU
MAG_A č un dettaglio di MAG  	(in ogni riga ho l'esistenza "alla data")
MAG_A č un dettaglio di OU_R	( in ogni riga ho l'impegnato "alla data")
Se dovesse capitare un casino a livello di sistema operativo oppure un
qualsiasi altro problema che dovesse compromettere l'integritŕ della
transazione l'utente puň con dei semplicissimi F5 F6 rieseguire la
transazione che effettua i calcoli del caso.
Vado sulle schede degli articoli modificati dall'ultima movimentazione e
premendo :
F5 sistemo le esistenze partendo dal primo giorno dell'anno (Inventario) 
F6 sistemo l'ordinato 	partendo dal primo ordine fornitore
F7 sistemo l'impegnato  partendo dalla prima conferma d'ordine
Bisogna osare secondo me non preocccupandosi troppo di quello che
potrebbe accadere nel caso in cui...
altrimenti si fanno dei programmi "stitici" i quali sono limitati e non
piacciono ai clienti.
Una volta avvertito il cliente del pericolo sarŕ lui a decidere se vuola
l'elasticitŕ con il rischio che ogni tanto potrebbe capitare di lanciare
il "ricalcolo globale" magari di notte per risistemare il tutto oppure
se vuole la rigiditŕ ma senza avere dal programma informazioni un
tantino piů articolate.
Il segreto secondo me č tenere sempre la traccia di tutto quello che
viene operato sugli archivio in modo da poter ricreare oggi i movimenti
di ieri ottenendo appunto il concetto di "alla data".
esistenza alla data
Un esempio di na scheda di magazzino dopo aver premuto il tasto che
permette di vedere la storia dall'inventario ad oggi
non č che l'elenco dei record di MAG_A (movimenti di magazzino) con
codice uguale ordinati per data mentre l'ultima colonna riporta
l'esistenza che si trova nel campo esi di MAG.DBF
Data       Documento  CliFor Cau Car   Sca   EsiDat Esi
01-01-2000ŚINV99     Ś      ŚC10Ś   20Ś    0Ś    20Ś    Ś
02-03-2000Ś00.1227E  ŚKMI_M ŚS03Ś    0Ś    1Ś    19Ś    Ś
13-03-2000Ś00.0668   Ś40874 ŚS04Ś    0Ś    8Ś    11Ś    Ś
20-03-2000Ś00.1700E  Ś40874 ŚC04Ś    8Ś    0Ś    19Ś    Ś
29-03-2000Ś00.1942E  ŚKMI_M ŚS03Ś    0Ś    1Ś    18Ś    Ś
14-04-2000Ś00.2356E  ŚKMI_L ŚS02Ś    0Ś    4Ś    14Ś    Ś
14-04-2000Ś00.2361E  ŚKMI_L ŚC02Ś    8Ś    0Ś    22Ś    Ś
04-05-2000Ś00.1172   Ś10464 ŚS01Ś    0Ś    1Ś    21Ś  21Ś == 	quando
l'esistenza alla data e l'esistenza 
								non sono uguali significa che qualcue cosa
								non ha funzionato

 di ieri ottenendo appunto il concetto di "alla data".
Sono d'accordo con te.
EMG

[...]
Per quel che mi riguarda no, però non sarebbe un'idea tanto male...
Antonello.

Io sto risolvendo la cosa cosi'.
Ho creato una classe che ho chiamato MultiServer tramite la quale apro
tutti i file che fanno parte di una transazione (nel tuo esempio
movimenti e giacenze) e definisco le relazioni tra i vari archivi.
Quando devo fare una operazione di update, il metodo Rlock del padre
si incarica di bloccare tutti irecord dei file relazionati. Se riesce
a bloccarli tutti, sono in grado di procedere con gli aggiornamenti
con la sicurezza che, a meno di caduta del sistema, i file saranno
sicuramente aggiornati.
Se invece anche un solo record non puo' essere bloccato, vengono
sbloccati tutti e l'operazione non puo' essere fatta.
Sto ampliando la cosa per automatizzare anche altre operazioni come,
per esempio, definire che un certo campo del padre e' pari alla somma
di un altro campo del file figlio, ma questo e' ancora in sviluppo per
cui non so se e come funzionera'.
Ciao
-----------------------------
Fabio Cresta
EDP Consultant & VO/Jasmine developer ITALY
President of Clipper/Visual Objects/Jasmine User Group Italy
e-mail: 
fcr...@tin.it
 
fcr...@windevs.com
web: 
http://www.windevs.com
------------------------------