Newsgroup: it.comp.lang.vo-clipper
Titolo: Problemi cancellazione record

Ho una procedura (VO 2.5) molto semplice che azzera 2 campi di un database
(ENTRATO ed USCITO) mostrando la progressbar ed un contatore di record.
Dopo aver elaborato circa 550.000 record l'applicazione rallenta di colpo
(scrive
una decina di record al secondo) passando un record ogni 15 MINUTI !!!
Qualcuno ha qualche idea del motivo ?
Il S.O. č  W2000 , il PC č un Pentium IV .


 // azzeramento Dislovar //
 SELF:oDCPBar:Range:=Range{0,100}
 SELF:oDCPBar:UnitSize := 1
 SELF:oDCPBar:Position := 0
 SELF:oDCSC_Descri:Caption := "Azzeramento Dislocazioni T/V"
 FatAv := Integer(oSrv_DV:RecCount/100)
 IF FatAv < 100
  SELF:oDCPBar:Range:=Range{0,oSrv_DV:RecCount}
  FatAv := 1
 ENDIF
 oSrv_DV:gotop()
 i := 1
 ii := 1
 WHILE .NOT. oSrv_DV:Eof
  IF i>=FatAv
      SELF:oDCPBar:Advance()
         i := 0
          ApplicationExec(EXECWHILEEVENT)  // già provato a toglierlo
         CollectForced() // già provato a toglierlo
        ENDIF
     SELF:oDCSC_Record:Caption := AllTrim(Str(ii,10,0)) //già provato a
toglierlo
     ii:=ii+1
     i:=i+1
  Giabloccato(oSrv_DV , oSrv_DV:RECNO)  // funzione per il controllo di
blocco del record
  oSrv_DV:FIELDPUT( #entrato, 0 )
  oSrv_DV:FIELDPUT( #uscito, 0 )
  oSrv_DV:FIELDPUT( #giacenza, 0 )
     oSrv_DV:skip(1)
 ENDDO
 oSrv_DV:Commit()

>   Giabloccato(oSrv_DV , oSrv_DV:RECNO)  // funzione per il controllo di
blocco del record
Ciao Alessandro,
hai provato a bloccare il file all'inizio della procedura e sbloccarlo alla
fine, per evitare la funzione di blocco record?
Non so se è compatibile con le esigenze operative del tuo programma, ma
credo che velocizzeresti di molto la routine, a prescindere dall'anomalia
segnalata.
                    Francesco Leo

Ciao Alessandro,
hai provato a spostare il commit all'interno del ciclo?
    oSrv_DV:FIELDPUT( #entrato, 0 )
    oSrv_DV:FIELDPUT( #uscito, 0 )
    oSrv_DV:FIELDPUT( #giacenza, 0 )
    oSrv_DV:Commit()
    oSrv_DV:skip(1)
 ENDDO
Saluti
Mario Costantino

 ha scritto nel
messaggio news:b%aia.39030$Jg1.9...@news1.tin.it...


hai provato ad utilizzare la sintassi clipper :
select ("alias")
// ciclo while
_field->uscito := 0
_field->entrato := 0
_field->giacenza := 0
vodbskip(1)
che è circa una 60 di volte piu' veloce (su disco fisso;  in rete molto
meno) rispetto ad utilizzare l'oggetto.
utilizzare il file in esclusiva e togliere la funzione giabloccato()
togliere collectforce() ed utilizzare la commit() all'interno del ciclo ma
con un intervallo di uno a 10 rispetto al ciclo.
ciao,
      Fabrizio Malaguti

  ENDDO
Scusate, non ricordo bene quale fosse il problema lamentato, ma se
riguardava la velocità, certamente mettere il Commit all'interno del
ciclo aggraverà enormemente la situazione (a meno, ovviamente, di
eventuali ottimizzazioni automatiche eseguite dal compilatore).
EMG
--
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg

Il S.O. è  W2000 , il PC è un Pentium IV .
Mario Costantino

 meno) rispetto ad utilizzare l'oggetto.
Azz! Possibile? Ma allora chi č quel pazzo che userebbe l'oggetto???


 ha scritto nel
messaggio news:5b%ha.37205$Jg1.8...@news1.tin.it...



 Azz! Possibile? Ma allora chi è quel pazzo che userebbe l'oggetto???
Si utilizzano gli oggetti per comodita' e perche' è estremamente flessibile
utilizzarli.
Mi spiego meglio:
utilizzando gli oggetti è possibile mantenere (per quanto possibile)
invariata la sintassi (polimorfismo ) per leggere sia i DBF che i  database
SQL.
La lentezza deriva da una particolarita' introdotta dalla CA ovvero quella
di poter linkare lo stesso motore di database ( in questo caso l'oggetto
della classe dbserver) a una o piu' finestre con lo scopo di aggiornarle
simultaneamente ed in automatico ad ogni evento (cancellazione di record,
modifica di campi, ecc). Il classico esempio è quello di avere due finestre
aperte sullo stesso database una in Browse e l'altra in Form_view (si scrive
cosi'?). Spostando il cursore da un Rk all'altro della prima finestra
ottengo l'aggiornamento automatico sulla seconda (senza impazzire tanto su
come gestire il tutto, in quanto automatico).
Tutta questa gestione ha un enorme peso e fino ai Pentium II si notava
moltissimo. Tanto che il paragone tra la classe Tbrowse del Clipper e quella
analoga del VO era stravinto dal primo 1000 a 1. Secondo me uno dei motivi
per il quale gli utenti si siano buttati su altre soluzioni era proprio
questo: la lentezza nel gestire databases e la Browse.
Io dopo vari tentativi ho individuato i punti dove è doveroso utilizzare gli
oggetti  (gestione di mappe interattivi con l'utente, dove la velocita' non
serve) e quelli dove posso utilizzare la sintassi Clipper (praticamente in
tutte le lavorazioni Batch). Mentre nel primo caso se mi cambia il tipo di
database non cambio praticamente nulla nel codice (es: passando da DBF a
SQL ) nel secondo caso occorre cambiare tutto. Dal momento che di solito
utilizzo la seconda forma nelle librerie mi basta creare una libreria
specifica per ciascun database utilizzato cosi' da mantenere praticamente
invariato il codice del programma principale mantenendo comunque sempre il
massimo della velocita' di esecuzione.
ciao,
      Fabrizio Malaguti


 La lentezza deriva da una particolarita' introdotta dalla CA
Bella particolarità! Gli oggetti analoghi disponibili con le Fivewin
sono veloci esattamente come i normali comandi Clipper...


Innanzitutto se il Server è il Server di un Browser, devi fare
SELF:oSFMioBrowser:Server:SuspendNotification() ... in tal modo interrompi
il processo di notifica che VO fa al server del Browser per ogni variazione
!!!  (dopo ...all'ultimo farai
SELF:oSFMioBrowser:Server:ResetNotification() )
Poi... devi mettere la Commit FUORI dal ciclo altrimenti ti rallenta in modo
sensibile, poiché deve scaricare il buffer dalla memoria al Disco per ogni
ciclo (sai che pa...e !!!). In questo modo io non ho mai avuto problemi di
velocità sia in cancellazione records che in aggiornamento dati.  Il Commit
lo farai a fine ciclo. Se devi bloccare il file o i records per gestire
l'accesso concorrenziale in rete, ti consiglio di fare un Lock dell'intero
file !!! questo perché quando ci sono operazioni che coinvologono molti
record è buona norma bloccare il file.
Ciao
Enio

Mai provato ClassMate con VO ?
Provare per credere .....
Ciao a tutti
"Fabrizio Malaguti" <fabrizio...@NOSPAMsispaghe.it> ha scritto nel
messaggio news:b6cfgq$iv7$1...@newsreader.mailgate.org...


 ha scritto nel
messaggio news:5b%ha.37205$Jg1.8...@news1.tin.it...



Volevo intanto ringraziare tutti per l'interessamento.
Il problema non risiede nel codice VO ma in un problema di memoria del
SERVER.
Il server W2000 funzionava con solo 128 MB Ram (dovrò tirare le orecchie al
sistemista), aumentando la memoria a 512MB il problema si è risolto.
Con i 128 Mb probabilmente lavorava al limite quindi dopo aver allocato e
teminato la
memoria ram , utilizzava il disco fisso rallentando in modo inesorabile.
GRAZIE  ancora a tutti.
Alessandro.


... oppure fare preventivamente il lock di tutti e soli i record che devi
cancellare
(per garantire l'integrità ref. DB) e poi, se riesce, cancellare.
A volte il blocco dell'intero file è impossibile (se devo cancellare i
record relazionati ad una testata...)
Ciao
Massimo

>> Il problema non risiede nel codice VO ma in un problema di memoria del
SERVER.
Porta pazienza ma non ho ancora capito se all'interno del ciclo il record
viene sbloccato immediatamente o NO

 ha scritto nel messaggio
news:b6jb0s$61o96$1...@ID-115129.news.dfncis.de...

No non sblocco mai il record . Non ho mai riscontrato problemi sul
lock/unlock
sia con Clipper che con VO.
Se guardi nel terzo msg c'e' una parte (semplificata) del codice utilizzato.

 lock/unlock sia con Clipper che con VO.
Se devi bloccare tutti i record uno alla volta allora non č meglio se
blocchi l'intero file all'inizio?


 Se devi bloccare tutti i record uno alla volta allora non è meglio se


 costringerebbe ad uscire ed aspettare .
Infatti per questo ho scritto "se devi bloccare *tutti* i record".
Ovviamente se ne devi bloccare solo alcuni allora va benissimo il
lock/unlock (anche singolarmente, non mi risulta che il lock/unlock
rallenti alcunché, almeno in Clipper).
