Newsgroup: it.comp.appl.access
Titolo: Il saggio uso dell'opzione /Decompile per risolvere problemi

Ieri ho messo mani su un mio applicativo sul PC di un cliente per modificare
una cosa del codice.
Ho aggiunto una riga, nulla più e niente di eccezionale.
Vado a compilare, e mi da un errore con crash di Access dicendo che il
problema era con la libreria VBA332.dll.
Da quel momento in poi non sono riuscito più ad avviare l'applicativo (cioè
se entravo con lo SHIFT premuto, entravo, ma poi non riuscivo ad compilare
il codice nè ad aprire maschere o report).
Ho provato ad importare tutto in un DB vuoto, ma mentre i moduli, le query e
le tabelle non mi hanno dato problema, crashava con i report e le maschere.
Alla fine ho provato a lanciare l'applicativo con l'opzione /Decompile e mi
ha detto che la versione del codice era aggiornata al visual basic corrente,
e quindi il problema si è risolto.
Ricordo a tutti di provare ad utilizzare questa opzione per malfunzionamenti
"strani"
Comunque chiedo a qualcuno se conosce cosa poteva essere successo e cosa ha
comportato l'uso dell'opzione in oggetto.
Antonio


se ogni tanto facessi F1 invece di rompere gli "zebbedei" ;<) non sarebbe male.
ti ho trovato questo vedi se e' una "weak preconditions...."
This post is to give a little historical background and info
on this undocumented command line switch in msaccess.exe. To
use it, you simply run
msaccess /decompile <your database name>
and thats all there is to it. But what exactly does it
do?????
VBA AND THE 11 STATES OF COMPILATION
Thats right, internally there are 11 different compilation
levels between decompiled and fully compiled like you would
find in an MDE. As you make objects dirty, you will
decompile the project, but dirtying Module1 does not remove
all the "compiled" info about Module2 or Form1, for example.
The exact levels are impossible to even detect unless you
have source and debugging symbols for VBA, and insanely
difficult even then.... so lets just leave it as read that
the yes/no question of "is it compiled?" has many
subcategories under the NO answer that essentially mean its
not compiled but some parts of it are kind of.
P-CODE VERSUS CANONICAL TEXT
Your code is stored in two forms, each one of which is a
Stream object in the project's storage(s). One form is the
canonical text that you look at and edit and such, the other
is the compiled version of the code that runs. VBA must
always compile before it runs, so in an app that runs you
will always find p-code. And unless you are running in an
MDE (where the canonical code is stripped out) you will
always have the canonical text too. Any time VBA thinks that
the compiled code is invalid (such as when you make a change
or the binary format changes, which is so far only during
beta cycles), it will "decompile" the module and then
compile it again from the canonical text.
ACCESS BETAS: BINARY FORMATS, ETC.
People who were on the betas for Access 95, 97, and/or 2000
will remember the binary format issues. From build to build,
changes would be made in VBA or in the Access OM which would
make old compiled code invalid. Usually a crash is the best
you could expect. To help fix this, some work was done to
have a global way to decompile *ALL* code that is present in
a project so that you do not risk having any invalid code
that might crash.
**********
This is the reason the flag is there and the only reason.
The command line switch is undocumented because there is
never a binary format change except during betas and in
internal builds.... so there is no reason to document
something never intended to be used.
**********
NOW there are some positive benefits that are side effects
that people have made use of:
1) SIDE EFFECT: CORRUPTED PROJECTS
Now, as a side effect, you have a way to deal with corrupt
projects! You see, the canonical text is never what is
corrupted, it is always some compiled portion of a project,
like a module or most commonly the typeinfo of a form or
report. By globally telling Access that the compiled portion
should be thrown away, you get rid of whatever the bogus
piece of code is. Now this kind of fix is what would have
taken care of the old Access93 vba232 page faults and other
problems where Access was walking off the end of a vtable
and crashing, as well as a zillion other such little
problems. This is what made PSS first expose this flag
for.... if a project is corrupted, this is the best way to
uncorrupt it.
2) SIDE EFFECT: PROJECT SIZE
It was found that there are times where an object would be
decompiled and while the Stream object from the strorage
would be properly invalidated, it would be orphaned and left
in the Storage, and then would not be cleaned  up later.
There are many applications that use structured strorage
that have such a problem in their garbage collection... VBA
and Access are just one of them, thats all. Over time, these
orphaned streams will contribute some bloat to the project.
People noticed that a fully compiled app would take up more
space than the same app fully compiled with all objects
imported to a new database..... and that is the very issue
being discussd here. As you may have guessed, the /decompile
switch, which invalidates *all* streams that contain
compiled code, does an effective job of garbage collection
and removes these orphaned streams. Thus, a /decompile
/compact will make for the smallest possible size of as
database.
RISKS TO DECOMPILE: WHY YOU SHOULD NOT USE IT CONSTANTLY
If you think about the mechanism, you are relying on the
canonical text always being completely valid, and you are
relying on the ability to globally invalidate a compiled
state. If there is ever a problem in either area, /decompile
will take a project that was working fine and turn it into
cottage cheese. And while such bugs should not happen.... it
is impossible to make a /decompile bug happen without using
/decompile. They simply did not extensively test a command
line switch that was never meant to be used.... nor should
they have to, really.
SO, PLEASE REMEMBER that this is a very powerful technique
that was added for reasons having nothing to do with any of
the reasons that you may want to use it now. It may help you
save an otherwise hopelessly corrupted project. But use it
sparingly as you may end up in a worse situation than you
started by just globally using the switch on projects that
do not need it.
IF IT AIN'T BROKE, DON'T FIX IT.
--
a.cara 
Togli qualcosa dall'email

 ti ho trovato questo vedi se e' una "weak preconditions...."
C'ho qualcosa da leggere stasera...
Grazie mille
Antonio

 IF IT AIN'T BROKE, DON'T FIX IT.
P.S. dimenticavo l'autore e' Michael Kaplan (
www.trigeminal.com
) 
che a quanto pare e' uno dei "piu'" di access.


 che a quanto pare e' uno dei "piu'" di access.
Me lo sono letto.
Pare che il mio sia stato un bug conosciuto di progetto corrotto dovuto a
qualcosa tipo sforamenti sulle vtable o qualcosa del genere.
Certo che il tipo č piuttosto criptico e scrive con una sintassi veramente
ostica!!!
Antonio

SEI TU CHE NON CAPISCI UN CAZZO


Perchč questa risposta cosě da maleducato ?
Giuseppe


Sta litigando con A. Biso ed "ovviamente" invece di combinare un appuntamento
da qualche parte per darsele "pensa" bene di fare sfoggio di aulico turpiloquio,
nonche' essendo periodo sta cercando di vendere le sue "fave". Il tutto
sempre "ovviamente" rompendo i cosidetti al prossimo.
Insomma tipico esempio di cristiano caritatevole




 Insomma tipico esempio di cristiano caritatevole
Scusa Alessandro, che vòr dì "aulico turpiloquio"?
Antonio.

 compile it again from the canonical text.
P-code contro testo canonico
Il tuo codice viene registrato in due maschere, una delle quali è un oggetto
Stream (ndr - nel senso di flusso) nell'archivio del progetto.
Una maschera è il testo canonico che puoi vedere e su cui puoi lavorare,
l'altra è la versione compilata prima che venga lanciata, quindi in un
appliacazione che viene lanciata tu puoi sempre trovare il p-code.
E senza che tu stia lavorando in una versione MDE (dove il codice canonico
viene
"tirato via") tu puoiavere anche il codice canonico.
Ogni volta che VBA ritiene che il codice compilato sia invalido
(come quando compi una variazione o cambi il formato binario, che è così
distante
solo durante i cicli beta), lui decompilerà il modulo per poi
compilarlo dal codice canonico.
[NDR - Per ora basta, torno a far finta di lavorare - Il fascicolo 2
sempre su questo NG prossimamente]
ciao MAssimilaino
p.s. Ah ragazzi, se qualcuno continua la mia opera no mi offendo,
tanto è un Open source..
--------------------------------
Inviato via 
http://usenet.libero.it

MA wrote:
[cut]

a MA io sto pezzo io l'avrei tradotto cosi'
Il codice viene registrato in due "formati" ognuno dei quali e' un file
nell'ambito del progetto. Uno e' nel classico formato testo, quello che in
genere viene visualizzato e modificato, l'altro e' il formato compilato
utilizzato per la esecuzione.
Il VBA deve essere sempre prima compilato per poter
essere eseguito, quindi, in una applicazione eseguibile ci sara' sempre
un codice compilato (p-code). A meno che non si stia eseguendo un MDE
(dove il codice canonico (testo) e' stato eliminato) ci sara' sempre
in un Db (MDB) sia il formato testo che il formato compilato.
Ogni volta che VBA "ritiene" che il codice compilato sia invalido
(cioe' quando si fanno modifiche o il formato binario cambia, il che 
avviene nelle versioni beta) il modulo verra' "decompilato" e ricompilato
a partire dal formato testo.



Ottimo, io l'ho tradotto di getto e sono solito tradurre prima +o-
letteralmente poi aggiusto la forma.
Cmq la tua è molto + sciolta.
ciao MAssimiliano


 Antonio.
Il mio è  Microsoft Outlook Express 5.50.4807.1700
Antonio

 SEI TU CHE NON CAPISCI UN CAZZO
Sì ciccio, hai ragione tu...
In fondo da uno che viene da Oxford come te, non si può pretendere un
esempio di (MAL)educazione migliore...
Complimenti...
Antonio

 Complimenti...
Il mio è questo:  5.50.4522.1200
Antonio