Newsgroup: it.comp.lang.vo-clipper
Titolo: Campo Memo

Esiste un modo per evitare che si verifichi il problema dello slittamento
dei campi memo nei DBT o almeno un modo per recuperarli ?
Grazie a tutti

 wrote in message
9q697s$k6a$1...@fe1.cs.interbusiness.it...



Cosa intendi per slittamento dei campi memo nei DBT?
Ciao,
        Fabrizio Malaguti

 dei campi memo nei DBT o almeno un modo per recuperarli ?
Dovresti essere sicuro di dare sempre il COMMIT dopo le modifiche ai
campi e assicurarti che il tuo RDD lo rispetti. Ad esempio, ho appena
scoperto che dopo aver cambiato versione di Comix il COMMIT non mi
veniva più eseguito. Ho dovuto dare il comando CMXSYS( 1002, .T. )
all'inizio del programma per riattivarne la funzionalità.
EMG

 dei campi memo nei DBT o almeno un modo per recuperarli ?
Intendi che i memo si sono danneggiati?
A me e' successo qualche volta con Clipper 5.2e e RDD NSX, ho trovato
una utility di nome DBTCHK, che trova gli errori, ma non corregge tutto
poi ho scritto una utility che recupera la funzionalita' dei memo
se vuoi mando un attachment, non e' tanta roba.
Ciao...
Claudio Driussi
http://www.swit.net/csoft
mailto:
cldr...@swit.net

 A me e' successo qualche volta con Clipper 5.2e e RDD NSX,
A me è capitato una volta tanti anni fa, prima che adottassi un tipo di
programmazione preventiva nei confronti di questo tipo di problemi,
problemi che comunque non sono legati ai soli DBT ma a qualunque tipo di
file aperto in generale.
EMG

 file aperto in generale.
Mah! a me il problema si e' verificato solo con i campi memo ed
in casi rarissimi, non so che cosa intendi per programmazione
preventiva, ma nel mio caso non vedo come avrei dovuto fare
per prevenire errori cosi' rari.


 per prevenire errori cosi' rari.
Dunque, il discorso è questo: o pensi che la gestione dei campi memo DBT
in Clipper abbia dei bug gravi che ne causano la corruzione (e questo
penso di poterlo escludere dato che io, come dicevo, sono tanti ma tanti
anni che li uso pesantemente senza avere il minimo guaio), oppure il
problema è generale.
In effetti la causa principale di queste cose sono le cache in scrittura
che, nel caso di impallamenti del sistema, lasciano il database in uno
stato non coerente. E' molto difficile (anche se non impossibile) che si
corrompa il DBF in quanto questo è il file principale. E' più facile che
si corrompano gli indici o i DBT che sono file che dipendono da quello
principale.
Per ridurre praticamente a zero il problema è sufficiente utilizzare il
COMMIT dopo ogni scrittura (o gruppo di scritture) e assicurarsi (cosa
importantissima che ho scoperto recentemente dopo un cambio di RDD) che
il proprio RDD scriva effettivamente su disco dopo il COMMIT
(eventualmente cercare il comando per forzarlo a fare questo oppure
cambiare RDD).
Altra programmazione preventiva che si può fare è quella di gestire
sempre (in modo centralizzato o locale) tutti i possibili errori di
disco o di database. Ricordarsi anche che un indice corrotto potrebbe
non dare luogo ad alcun errore ma causare problemi logici e
disallineamenti vari nei dati del database.
EMG

 disallineamenti vari nei dati del database.
Secondo me, si deve tener conto di questo soprattutto nel design 
del database, bisogna evitare il piu' possibile di avere nel DB dati
che vengono desunti da altre porzioni di DB, ad esempio non ci
si deve affidare in modo univoco ad un file di numeratori per
trovare i progressivi, oppure si puo' evitare di memorizzare
progressivi di giacenza o progressivi contabili quando si riesce
ad ottenere questi dati con una elaborazione non eccessivamente
pesante.


Quali sono gli strumenti che usi per rimediare in caso di danneggiamento dei
Memo ?

 pesante.
Tutto vero, ma questa "elaborazione" probabilmente utilizzerà un indice.
Altrimenti sarà, temo, "eccessivamente pesante" (anche se, in generale,
non è detto...).
EMG

 Memo ?
Purtroppo mi sa che se si danneggiano c'è ben poco da fare, in
generale... :-(
EMG

 non è detto...).
Vero, ma dopo la ricostruzione degli indici si tornano ad ottenere
dati corretti, invece con un design di database inadeguato si possono
perdere dati.


 perdere dati.
Se l'elaborazione di cui parli ottiene, ad esempio, il prossimo codice
grazie ad un indice, ricostruendo gli indici non si risolve il fatto
che, nel frattempo, potresti aver generato dei codici non corretti.
Purtroppo penso che il problema non sia affatto di facile soluzione...
EMG

 D'altronde anche dire che la colpa è dei DBT è un atto di fede, no?
No, e' la constatazione di un problema nei memo, saltano i riferimenti.


 Memo ?
Te li mando in e-mail dato che sembra le l'NG non accetti attachments.


 No, e' la constatazione di un problema nei memo, saltano i riferimenti.
Non confondere la causa con l'effetto. Quello che tu vedi è, appunto,
l'effetto e purtroppo ciò non ti dà alcuna indicazione sulla causa...
:-(
EMG

 Te li mando in e-mail dato che sembra le l'NG non accetti attachments.
E' vietato dal regolamento di Usenet. Comunque, quali sarebbero e come
funzionano esattamente questi strumenti di cui parli?
EMG

valutazione costi/benefici.
Nel caso di un normale 'data entry' il commit non e' avvertibile, nel
caso invece di un aggiornamento di diversi record basta 'usare' il
file in exclusive.
ciao, acc.   
a...@libero.it

 Claudio Driussi wrote:

C'e' un programma che si chiama DBTCHK che controlla gli errori dei DBT,
segnala tutta una serie di anomalie tra cui riferimenti duplicati, dimensione
errata ed altri, questo programma e' in grado di riparare alcuni di questi
errori ma non tutti, per ovviare a questo mi sono scritto un utility che 
riscrive interamente il file ed e' efficace (per quanto l'ho testata).
8<--------8<--------8<--------8<--------8<--------8<--------8<--------
static lNew
static getlist := {}
function main(cFile)
  local aOld, i, j, t
  local aStru := { {"NREC",'N',8,0}, {"ISDEL",'L',1,0} }
  if cFile == nil
    ? "scrivere: rememo <cNomeFile>"
    ?
    return nil
    endif
  use (cFile) alias old new
  // -------------- preparo la struttura del file d'appoggio
  aOld := dbstruct()
  for i := 1 to len(aOld)
    if aOld[i,2] == 'M'
      aadd(aStru,aOld[i])
      endif
    next i
  if len(aStru) == 2
    ? "il file non contiene campi memo"
    ?
    return nil
    endif
  // ------------- apro il file d'appoggio
  dbcreate("_TT",aStru)
  use _TT alias temp new
  clear
  ? "*** COPIA DATI SU TEMPORANEO ***"
  ?
  sele old
  copy to _tt sdf
  clear
  ? "*** PREPARA FILE D'APPOGGIO ***"
  ?
  @ 3,1 say "Record:"
  @ 4,1 say "Campo :"
  sele old
  go top
  while !eof()
    @ 3,9 say recno()
    lNew := .f.
    if deleted() ; newTemp() ; endif
    for i := 1 to len(aOld)
      if aOld[i,2] == 'M'
        t := fieldget(i)
        if !empty(t)
          newTemp()
          for j := 1 to len(aStru)
            if aStru[j,1] == aOld[i,1]
              sele temp
              fieldput(j,t)
              @ 4,9 say pad(aStru[j,1],10)
              sele old
              endif
            next j
          endif
        endif
      next i
    sele old
    skip
    enddo
  clear
  ? "*** LEGGI DATI DA TEMPORANEO ***"
  ?
  sele old
  zap
  append from _tt sdf
  clear
  ? "*** CARICA DATI DA FILE D'APPOGGIO ***"
  ?
  @ 3,1 say "Record:"
  @ 4,1 say "Campo :"
  sele temp
  go top
  while !eof()
    sele old
    goto temp->nrec
    @ 3,9 say recno()
    if temp->isdel
      delete
      endif
    for i := 3 to len(aStru)
      sele temp
      t := fieldget(i)
      if !empty(t)
        for j := 1 to len(aOld)
          if aStru[i,1] == aOld[j,1]
            sele old
            fieldput(j,t)
            @ 4,9 say pad(aStru[i,1],10)
            endif
          next j
        endif
      next i
    sele temp
    skip
    enddo
  CLOSE DATABASES
  DELETE FILE _TT.TXT
  DELETE FILE _TT.DBF
  DELETE FILE _TT.DBT
return nil
// ---------- crea un nuovo record del file d'appoggio
function newTemp()
  if lNew ; return nil ; endif
  sele temp
  append blank
  temp->nrec  := old->(recno())
  temp->isdel := old->(deleted())
  sele old
  lNew := .t.
return nil
8<--------8<--------8<--------8<--------8<--------8<--------8<--------


 file in exclusive.
Perché? Non mi sembra che la modalità di apertura, esclusiva o
condivisa, del file possa influire sul tempo necessario alla COMMIT a
scrivere le modifiche sul disco. Io direi, invece, che basta mettere
COMMIT alla fine dell'aggiornamento.
EMG

 riscrive interamente il file ed e' efficace (per quanto l'ho testata).
Grazie, me la sono salvata. Non si sa mai...
EMG

COMMIT alla fine dell'aggiornamento.
Non mi sono spiegato bene...mi riferivo al caso in cui stai
effettuando un pesante aggiornamento, come ad esempio un'importazione
dati, in questo caso e' preferibile che il file sia bloccato agli
altri utenti. Certo sempre che l'operazione sia 'intensiva' e non duri
un'eternita'.
ciao, acc.   
a...@libero.it

 un'eternita'.
Ok, ma l'apertura esclusiva e il COMMIT sono due cose indipendenti,
giusto?
EMG

 ha scritto nel
messaggio news:3BCD3807...@emagsoftware.it...


 Se a qualcuno interessa, magari disposto a riscriverla migliorandola...
Io uso da sempre una funzione del genere che viene eseguita
automaticamente, quando faccio la manutenzione degli archivi, assieme al
PACK e alla ricostruzione degli indici. Forse anche questa č una delle
cose che mi evita problemi con i DBT.
EMG
-----------------------------------
EMAG Software homepage
http://www.emagsoftware.it
The EMG's ZX-Spectrum Software Page
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games
http://www.emagsoftware.it/tbosg

giusto?
Ovviamente.
Aggiungo soltanto che dove lavoro abbiamo una procedura Clipper che
lavora in rete su 12 macchine (win98); gli archivi sono tutti su
un'unica macchina, e finora non ci sono mai stati problemi.
ciao, acc.   
a...@libero.it

 un'unica macchina, e finora non ci sono mai stati problemi.
E usi pesantemente i campi memo DBT?


E usi pesantemente i campi memo DBT?
Credo che "pesantemente" sia proprio la parola giusta, arrivo anche a
quattro campi memo su certi archivi (tutti CDX/FPT).
Oltre all'uso classico (note etc.) io li uso (forse un po' ne abuso)
per memorizzare intere tabelle di dati, che vengono poi lette ed
elaborate in array.
Pensa che sono costretto a controllare la dimensione degli array
perche' il limite dei 4096 elementi viene spesso raggiunto.
Eppure funziona tutto perfettamente e per di piu' in rete (alla faccia
di Murphy), devo avere sbagliato qualcosa sicuramente :-?
ciao, acc.   
a...@libero.it

 ha scritto nel
messaggio news:3BCF1925...@emagsoftware.it...


 di Murphy), devo avere sbagliato qualcosa sicuramente :-?
Si, oppure hai fatto tutto per bene. Qualche volta ci si riesce... :-)


 Potrebbe essere utile a tutto il NG.
Hai ragione. Però è difficile concentrarsi veramente in un qualcosa che
attualmente non ti dà problemi...


DBF.
Scusate se mi intrometto, ma mi viene spontanea una domanda : questi
problemi, di cui si sta discutendo (e mi sembra una discussione molto
interessante) riguardo la corruzione dei DBT, esistono anche per altre
RDD, come ad esempio la DBFCDX (che io uso) ?
Personalmente non ho mai avuto corruzioni dei soli file memo, a volte
di dbf, ma sempre con qualche valido motivo.
Ciao.Alberto.
-------------------------------------------------------------
Alberto Rubinelli           Mail : 
alb...@retrocomputing.net
A2 SISTEMI                  Http : 
www.retrocomputing.net
Via Costantino Perazzi 22   Tel 0321 640149
28100 NOVARA (NO) - ITALY   Fax 0321 391769
ICQ : 49872318              Odigo : 5269083

 di dbf, ma sempre con qualche valido motivo.
Purtroppo con questo tipo di problemi non si è mai certi che un domani
non possano capitare, anche se si è scampati ad essi per anni... :-(


non possano capitare, anche se si è scampati ad essi per anni... :-(
Gia' ... purtroppo e' cosi'. Devo dire che per le applicazioni piu'
critiche uso ADS della Extended, almeno taglino un cavo di rete o
spacchino un pc per terra, i dati sul server sono integri :))


 spacchino un pc per terra, i dati sul server sono integri :))
Non ti cullare in queste false sicurezze che è pericoloso. Non esiste un
sistema software in grado di dare quel tipo di garanzie. Solo un sistema
hardware ridondante è in grado di darle, credo.
EMG
___________________________________
EMAG Software homepage
http://www.emagsoftware.it
The EMG's ZX-Spectrum Software Page
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games
http://www.emagsoftware.it/tbosg
___________________________________

hardware ridondante è in grado di darle, credo.
Certo, non mi illudo ... spero solo di avere un po' di vantaggio :))
