Univocit

[gianluigi]

Buongiorno
uso FMP 8.5 su winxp
In una soluzione gestionale multiutenza complessa genero i codici identificativi dei vari documenti appoggiandomi ad una tabella progressivi, relazionata con le altre tabelle.
In questa tabella progressivi ogni progressivo è a sua volta l'unione di un campo prefisso (che varia a seconda della causale dei documenti), di un campo numerico e di un post fisso di 2 cifre, rappresentante l'anno.
Quando nelle altre tabelle genero un nuovo record, attivo uno script del tipo:
definisci fatture:codice=progressivi::codicecompleto
definisci progressivi::partenumero=progressivi::partenumero + 1
Il tutto ha sempre funzionato su decine di migliaia di record, ma oggi mi hanno chiamato per un codice duplicato sulle fatture
Apparentemente non ci sono state cause esterne, mancanze o sbalzi di corrente, bocchi di sistema o altro, quindi sono portato a pensare ad una esecuzione contemporanea dello script nuovo documento su due postazioni.....
Voi che dite?
Per il momento ho implementato un controllo sull'autenticità del codice record, successivo alla sua definizione, e nel caso di duplicato elimino subito il nuovo record e lo ricreo (controllando la progressività della parte numerica del codice)....
Gianluigi Agostini

[stregatto]

l'unica cosa che mi viene in mente è che in una occasione non è stato possibile aggiornare il campo numerico per un problema di record locking e quindi al successivo incremento è stato riproposto lo stesso numero.

.g.

[Pirata]

Chiedo a Gianluigi:
appena subito dopo aver ottenuto il numero progressivo e definito all'interno del campo destinatario, FAI IMMEDIATAMENTE un salva record prima di far continuare all'utente di digitare il resto dei campi?
(a me viene immente che almeno due utenti abbiano fatto la stessa operazione "appropriandosi" dello stesso numero generato)

[gianluigi]

Grazie per le risposte.
A pirata: non capisco l'utilità del salva record. Dopo aver incrementato il progressivo, il vecchio valore non esiste più.
A Stregatto: il formato progressivi non è disponibile all'utente finale, e non ci sono campi di questa tabella in giro per il database; quindi ho sempre pensato che non potesse esserci il problema del record bloccato da altri utenti.
Quale può essere un sistema migliore per distribuire i progressivi in una soluzione multiutenza?
Gianluigi

[Thomas]

Caro gianluigi,
Anche il mio modestimmo intuito dice che la pista nella quale cercare è quella indicata, pure in modi diversi sia da stregatto che da pirata. Infatti se due utenti, quasi contemporaneamente, chiedono il nuovo numero, prima che la "transazione" di aggiornamento sia conclusa, riceveranno il medesimo numero. Occorre concludere esplicitamente la "transazione" con "salva record".
Prova!
Thomas

Appendice:
Alcuni sistemi banca dati prevedono esplicitamente di definire le "transazioni" e le relative istruzioni di "interlocking": con questi sistemi, si inizierebbe la transazione con accesso esclusivo, aggiornando i contatori e chiudendo la transazione. Un eventuale secondo utente avrebbe accesso ai dati solo dopo che la prima transazione sia stata chiusa e quindi otterrebbe i dati aggiornati. Dal punto di vista pratico nessuno si accorge di niente, perché queste transazioni avvengono in una frazione di secondo.
Filemaker apre la transazione implicitamente quanto si inizia a modificare un campo, non permette le modifiche contemporanee da parte di altri utenti, ma permette loro l'accesso dei dati in lettura (ma non ancora modificati). Di conseguenza l'unica possibilità è chiudere subito la transazione con "salva record".
Il fatto che FileMaker non conosca un meccanismo esplicito di transazioni è, in un ambiente client-server, un punto negativo che potrebbe limitarne l'impiego in applicazioni molto complesse con un grande numero di utenti che interagiscono fra di loro.
Si potrebbe ovviare introducendo un sistema di "interlocking" all'interno dell'applicazione stessa con un campo "interlock" (NON globale in ambiente client-server perché ogni utente ha i suoi valori e perché così si riesce a controllare in modo differenziato ogni singolo record) che tiene conto se il record è già usato in modifica da un altro utente. Se sì (valore = 1) non si lascia accedere un secondo utente nemmeno per la lettura, se no (valore = 0), l'accesso è permesso. Alla chiusura della "transazione" si mette di nuovo a 0 il valore del campo "interlock", liberando l'accesso. Ovviamente, dopo ogni cambiamento di valore del campo "interlock" bisogna fare "salva record". Questo indica che pure questo sistema non è affidabile al 1000 per 1000, lasciando un residuo di limitazione e il desiderio che una futura versione di FileMaker tenga conto dell'esigenza di creare "transazioni" esplicite con delle opzioni di "interlocking" esplicite.

[gianluigi]

Ciao
Grazie per l'ulteriore precisazione, ma continuo a non capire....
Dove o quando devo eseguire l'istruzione salva record?
1) prelevo il valore del progressivo, e qui non mi pare serva il salva record
2) incremento il progressivo, e qui a cosa serve il salva record? Se di per se non bastasse l'istruzione di incremento progressivo, avrei creato nel tempo chissà quanti buchi, mentre nella mia esperienza è il primo caso di anomalia....
3) se effettivamente il sistema di transazione di FM fosse "debole", la cosa sarebbe grave (intollerabile!) a prescindere dalla più o meno gravosità dell'utilizzo in rete.... non è possibile tollerare un sistema che nell'utilizzo in rete possa permettere la creazione di doppioni, al di là che il sistema venga utilizzato da due o da duecento terminali! (oppure il mio sistema di generazione codici non è adeguato ed allora chiedo lumi ai più esperti)
4) ho cercato di concretizzare il tuo suggerimento del blocco record, ma non trovo il modo di bloccare l'accesso in sola lettura ad un record; mi potresti indicare queli sono le istruzioni di script che permettono questo blocco? (la qual cosa sarebbe forse la soluzione: leggo il progressivo, blocco il record, utilizzo il progressivo letto per le mie necessità, incremento il progressivo e quindi sblocco il record).
Grazie
Gianluigi

[stregatto]

3) se effettivamente il sistema di transazione di FM fosse "debole", la cosa sarebbe grave (intollerabile!) a prescindere dalla più o meno gravosità dell'utilizzo in rete.... non è possibile tollerare un sistema che nell'utilizzo in rete possa permettere la creazione di doppioni, al di là che il sistema venga utilizzato da due o da duecento terminali! (oppure il mio sistema di generazione codici non è adeguato ed allora chiedo lumi ai più esperti)

il sistema NATIVO di fm non è debole. Intendo quello che si imposta in fase di definizione campo. Il problema accade quando - come nel tuo caso "elabori" questo sistema inserendo delle variabili per le tue esigenze.

4) ho cercato di concretizzare il tuo suggerimento del blocco record, ma non trovo il modo di bloccare l'accesso in sola lettura ad un record; mi potresti indicare queli sono le istruzioni di script che permettono questo blocco? (la qual cosa sarebbe forse la soluzione: leggo il progressivo, blocco il record, utilizzo il progressivo letto per le mie necessità, incremento il progressivo e quindi sblocco il record).

infatti di solito si fa così. Visto che governi tutto via script, il modo più semplice è usare un campo indicatore (pieno, occupato, vuoto libero) da riempire ad inizio script e svuotare a fine script, con un if iniziale per cui se il campo è pieno lo script pausa per un po e ripete se stesso fino a trovare il campo libero.

.g.

[olto]

Buona sera a tutti.

Premetto che non ho mai testato la procedura a fondo, ma in altra situazione simile era stato consigliato di mettere una specie di lucchetto sottoforma di flag/semaforo.
Nel momento in cui viene richiesto in nuovo numero progressivo, la procedura, pone il flag a 1 = "occupato" e solo al termine della procedura, il flag viene posto a 0 = libero, a disposizione di un altro utente che nel frattempo viene messo in attesa tramite un loop condizionato dal flag.

[stregatto]

ehm, olto, non è esattamente quello che avevo detto nell'ultimo intervento?


.g.

[olto]

hemm.

Sì...ma ti garantisco che non ho copiato... non ne ho bisogno!!!!

Sono saltato subito alla risposta senza guardare ciò che veniva dopo!

ASe ti può interessare, quando cito"in una occasione simile....." si riferisce ad una richiesta fatta in LISTA e la possibile soluzione(che non ho avuto modo di testare perchè era un semplice esperimento) mi è estat fornita da G.Pupita!