Newsgroup: it.comp.lang.vo-clipper
Titolo: [VO25a1] Tema: Condivisione archivi DBF

Ciao a tutti, ho lanciato una proposta e mi sembra giusto aprire le danze.
Premetto solo che non sono un programmatore professionista.
Le funzioni o i metodi di VO per bloccare / sbloccare un record o un file
sono molto facili da usare.
Aggiungere un record o modificarlo non è un'impresa ardua.
Il problema può nascere quando il nostro archivio è indicizzato su una
chiave progressiva (esempio codice cliente).
La mia soluzione è questa:
1)  Uso un file bsys.dbf condiviso, che funziona da semaforo, con un solo
campo (tipo C lung. 20) e indicizzato sullo stesso. In questo campo vengono
memorizzati i nomi dei file (nome effettivo del file senza estensione)che
usano delle chiavi progressive.
2)  Prima di aggiungere un nuovo record al mio archivio di dati (es.
clienti) effettuo una seek sul file semaforo
oServerSys:Seek(PADR("clienti",20))
e blocco il record
oServerSys:RLock()
3) calcolo la chiave progressiva sul file clienti, aggiungo un record al
file clienti, memorizzo i dati nel file clienti
4) sblocco il semaforo
oServerSys:UnLock()
Naturalmente ho semplificato il codice, per evidenziare solo il concetto. In
realtà bisognerebbe implementare i tentativi di blocco del semaforo in
quanto questo potrebbe già essere bloccato da un altro utente, ecc. ecc.
Il sistema da me usato, che chiaramente non ha niente di originale e
sicuramente già utilizzato da molti, presenta un grosso punto positivo che è
quello di non scrivere niente nel file semaforo e nemmeno creare file
temporanei esterni. Se un utente blocca il record e poi il PC va in tilt,
effettuando il reset del PC, anche il semaforo viene sbloccato.
Penso di aver fatto cosa gradita a chi si avvicina per la prima volta alla
condivisione di un file DBF.
Ciao

 1)  Uso un file bsys.dbf condiviso, che funziona da semaforo,
Premetto che uso Clipper, non VO. Anch'io uso un semaforo del genere (in
realtà uno semplificato fatto da un solo record) per sincronizzare
operazioni che non possono essere gestite tramite locks come, ad
esempio, la creazione di un file condiviso, e la cosa ha, in effetti,
sempre funzionato benissimo (e se le operazioni sono brevi, come quasi
sempre succede, non c'è neanche bisogno del retry).
Nel caso, invece, della chiave progressiva non riesco a capire perché
mai tu debba aver bisogno di un semaforo esterno. Non basta bloccare
l'intero file utilizzandolo, esso stesso, come semaforo?
EMG

quanto questo potrebbe già essere bloccato da un altro utente, ecc. ecc.
Mumble mumble..... il tuo approccio non mi piace :) Cosi' facendo blocchi
l'intero file per un solo record.
Ciao
DioBrando

Io utilizzo un altro sistema un file INI nella cartella ove in rete sono i
DBF.
Quando faccio un append controllo che esita il file INI, se non c'è viene
creato, apro il file INI controllo che esista l'Item con nome del DBF, se
non c'è lo crea, leggo il valore, lo incremento lo registro.
Quando faccio un delete se è l'ultimo Record, ovvero la chiave corrisponde
al valore nel File INI lo decremento.
es. Del file INI
[FATTURE /FT]
LOCK=0
CONTATORE=236
DESCRIZIONE=FATTURE /FT
[FATTURE /NC]
LOCK=0
CONTATORE=2
DESCRIZIONE=FATTURE /NC
[TAB_IVA]
LOCK=0
CONTATORE=29
DESCRIZIONE=Tabella IVA
[CLIENTI]
LOCK=0
CONTATORE=2412
DESCRIZIONE=CLIENTI
[FORNI]
LOCK=0
CONTATORE=3
DESCRIZIONE=FORNITORI
L'Iten LOCK viene messo a 1 qundo inizio l'operazione e rimesso a 0 alla
fine, server a gestire accessi contemporanei,
La descrizione server per una finestra dalla quale l'amministratore puo'
modoficare manualmente i codici se necessario.
Con quasto sistema gestisco anche numerazioni multiple sullo stesso file
nell'esempio le fatture sono posto nello stesso
file delle note di credito, ma utlizzano un contatore diverso.
Il meccanissmo è poi gestito in automatico da una classe MyDBServer che
eredita dalla DBServer.
Vi garantisco funziona ed anche molto bene,
Danilo Giuliani

DioBrando

On Sun, 25 Jun 2000 08:44:35 GMT, 
s...@hi-net.it
 (Eugenio Belli) wrote:
E' sparita la riga iniziale..
diceva :
Anche io faccio cosi' :  (come E.M.Giordano)
 

 l'intero file per un solo record.
Questo, in un modo o nell'altro, ritengo sia indispensabile, se si vuole
garantire l'unicità della chiave. Comunque se hai un metodo alternativo
siamo qui per imparare.
EMG

 non c'č lo crea, leggo il valore, lo incremento lo registro.
Non mi sembra che questa sistema sia affidabile. Il file INI chi lo
blocca? Chi impedisce che venga letto contemporaneamente da piů utenti?
Non mi pare ci sia un meccanismo implicito di bloccaggio per i file INI.
EMG

 la lettura resta possibile.
Secondo me è fuorviante parlare di blocchi in scrittura, lettura o che
altro. Le funzioni di lock su file o su record non sono altro che
semafori. Quello che effettivamente bloccano dipende dalla strategia
adottata nel programma.
EMG

 CHE NE PENSATE????
Come mi sembra di averti già detto, non so se le funzioni di lock del VO
abbiano qualche bug ma in caso contrario non vedo proprio perché non
utilizzarle. Quelle del Clipper, ad esempio, funzionano benissimo. Forse
stavi condividendo DBF tra programmi scritti in VO e programmi scritti
in Clipper o con altri strumenti? In questo caso può darsi che le
tecniche di locking utilizzate siano incompatibili.
Altra cosa che ripuntualizzo: parlare di blocco di file o record è
fuorviante. A poco serve usare quelle funzioni se poi la strategia
seguita per sincronizzare operazioni inerentemente asincrone è in
qualche modo errata.
EMG

Ciao a tutti.
La mia soluzione è quella di avere un file .dbf, con tanti campi
quanti sono i terminali in uso, più un campo relativo allo specifico
lock che viene impostato.
Il file dovrà avere, in origine, tanti record quanti possibili tipi di
lock dovranno essere gestiti (ad es. uno per le accettazioni, uno per
le refertazioni, etc.).
Nel momento in cui un terminale entra in modifica di una accettazione,
il blocco viene segnalato agli altri terminali andando a registrare
numero e data dell'accettazione nel record delle accettazioni in
corrispondenza al campo del terminale.
Gli altri terminali possono quindi bloccare una propria accettazione,
purchè essa non risulti già bloccata da altri nel record delle
accettazioni.
Inoltre, aggiungendo un record "Reindex" per la reindicizzazione degli
archivi, viene impedito a qualsiasi terminale di accedere ad ogni
procedura di modifica dei dati, finchè è presente un blocco su uno
qualunque dei campi nel record di reindicizzazione.
Spero di essere stato chiaro....
L'inconveniente classico è quello del blocco che continua a permanere
nel caso di uscita anomala dal programma...
Questo mi ha fatto apprezzare particolarmente la soluzione di Biagio
Notario, che terrò ben presente.
ciao.

lock che viene impostato.
ehm.., dimenticavo di dire che il file viene poi aperto in modalità
esclusiva.

CHE NE PENSATE????
penso che sia una soluzione valida, ed in certi casi necessaria. 
Ma non è certo la più flessibile e sofisticata...
saluti.

 corrispondenza al campo del terminale.
A me sembra che, in generale e senza offesa alcuna, vi complichiate la
vita con strutture non necessarie. In realtà il Clipper (o, credo, il
VO) dispone di tutti gli strumenti necessari a gestire il lock in ogni
situazione. L'unico caso non gestito è, come ho detto in un messaggio
precedente, quello in cui si debba sincronizzare un'attività durante la
quale non c'è un DBF aperto e quindi non è disponibile alcun semaforo.
In tale evenienza un DBF accessorio con un unico record (ne serve almeno
uno o si può fare flock anche senza alcun record? Non ci avevo
pensato...) può tranquillamente fare le veci del semaforo mancante.
EMG

Ciao a tutti,
EVVIVA sono riuscito a smuovere questo NG che era un po' statico
ultimamente.
Speriamo che continui cosě !!!!!
Forza che ci siamo

 l'intero file utilizzandolo, esso stesso, come semaforo?
Si Enrico hai ragione.
Perň ho scelto il mio sistema per questi motivi:
1) se un utente sta modificando un record (e quindi lo tiene bloccato) non
mi permette di bloccare l'intero file;
2) bloccare un record di un piccolo file esterno che funziona da semaforo č
sicuramente piů veloce che bloccare un file di parecchi record.
Tutto qui


Al contrario, forse non sono stao chiaro.
Sia il file di dati che quello che funziona da semaforo, sono in modalità
condivisa.
Nel file di dati non è possibile aggiungere un nuovo record (con chiave
progressiva) per il tempo strettamente necessario ad un altro utente di :
- calcolare la chiave
- happend nel DBF
- scrivere nel DBF
Questo sistema permette di aggiungere record contemporaneamente in file
diversi in quanto ogni file dati ha un suo record semaforo.

 DBF.
Non lo trovo pratico perchè preferisco non fidarmi di file esterni per
sapere l'ultimo numero utilizzato.
Io leggo sempre il file DBF, e se non ci sono problemi di indici, calcolo la
nuova chiave sui record esistenti, non so se mi spiego.

 CHE NE PENSATE????
Devo dirti che per il momento non ho avuto di questi problemi, però devo
dire che il tuo sistema aumenta sicuramente la sicurezza (forse rallenta un
po' la velocità per il fatto che devo continuamente aprire e chiudere il
file).

vita con strutture non necessarie. 
Non hai certo torto... 
è veramente facile trovare soluzioni complicate, a volte per la
fretta, a volte per una analisi non sufficientemente approfondita.
Il difficile, lo sappiamo tutti, è trovare le soluzioni semplici, ma
potenti.
Per questo, lo scambio in corso è estremamente interessante.
ciao

[...]
Io uso un altro metodo, ho un file (ad. es) PROG.DBF di un solo campo
CONTATORE o ID, che contiene l'ultimo progressivo utilizzato.
Quando faccio l'append, apro il file, blocco l'unico record,
incremento, pesco il numero, sblocco e chiudo. 
Si possono usare + files (1 per ogni DBF con un campo contatore)
oppure un file con un campo che identifica il contatore e un campo
contatore vero e proprio.
Antonello.

 penso che sia una soluzione valida, ed in certi casi necessaria.
Non vedo per quale motivo dovrebbe essere necessario aprire il DBF in
modo esclusivo. Le normali funzioni di lock sono piů che sufficienti.
L'apertura esclusiva č richiesta solo nei casi specificati nella
documentazione del Clipper (in questo momento ricordo solo il PACK).
EMG

 sicuramente più veloce che bloccare un file di parecchi record.
No, qui sei in palese errore: l'operazione di file locking è
assolutamente indipendente dalla grandezza del DBF, sia come dimensione
dei record che come quantità degli stessi.
EMG

 sapere l'ultimo numero utilizzato.
Sono d'accordo. E' in generale impossibile garantire la coerenza tra il
DBF e la relativa entry nel file INI.
EMG

modo esclusivo. Le normali funzioni di lock sono più che sufficienti.
in teoria hai sicuramente ragione.
ma ci sono casi in cui non ti va di correre alcun rischio, ed apri in
modalità esclusiva. Quello che ho in mente è una rete di tre server
NT, dislocati in tre palazzine distanti dai 50 ai 100 metri, su un
server sta il file con il contatore delle fatture. Devi essere certo
che a tutti i terminali collegati ai vari server venga fornito un
numero progressivo univoco.
Considerati i tempi di accesso, incremento e rilascio, preferisco
senz'altro aprirlo in modalità esclusiva.
Una osservazione su questo thread.
Mi sembra che si stiano mischiando argomenti differenti, ed in
particolare due:
uno è essenzialmente relativo al "blocco" di un file (o più file)
contenente un contatore da aggiornare;
l'altro è relativo al meccanismo di semafori per l'accesso sicuro da
parte di più utenti ai record di uno stesso file dati, sia in modifica
che in append (e qui si ricollega allora anche il primo caso).
ciao

Heila' che vespaio che ho scatenato :)
Allora rispondo un po' a tutti su quale sarebbe la mia alternativa. Premesso che
ove possibile secondo me il blocco del file sarebbe da evitare del tutto, questo
per dare la possibilita' ad ognuno di poter modificare un record in qualunque
momento ( ovviamente quando non gia' lockato ). In pratica mi creo un array con
i record da lockare con una funzione ( se volete posto il codice ) e se un solo
lock fallisce non permetto l'aggiornamento del/i record, in questo modo non
obbligo nessuno ad aspettare che il file semaforo si sblocchi.
Le mie considerazioni poi erano dovute al fatto che comunque dipende dalla
tecnica di locking che si vuole adottare, faccio un esempio: 
- voi utilizzate tecniche di scatter/gather ( server bufferizzati ) ?
- bloccate il record al momento dell'input dei dati ( bufferizzati ? ) oppure
editate il record stesso ?
- se il lock fallisce date la possibilita' di riprovare ?
- nel caso di lock fallito avete delle procedure di rollback ( per quanto
possibile con il clipper e i .dbf ) ?
A me non piace il metodo da voi adottato perche' per es.: l'utente/i stanno
editando i dati, si allontana dalla sua postazione di lavoro un attimo ( una
telefonata, deve andare al bagno, pausa caffe', un collega gli parla etc. etc.
). 
- Ora, se il file e' gia' bloccato gli altri cosa fanno ? Non possono ne
aggiungere ne modificare record fino a che il tipo ritorna alla sua postazione e
finisce quello che stava facendo.
- Il file non e' ancora bloccato, lo blocco al momento del salvataggio dati ma
un mio collega, mentre ero via, ha gia' modificato i dati dello stesso record,
cosa faccio, sovrascrivo i dati appena salvati dal mio collega ?
Fatemi sapere le soluzioni che voi avete adottato che poi le confrontiamo con
quelle che utilizzo io.
Per quanto riguarda il file con i numeri progressivi io non lo utilizzo, bensi'
faccio uso dei #Recno.
Ciao
DioBrando
P.S. Comunque ci sarebbe da scrivere per chilometri sull'argomento :) e se
volete la discussione su argomenti tecnici come questi ecchime :)
P.S.2 io utilizzo sia Clipper che VO.

 Per questo, lo scambio in corso č estremamente interessante.
Sono d'accordo.
EMG

 volete la discussione su argomenti tecnici come questi ecchime :)
Ben vengano queste interessanti discussioni!
EMG

 contatore vero e proprio.
Ciao Antonello
Va bene. Ma cosa succede se avviene un crash del PC prima o dopo aver
incrementato il contatore?
Primo append
append
apro file
blocco
incremento
pesco
 ----> crash ... non rieso a salvare i dati con la nuova chiave progressiva
Secondo append
Ho un buco nel contatore. Non è un problema se il contatore mi serve solo
per identificare il record e quindi può contenere anche buchi nella
sequenza.
Scusa se sono pignolo ma è l'unico modo per rendere la discussione proficua.

 modalità esclusiva.
No, scusa, il discorso è questo: o ti fidi delle funzioni di lock e le
usi tranquillamente oppure ritieni che non funzionino e allora non le
usi mai. Non ci sono vie di mezzo.
EMG

 dei record che come quantità degli stessi.
Ammetto di non aver fatto nessun test e sono andato a fiuto. Però non è
possibile bloccare l'intero file per aggiungere un record con chiave
progressiva se già un utente ha bloccato il record 27 per fare una modifica,
o sbaglio?
Discussione accesa e piacevole.
Non so voi ma io sto imparando un sacco di cose e riorganizzo le idee !!!!

 Heila' che vespaio che ho scatenato :)
Va bene, va bene ....... da un po' di tempo non si sentiva volare una mosca
in questo NG.
Ora spero che si aprano nuovi temi.

 Non so voi ma io sto imparando un sacco di cose e riorganizzo le idee !!!!
A questo dovrebbero servire i newsgroup (purtroppo spesso non è
così...).
EMG

 2: impedire il salvataggio dei dati
Si, conosco questa tecnica ma non la condivido nei suoi intenti.
Ragioniamo: quando l'utente conferma dei dati immagina (giustamente) che
questi vengano scritti sul disco. Se subito dopo un altro utente
modifica questi dati e li conferma nessuno si soprenderà se questi sono
ulteriormente cambiati sul disco stesso. A questo punto cosa importa se
l'ultimo ad aver confermato dei dati modificati ha iniziato l'operazione
prima o dopo gli altri? Se ci riflettete bene, l'unica cosa importante è
l'ordine di conferma, non quello di inizio della modifica.
EMG

incrementato il contatore?
Si perde un numero, ma č poco importante, poichč il campo ID che
utilizzo č sempre un NUMERICO di 8 cifre e comunque nei miei programmi
i dati inseriti vengono anche cancellati spesso, quindi di buchi ce ne
sono sempre parecchi.
Per recuperare qualche numero si potrebbe al limite riallineare il
contatore con l'ultimo ID valido durante il PACK del file.
Es.
CONTATORE = 2500
ULTIMO ID VALIDO NEL FILE = 2450 (puň capitare)
Dopo aver fatto il pack riporto il contatore a 2450.
Antonello.

 numero progressivo univoco.
Visto che mi sembra si tratti di un'installazione non da poco, hai valutato
la possibilita' di usare un client/server come ADS ? Ti garantirebbe
sicuramente un'ottima integrita' dei dati.
Ciao.Alberto.

 e decidere se accettare il salvataggio o meno con il nuovo record!
La mia applicazione propone un codice automatico sin dall'inizio, ma prima
di salvare il record lo ricalcola e non chiede niente alla segretaria. Lei
visualizzava il nuovo codice "000100" e immediatamente dopo il salvataggio
vede il "000101". Questo perché una sua collega è arrivata prima di lei e
gli ha fregato il numero.
Potrei evitare di calcolare il codice all'inizio, in modo da risparmiare
qualche frazione di secondo ........
Ciao

 l'ordine di conferma, non quello di inizio della modifica.
Giusto !!!!! Ma è una regola da usare con cautela, da non applicare a 360°.
A volte quell'informazione determina un certo comportamento ed è quindi
necessario avere un semaforo iniziale. Se si apre la porta dell'ascensore è
irrilevante che qualcuno sia in attesa al piano superiore o inferiore
(esempio stupido ma rende l'idea).

 poichè il campo ID che utilizzo è sempre un NUMERICO di 8 cifre
Io generalmente lo dimensiono a 10 cifre per stare proprio tranquillo ma
in effetti 8 sono più che sufficienti anche per molti anni di utilizzo.
EMG

sicuramente un'ottima integrita' dei dati.
Ho letto in varie occasioni le caratteristiche di ADS, e mi ha sempre
"intrigato", ma i prezzi mi sono sembrati piuttosto alti non solo per
me ma anche per il mio client, per cui finora ne ho fatto a meno.
In ogni caso, ne so molto poco.
Potrebbe anche essere un'idea per nuovi thread sul NG:
parlare di librerie di terze parti che hanno meritato di essere state
acquistate....
ciao

 anche per via della programmazione procedurale...
Non è vero. Io uso Clipper e Fivewin per lo sviluppo di programmi
Windows e, nonostante la programmazione sia tutt'altro che procedurale,
non riscontro alcun problema nelle funzioni di lock.
EMG

 acquistate....
Una libreria che ho acquistato e che uso ormai da diversi anni sono le
Fivewin. E non sono affatto pentito dell'acquisto, anzi lo trovo uno
strumento di lavoro eccezionale. Poi uso un'altra libreria, questa
gratuita, che si chiama BARLIB che permette ad una applicazione Clipper
+ Fivewin di stampare in modo estremamente semplice molti tipi di codici
a barre. Poi uso la Comix per quanto riguarda la gestione degli indici
(CDX) e anche con questa mi trovo benissimo.
In generale, se non è proprio indispensabile, preferisco evitare l'uso
di librerie esterne per non creare dipendenze che, prima o poi,
risultano sempre problematiche.
EMG

 non riscontro alcun problema nelle funzioni di lock.
sempre clipper e'....
a proposito mi dici come risolveresti tu il problema del blocco che non
avviene a random??? cerchiamo di reificare un po'....
franco

 avviene a random??? cerchiamo di reificare un po'....
Chiariamo. Prima hai detto che il blocco non avviene nonostante la
funzione (o metodo) di lock restituisca TRUE e questo è ovviamente
impossibile dato che il lock stesso è *esattamente* quel TRUE. Immagina
che la funzione di lock scriva da qualche parte ROSSO senza prendere
minimamente in considerazione i DBF. Ebbene, comunque assolverebbe
ugualmente al suo compito. Quindi l'operazione di locking non è affatto
legata a file, record o quant'altro. Quelli sono solo dei comodi e
preesistenti supporti sui quali sono state implementate tali funzioni.
Cominciamo a chiarirci?
EMG

Mi inserisco nello scambio tra Franco Signore ed Enrico Maria Giordano
per qualche considerazione sicuramente scontata.
So che inserirsi in uno scambio avviato è pericolosissimo e si corre
il rischio di prenderle da entrambe le parti, ma tant'è...
La mia premessa nel leggere questi interventi è che sto leggendo il
risultato della rispettabilissima esperienza di altri programmatori.
Voglio dire che, aldilà delle espressioni usate (semaforo, lock,
accesso bloccato, regolamentazione di flusso, etc..), il problema è
perfettamente chiaro.
A me interessano molto anche le puntualizzazioni (come dire.., non
trovo l'espressione adatta) stilistiche e/o teoriche e/o
metodologiche, ma questo non toglie che una certa soluzione "pratica"
abbia una sua validità o necessità in certi contesti, valutabili
soltanto caso per caso.
Ad esempio, un mio cliente ha una rete peer-to-peer basata su un
"server" non dedicato Windows98 con sette PC W98/W95/w3.11 collegati.
Ci sono ovviamente problemi.
Gli ho detto di passare a Windows NT se vuole sicurezza e stabilità.
Intanto si tiene i problemi (tutto sommato, sporadici) ed io continuo
a servirmi delle funzioni Flock() ed RLock(), dato che addebito in
toto al sistema operativo di rete la comparsa di detti problemi.
Invece, come ho già detto, su una rete basata su un vero sistema
operativo di rete (NT), per la particolare dislocazione di terminali e
di server, per l'obiettivo da raggiungere, apro un file con campo
contatore in modalità esclusiva.
Sembra un paradosso.
Proprio là dove ho il migliore supporto alla rete, uso la modalità
esclusiva!!!
Ma sta di fatto che non cambierò modalità in quanto la realtà di
quella installazione vede forti sbalzi di tensione, attualmente non
filtrati a sufficienza.
Per me, con NT, aprire un file in modalità esclusiva per un tempo
insignificante equivale di fatto ad accendere un semaforo, di cui è
responsabile NT (a me sembra il massimo).
ciao

 responsabile NT (a me sembra il massimo).
No, il responsabile del semaforo sei comunque tu. Ne puoi lasciare al
massimo la responsabilità al Clipper che però più che generarti
un'eccezione (eventualmente trappabile tramite BEGIN SEQUENCE/END
SEQUENCE) non può fare.
EMG

 Cominciamo a chiarirci?
no caro xche' ancora non hai risposto al quesito: se si appura che per
motivi x non c'e' stato il blocco(nel senso che e' possibile acedere al file
NONOSTANTE il rosso) come risolveresti la questione sul piano pratico?
ripeto sul piano pratico... risparmiami altre lezioni di teoria x carità.
ciao Franco

 ripeto sul piano pratico... risparmiami altre lezioni di teoria x carità.
Se lo stesso lock fatto da un altro utente riesce allora non c'è proprio
niente da fare dato che il semaforo non funziona.
EMG

SEQUENCE) non può fare.
la tua attenzione mi pare rivolta essenzialmente al codice, quindi ad
un punto di vista da cui io non mi sto ponendo, in quanto lo do per
scontato.
io cercavo di dire la mia su casi in cui, per far fronte a situazioni
anomale, si adottano soluzioni magari non "canoniche", ma efficaci,
praticamente efficaci.
apprezzo senz'altro il tuo rigore e riconosco di avere sempre da
imparare, ma considera anche che ognuno ha una propria esperienza.
ciao

 imparare, ma considera anche che ognuno ha una propria esperienza.
E siamo qui per condividerla, no?
EMG

Scusatemi se insisto, ma i sistemi basati su indici hanno proprio il difetto
che se un indice è corrotto, buona notte all'incremento del numero, e Dio
solo sa come sia facile il verificarsi di questa evenienza e come non esista
una routine che controlli veramente l'integrità di un indice;
L'uso di un DBF in cui posso definire il numero usato quale ultima chiave,
equivale ad usare il mio file INI che a mio giudizio offre il vantaggio di
essere un file testo e quindi modificabile con Notepad as esempio.
Per quanto riguarda il controllo degli accessi come ha detto uso un Item
LOCK per ogni archivio che serve a prevenire accessi nultipli.
Danilo Giuliani
Vecchia News:
Io utilizzo un altro sistema un file INI nella cartella ove in rete sono i
DBF.
Quando faccio un append controllo che esita il file INI, se non c'è viene
creato, apro il file INI controllo che esista l'Item con nome del DBF, se
non c'è lo crea, leggo il valore, lo incremento lo registro.
Quando faccio un delete se è l'ultimo Record, ovvero la chiave corrisponde
al valore nel File INI lo decremento.
es. Del file INI
[FATTURE /FT]
LOCK=0
CONTATORE=236
DESCRIZIONE=FATTURE /FT
[FATTURE /NC]
LOCK=0
CONTATORE=2
DESCRIZIONE=FATTURE /NC
[TAB_IVA]
LOCK=0
CONTATORE=29
DESCRIZIONE=Tabella IVA
[CLIENTI]
LOCK=0
CONTATORE=2412
DESCRIZIONE=CLIENTI
[FORNI]
LOCK=0
CONTATORE=3
DESCRIZIONE=FORNITORI
L'Iten LOCK viene messo a 1 qundo inizio l'operazione e rimesso a 0 alla
fine, server a gestire accessi contemporanei,
La descrizione server per una finestra dalla quale l'amministratore puo'
modoficare manualmente i codici se necessario.
Con quasto sistema gestisco anche numerazioni multiple sullo stesso file
nell'esempio le fatture sono posto nello stesso
file delle note di credito, ma utlizzano un contatore diverso.
Il meccanissmo è poi gestito in automatico da una classe MyDBServer che
eredita dalla DBServer.
Vi garantisco funziona ed anche molto bene,
Danilo Giuliani

 una routine che controlli veramente l'integrità di un indice;
Sacrosanto. Per questo è meglio che l'indice non sia coinvolto. E
normalmente non c'è alcun bisogno che lo sia in quanto il codice, se
generato in maniera trasparente, può tranquillamente essere nell'ordine
fisico di append dei record. Quindi nel momento in cui si vuole il
codice successivo basta un SET ORDER TO 0 seguito da un GO BOTTOM per
trovare l'ultimo e quindi poter calcolare il nuovo.
EMG

una routine che controlli veramente l'integrità di un indice;
Non metto in dubbio la possibilita' che un indice si corrompa,
ma in tanti anni  che uso questo sistema non si e' mai verificato
il caso di inserimento di key duplicate (ovvero di numeri doppi
o errati).
Le uniche anomalie riscontrate sono state in caso di alterazione
delle tabelle o danni fisici ai dischi fissi.
Il motivo credo sia nel fatto che io prevedo una rigenerazione
indici automatica in caso di interruzione del programma e
d'altra parte se gli indici sono corrotti  non si puo' garantire
il funzionamento di niente.(Salvo file ini o tabelle senza indici)
In breve : che me ne faccio di un contatore sicuramente
corretto se poi quando lo vado ad utilizzare ho un comportamento
imprevedibile?
(nessuna polemica, solo un tranquillo scambio di idee)
Eugenio Belli.
 

trovare l'ultimo e quindi poter calcolare il nuovo.
Utilizzare il numero di record preclude la possibilita' di
eseguire un pack dell'archivio e di riutilizzare records
annullati.
Non  e' possibile gestire serie di numerazioni diverse
e non e' detto che alla prima installazione si parta
con un progressivo uguale a 1.
Ciao,
Eugenio Belli.
 

 con un progressivo uguale a 1.
Basta prevedere, nella funzione di aggiornamento del codice, l'eccezione
nel caso di DBF vuoto (con inizializzazione di tale valore iniziale
magari da una tabella di configurazione).
EMG

 (nessuna polemica, solo un tranquillo scambio di idee)
Non c'è neanche bisogno di dirlo.
EMG



 (siamo tutti un po' gelosi, delle nostre idee)
Se così fosse perché staremmo qui a perdere tempo? :-)
EMG

 si potrebbe incrementare il valore iniziale della tabella...
Sapevo che l'avresti detto. :-) In realtà lo scopo era di non utilizzare
tabelle esterne per i contatori per ridurre la possibilità di errori. Se
c'è un valore iniziale questo, se prefissato, potrebbe anche essere una
costante all'interno del programma. Se invece deve essere scelto
dall'utente allora deve certo essere memorizzato da qualche parte (file
MEM, file INI, file DBF) ma si tratta comunque di un valore fisso che
non deve essere mai aggiornato nel normale lavoro. Mi sembra che la cosa
sia ben diversa dall'avere una tabella che viene continuamente toccata
da tutti gli utenti, non ti pare?
EMG

 non nel senso di avari.
Veramente io sono qui soprattutto per sentire delle idee alternative.
EMG

 :-)
Ok, sembra che questo thread si stia avviando alla fine. :-)
EMG

 Anche io ma prima di lasciare la strada vecchia... ;-)
Certo, nessuno pretende questo. Ma le buone idee, entrando a far parte
del bagaglio culturale di chi le recepisce, rendono le scelte future piů
efficaci.
EMG

 mi sa che non risolve nulla.
Penso proprio di no, anche se certo dipende dal tipo di problema.
EMG

 prossimo=field_numero+1
Mi sono perso. Non avevi detto che utilizzavi una tabella di contatori?
Ora sembra invece che trovi il prossimo codice sul DBF principale. Forse
mi sono confuso io...
EMG

 La discussione per me e' stata utile comunque.
Anche per me, senza dubbio.
EMG