Newsgroup: it.comp.lang.visual-basic
Titolo: [DAO BIG BUG] If Compatto_L_mdb Then A_volte_butto_via_tutto!

Ciao a tutti,
ho un ENORME problema (leggi spada di Damocle che sta per cadere sul mio
collo...)
Ho realizzato un programma enorme (a dir poco) di presenze in VB6 SP5, usa
DAO 3.5 (mdac 2.1) e supporta Plug-In ActiveX.
All'avvio del software eseguo una compattazione dell'mdb, che altrimenti
diventerebbe enorme. Tutto bene, funziona egregiamente, MA... in modo
casuale, imprevedibile e misterioso (tipo una volta su 1000 circa) la
compattazione crea una cosa crudele che mi sta uccidendo: mi trovo con il
mio mdb che, udite udite, ha UserName e Password IGNOTI! In realtą non č
vero, perchč non c'č SYSTEM.MDW (o come diamine si chiama) sul pc client, e
non č possibile che nessuno abbia fatto questo scempio, č successo a 3
clienti diversi, e dai log del sw sembra proprio la compattazione.
Cosa diavolo č? Perchč succede questo? Come evitarlo? E' successo a
qualcuno? (vi prego, date segni di vita, vi prego!)
L'unico programma in grado di recuperare i dati (e quindi non andare in
tribunale) č Access Recovery, e costa 399$, grazie M$, una bella stabilitą
dei dati!
P.S.: Probabilmente passando ad ADO e usando l'mdac 2.6 questo potrebbe non
succedere, ma ho tanti clienti lontani, e un lavoro di restyling cosģ ampio
non č previsto in breve termine, e che cavolo, non č che se non installi
l'ultima release non deve andare niente!!!
PLEASE, PLEASE, PLEASE HELP!!!
Grazie,
Henrik Sozzi
www.oasidigitale.it
www.innovaweb-design.com

PLEASE, PLEASE, PLEASE HELP!!!
evita questo, per favore, non serve a nulla, irrita e basta.
Piuttosto, posta qualche informazione piu' "precisa" (vedi domande fatte sopra).
ciao, hal

 ha scritto nel messaggio
news:X8nH6.3778$_r2....@news2.tin.it...
| Ciao a tutti,
| ho un ENORME problema (leggi spada di Damocle che sta per cadere sul mio
| collo...)
| Ho realizzato un programma enorme (a dir poco) di presenze in VB6 SP5, usa
| DAO 3.5 (mdac 2.1) e supporta Plug-In ActiveX.
|
| All'avvio del software eseguo una compattazione dell'mdb, che altrimenti
| diventerebbe enorme. Tutto bene, funziona egregiamente, MA... in modo
| casuale, imprevedibile e misterioso (tipo una volta su 1000 circa) la
| compattazione crea una cosa crudele che mi sta uccidendo: mi trovo con il
| mio mdb che, udite udite, ha UserName e Password IGNOTI! In realtà non è
| vero, perchè non c'è SYSTEM.MDW (o come diamine si chiama) sul pc client,
e
| non è possibile che nessuno abbia fatto questo scempio, è successo a 3
| clienti diversi, e dai log del sw sembra proprio la compattazione.
| Cosa diavolo è? Perchè succede questo? Come evitarlo? E' successo a
| qualcuno? (vi prego, date segni di vita, vi prego!)
| L'unico programma in grado di recuperare i dati (e quindi non andare in
| tribunale) è Access Recovery, e costa 399$, grazie M$, una bella stabilità
| dei dati!
|
| P.S.: Probabilmente passando ad ADO e usando l'mdac 2.6 questo potrebbe
non
| succedere, ma ho tanti clienti lontani, e un lavoro di restyling così
ampio
| non è previsto in breve termine, e che cavolo, non è che se non installi


 ha scritto nel messaggio
news:9clojl$e66$1...@serv1.iunet.it...


Mb, 
sono quei 20-30 MB che mi preoccupano, sino qualche tempo fa access li gestiva
male, magari le nuove versioni hanno ovviato al problema.
Hai pensato di suddividere l' mdb in piu' mdb di minori dimensioni, piu' uno
che contiene solo tabelle allegate, in modo che per il tuo programma
non cambi nulla ?
ciao, hal

backup.
La CompactDB esegue di per sè una Repair, che comunque male non gli fa.
Il problema è che se si perde un file esterno (nel tuo caso quello
contenente query per reperire info sul tuo file mdb) non c'è repair che
tenga: devi ripristinare il file MDW!
Fatti una copia di quello, non dell'MDB!
Ciao

 ha scritto nel messaggio
news:3WBH6.6491$_r2....@news2.tin.it...


 male, magari le nuove versioni hanno ovviato al problema.
Scusa hal, è un pò che non appoggio i programmi "corposi" a file mdb ma a
Msde/Sql Server, ma onestamente ho ampiamente passato in passato (perdonami
il gioco di parole) la dimensione suddetta, assolutamente senza problemi.
Semmai trovo abbastanza inutile eseguire così frequenti compact mdb se le
dimensioni in gioco sono queste. E' uno stress inutile per il database, che
non ha certo la solidità di un Oracle o di un Sql server.
In ogni caso, personalmente, raccomando anch'io di eseguire prima di ogni
compact una copia del file ed eventualmente una repair preliminare (allego
due sub che usavo ai tempi, spero vadano ancora bene, non le ho
riguardate...)
ciao
ugo
Sub Database_Compact()
    On Error GoTo REPERR
    Dim name, name1, datanum As String
    Dim Response As Integer
    If CheckRights(rgtMANUDB) = 2 Then    ' quesya era una verifica dei
diritti utente sull'operazione
        Response = MsgBox("Attenzione: il compattamento del database
richiede la CHIUSURA degli archivi da parte degli altri utenti." & vbCrLf &
_
                "Accertare che nessun utente utilizzi " &
app.FileDescription & " e procedere a una copia preliminare dell'archivio."
& vbCrLf & _
                "Si consiglia di contattare il servizio tecnico." & vbCrLf &
"Procedere con il compattamento dati?", vbOKCancel + vbDefaultButton2 +
vbExclamation, "Compattamento Database")
        If Response = vbOK Then
            SetHourglass
            datanum = Str(Day(Date)) & Str(Month(Date)) & Str(Year(Date))
            name = cDbPath & "Old" & datanum & ".mdb"
            name1 = cDbPath & "Compact" & datanum & ".mdb"
            CloseChilds
            Database_close
            FileCopy cDbPath & cDbName, name
            FileCopy cDbPath & cDbName, name1
            Kill cDbPath & cDbName
            On Error GoTo MAINERR
            DBEngine.CompactDatabase name1, cDbPath & cDbName
            On Error GoTo REPERR
            Database_Init
            Screen.MousePointer = vbDefault
        End If
    Else
        MsgBox "Nessun Diritto di accesso alla Manutenzione Archivi!" &
vbCrLf & "" & vbCrLf & "", vbOKOnly + vbDefaultButton1 + vbCritical,
"Manutenzione Archivi"
    End If
    Exit Sub
REPERR:
    MsgBox "Impossibile Compattare i dati. Contattare il servizio
assistenza.", vbOKOnly + vbDefaultButton1 + vbExclamation, "ATTENZIONE"
    Screen.MousePointer = vbDefault
    Exit Sub
MAINERR:
    MsgBox "Errore nella compattazione dati. Contattare il servizio
Assistenza.", vbOKOnly + vbDefaultButton1 + vbCritical, "Errore nel
Ripristino Dati"
End Sub
Sub Database_repair()
    On Error GoTo REPERR
    Dim name, name1, datanum As String
    Dim Response As Integer
    If CheckRights(rgtMANUDB) = 2 Then
        Response = MsgBox("Attenzione: il recupero dei dati danneggiati
richiede la CHIUSURA degli archivi da parte degli altri utenti." & vbCrLf &
_
                "Accertare che nessun utente utilizzi " &
app.FileDescription & " e procedere a una copia preliminare dell'archivio."
& vbCrLf & _
                "Si consiglia di contattare il servizio tecnico." & vbCrLf &
"Procedere con il recupero dati?", vbOKCancel + vbDefaultButton2 +
vbExclamation, "Recupero Database")
        If Response = vbOK Then
            SetHourglass
            datanum = Str(Day(Date)) & Str(Month(Date)) & Str(Year(Date))
            name = cDbPath & "Old" & datanum & ".mdb"
            name1 = cDbPath & "Repair" & datanum & ".mdb"
            CloseChilds
            Database_close
            FileCopy cDbPath & cDbName, name
            FileCopy cDbPath & cDbName, name1
            Kill cDbPath & cDbName
            On Error GoTo MAINERR
            DBEngine.RepairDatabase name1
            DBEngine.CompactDatabase name1, cDbPath & cDbName
            On Error GoTo REPERR
            Database_Init
            Screen.MousePointer = vbDefault
        End If
    Else
        MsgBox "Nessun Diritto di accesso alla Manutenzione Archivi!" &
vbCrLf & "" & vbCrLf & "", vbOKOnly + vbDefaultButton1 + vbCritical,
"Manutenzione Archivi"
    End If
    Exit Sub
REPERR:
    MsgBox "Impossibile Ripristinare i dati. Contattare il servizio
assistenza.", vbOKOnly + vbDefaultButton1 + vbExclamation, "ATTENZIONE"
    Exit Sub
MAINERR:
    MsgBox "Errore nel ripristino dati. Contattare il servizio Assistenza.",
vbOKOnly + vbDefaultButton1 + vbCritical, "Errore nel Ripristino Dati"
End Sub

ecc. vanno piuttosto veloce...
bene, vuol dire che lo hanno migliorato nel frattempo, come anche confermava Ugo.
meglio cosi' :)
ciao, hal
p.s.
l'idea di Zanna sull' mdw mi sembra azzeccata.

 <... 2 SUB ...>

 non cambi nulla ?
uso abbastanza spesso un mio vb con db access97. scandisce cd, zip compresi,
e mette il risultato in 3 tabelle.
sono arrivato abbastanza tranquillamente a 4 mln di righe nella tabella
file, con 600 mb di mdb, senza il minimo problema. con gli indici i seek
sono immediati. le query un po' meno, ma accettabili.
a volte i cd sono difettosi e inchiodano il programma. anche in questi casi,
pulisco tutte le righe relative all'ultimo cd e compatto. mai perso un bit.
(en passant: mi sono chiesto se le transazioni eviterebbero il problema. ma
alcuni cd scrivono 100k righe di file (record di ca 550 byte) e magari
10-20k di dir, e in ram si fa dura. le transazioni vengono gestite nello
swap?)
ciao, a.

Ma compattavi il DB ad ogni avvio del programma??? :-/
Oltre che essere uno stress per il DB stesso è uno stress per il cliente...
20-30 mega da compattare non so se siano una procedura abbastanza veloce...
e se uno nel giro di pochi minuti ti apre/chiude il prg un po' di volte???
CiaoZ
SebaMix

l'idea di Zanna sull' mdw mi sembra azzeccata.
Come al solito :P
Ciao

del genere?
Ricordati che parli di access!
A me questo non è mai successo, però te ne dico una su tutte: un mio
programma usava due DB (completamente differenti) Access97 tramite ODBC.
Un bel giorno mi chiama il cliente che si ritrovava entrambi i DB con la
stessa struttura!
L'ODBC si era copiato la struttura di un DB su quell'altro... (ovviamente
perdendo tutti i dati).
No comment.
Ciao

 ha scritto nel messaggio
news:wlYH6.9302$_r2.1...@news2.tin.it...


swap?)
Ho trovato, attraverso la solita msdn, il capitolo 7 dell' office resource kit,
titolato "Customizing and Optimizing Microsoft Office".
Verso meta' articolo tratta della proprieta' MaxBufferSize e, fra le varie considerazioni
sull' opportunita' o meno di manipolarne il valore, dice:
"
For computers with 16 MB or less of installed RAM, there is generally no need to 
override the calculated setting. 
For computers with 32 MB of RAM, however, you may see some performance improvement 
when specifying a larger MaxBufferSize, as long as no other applications are running at 
the same time as Access. 
For example, tests have shown performance improvements in applications that perform 
large transactions when a MaxBufferSize as large as 8 MB is specified. 
Specifying a MaxBufferSize larger than 8 MB has not been found to increase performance. 
Setting a value too high can degrade performance due to the added CPU overhead needed 
to manage the cache, and due to the fact that the operating system may start swapping the 
Microsoft Jet cache to disk as virtual memory. 
Important   
When you specify a MaxBufferSize setting larger than the default and you are not using the 
FlushTransactionTimeout setting, increase the SharedAsyncDelay setting to increase the time 
that data is held in the buffer. 
If you do not increase the value of SharedAsyncDelay, Microsoft Jet writes the contents of its 
buffer to the database before it has had time to utilize the additional memory you specified.
"
Sicche', almeno sulla carta, perche' non ho provato, Access dovrebbe reggere transazioni
anche piuttosto consistenti, a patto di affinare le impostazioni di MaxBufferSize e 
SharedAsyncDelay.
Chi si offre volontario per i test ?
ciao, hal

 ha scritto nel messaggio
news:9cpk3v$g8n$1...@pegasus.tiscalinet.it...


 ha scritto nel messaggio
news:9coook$eok16$1...@ID-66833.news.dfncis.de...


 ha scritto

senza fretta, e se nessuno dei molti piu' bravi e' disponibile, io. sto
lavorando su un mdbino che andra' a complicarsi. e ho quello grosso per
altre prove. ma dove le regolo le impostazioni in questione ?
fra l'altro, il manuale non dev'essere recentissimo: "with 16 mb or less of
installed ram" mi sa che ci sono rimasti solo alcuni telefonini :))
ciao a.
a prop: prima ho aperto mirc, non c'era nessuno, e lasciandolo aperto ho
portato j al parco. sono tornato proprio mentre te ne andavi tu. sara' per
un'altra volta.