The joy of decompiling...

[Deano]

Just wondering if there is a tool or method that will allow me to compare
the state of my database before and after I decompile it.

The last time I decompiled a few fields lost default values and some event
code wasn't firing anymore. I know that sounds unusual but this was
definitely the case.

I would like to decompile again but am reluctant to do so if it causes any
more problems. I would like to test what the decompile does to my database
by being able to accurately determine any subsequent changes in form
controls, table fields etc.

Any suggestions?

thanks
Martin
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.532 / Virus Database: 326 - Release Date: 28/10/2003

[TC]

"Deano" <ma************@hotmail.com> wrote in message
news:fY******************@wards.force9.net...

Just wondering if there is a tool or method that will allow me to compare
the state of my database before and after I decompile it.

The last time I decompiled a few fields lost default values and some event
code wasn't firing anymore. I know that sounds unusual but this was
definitely the case.
Er.... Default values are stored as column attributes. AFAIK, they are
nothing to do with the VBA Project (which is what the decompile alters). I
really can not see decompile affecting default values.

I would like to decompile again but am reluctant to do so if it causes any
more problems. I would like to test what the decompile does to my database by being able to accurately determine any subsequent changes in form
controls, table fields etc.

There is no way you will make any sense of a before/after comparison of the
mdb file. Most of the information is stored in binary structures. You will
not make any sense of *one* file - let along a before & after comparison -
unless you understand those structures: none of which are documented.

HTH,
TC

[Lyle Fairfield]

"TC" <a@b.c.d> wrote in news:1067404656.894978@teuthos:

"Deano" <ma************@hotmail.com> wrote in message
news:fY******************@wards.force9.net...

Just wondering if there is a tool or method that will allow me to
compare the state of my database before and after I decompile it.

The last time I decompiled a few fields lost default values and some
event code wasn't firing anymore. I know that sounds unusual but this
was definitely the case.

Er.... Default values are stored as column attributes. AFAIK, they are
nothing to do with the VBA Project (which is what the decompile alters).
I really can not see decompile affecting default values.

I would like to decompile again but am reluctant to do so if it causes
any more problems. I would like to test what the decompile does to my

database

by being able to accurately determine any subsequent changes in form
controls, table fields etc.

There is no way you will make any sense of a before/after comparison of
the mdb file. Most of the information is stored in binary structures.
You will not make any sense of *one* file - let along a before & after
comparison - unless you understand those structures: none of which are
documented.

HTH,
TC

After I decompiled all this hair started growing out of my ears.

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)

[Peter Russell]

Lyle Fairfield previously wrote:

After I decompiled all this hair started growing out of my ears.

See q8711234 - MSKB; known problem!

Peter Russell

[Deano]

TC wrote:

"Deano" <ma************@hotmail.com> wrote in message
news:fY******************@wards.force9.net...

Just wondering if there is a tool or method that will allow me to
compare the state of my database before and after I decompile it.

The last time I decompiled a few fields lost default values and some
event code wasn't firing anymore. I know that sounds unusual but
this was definitely the case.
Er.... Default values are stored as column attributes. AFAIK, they
are nothing to do with the VBA Project (which is what the decompile
alters). I really can not see decompile affecting default values.

That's kind of what I want to hear. But a key table did change after the
decompile. I certainly didn't go in and amend it. Very odd, I know I can't
prove that decompiling screwed it up - at the moment - but was hoping that
if I could record the state of play before decompiling then I could do a
comparison.
There is no way you will make any sense of a before/after comparison
of the mdb file. Most of the information is stored in binary
structures. You will not make any sense of *one* file - let along a
before & after comparison - unless you understand those structures:
none of which are documented.
I meant like a thorough printout of all objects in the db and their
attributes.

HTH,
TC

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.532 / Virus Database: 326 - Release Date: 27/10/2003

[Bri]

Deano wrote:
<snip>

There is no way you will make any sense of a before/after comparison
of the mdb file. Most of the information is stored in binary
structures. You will not make any sense of *one* file - let along a
before & after comparison - unless you understand those structures:
none of which are documented.

I meant like a thorough printout of all objects in the db and their
attributes.

Tools - Analyze - Documenter

This creates a report of all of the objects (user selectable) with all of their
properties. You could create one before and after for comparison.

HTH
Bri

[TC]

"Deano" <ma************@hotmail.com> wrote in message
news:wo******************@wards.force9.net...

TC wrote:

"Deano" <ma************@hotmail.com> wrote in message
news:fY******************@wards.force9.net...

Just wondering if there is a tool or method that will allow me to
compare the state of my database before and after I decompile it.

The last time I decompiled a few fields lost default values and some
event code wasn't firing anymore. I know that sounds unusual but
this was definitely the case.
Er.... Default values are stored as column attributes. AFAIK, they
are nothing to do with the VBA Project (which is what the decompile
alters). I really can not see decompile affecting default values.

That's kind of what I want to hear. But a key table did change after the
decompile. I certainly didn't go in and amend it. Very odd, I know I

can't prove that decompiling screwed it up - at the moment - but was hoping that
if I could record the state of play before decompiling then I could do a
comparison.

There is no way you will make any sense of a before/after comparison
of the mdb file. Most of the information is stored in binary
structures. You will not make any sense of *one* file - let along a
before & after comparison - unless you understand those structures:
none of which are documented.

I meant like a thorough printout of all objects in the db and their
attributes.

You could do that by writing some code. Or, I'm sure there are commercial
products. So before the decompile, run the code (or product) to create a
flat-file dump of the database structure. Then do the decompile, then run
the dump again to different files, then use a file-compare program to
compare the two versions. Or the other respondent's suggestion of
Tools:Analyzer might work also.

HTH,
TC

[Deano]

Thanks for the responses. I can't believe I missed the Documenter. I ran
it for all objects and got a report that ran to 2450 pages!!
Think I'll trim that down a bit.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.532 / Virus Database: 326 - Release Date: 27/10/2003

[TC]

Gak!

Perhaps write some Word VBA to cut it down somehow? (delete blank lines,
page breaks, whatever)

So you could probably still automate the comparison process.

TC
"Deano" <ma************@hotmail.com> wrote in message
news:uz******************@wards.force9.net...

Thanks for the responses. I can't believe I missed the Documenter. I ran
it for all objects and got a report that ran to 2450 pages!!
Think I'll trim that down a bit.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.532 / Virus Database: 326 - Release Date: 27/10/2003

[Deano]

TC wrote:

Gak!

Perhaps write some Word VBA to cut it down somehow? (delete blank
lines, page breaks, whatever)

So you could probably still automate the comparison process.

TC
Yeah I now, Containers and all that malarkey; I haven't got the will to do
it. I did select All objects and that wasn't strictly needed. I wish there
was some sort of checksum that 'proved' the file you started with is the
same you have after the decompilation process. Or maybe version control
software could help (SourceSafe??).


"Deano" <ma************@hotmail.com> wrote in message
news:uz******************@wards.force9.net...

Thanks for the responses. I can't believe I missed the Documenter.
I ran it for all objects and got a report that ran to 2450 pages!!
Think I'll trim that down a bit.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.532 / Virus Database: 326 - Release Date: 27/10/2003

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.532 / Virus Database: 326 - Release Date: 27/10/2003

[TC]

"Deano" <ma************@hotmail.com> wrote in message
news:_O******************@wards.force9.net...

TC wrote:

Gak!

Perhaps write some Word VBA to cut it down somehow? (delete blank
lines, page breaks, whatever)

So you could probably still automate the comparison process.

TC
Yeah I now, Containers and all that malarkey; I haven't got the will to do
it. I did select All objects and that wasn't strictly needed. I wish

there was some sort of checksum that 'proved' the file you started with is the
same you have after the decompilation process. Or maybe version control
software could help (SourceSafe??).

The checksum idea would be fine - as long as the two files did not have
"expected" differences; eg. a line: "This file was generated on 1/1/2003 at
13:48:02pm". If they *did* have such differences, just remove those lines
manually, or write some code to do that. For absolute certainty, you would
want to use a cryptographic checksum such as MD5. MD5 is actually available
via the windows Crypto API from (I believe) win95 osr2+, but you have to
write some code, & that might be more than you want to do, at this stage.
Maybe see if you can find an implementation of MD5 in VBA?

HTH,
TC

[Bri]

TC wrote:

"Deano" <ma************@hotmail.com> wrote in message
news:_O******************@wards.force9.net...

TC wrote:

Gak!

Perhaps write some Word VBA to cut it down somehow? (delete blank
lines, page breaks, whatever)

So you could probably still automate the comparison process.

TC

Yeah I now, Containers and all that malarkey; I haven't got the will to do
it. I did select All objects and that wasn't strictly needed. I wish

there

was some sort of checksum that 'proved' the file you started with is the
same you have after the decompilation process. Or maybe version control
software could help (SourceSafe??).

The checksum idea would be fine - as long as the two files did not have
"expected" differences; eg. a line: "This file was generated on 1/1/2003 at
13:48:02pm". If they *did* have such differences, just remove those lines
manually, or write some code to do that. For absolute certainty, you would
want to use a cryptographic checksum such as MD5. MD5 is actually available
via the windows Crypto API from (I believe) win95 osr2+, but you have to
write some code, & that might be more than you want to do, at this stage.
Maybe see if you can find an implementation of MD5 in VBA?

HTH,
TC

Why do things the hard way?

Once you have the preview of the report go to the menu and "File-Save as Table".
This creates a table with all the info. Export the table to a new db. Delete the
table. Do your decompile. Do above again. In the new db do a query to look for
changed records and extra records on either side.

Alternately, "File - Output to - Text" before and after. Then use the good old
DOS File Compare (FC) at the command prompt:

C:\> FC File1.txt File2.txt >Diff.txt

Diff.txt now contains the info on what lines changed. It lists the line above
and below the change as well so you can have some context. There's lots of
options. Type 'FC/?' at the command prompt for more info on FC.

Bri