Corruption that Decompile doesn't fix? 1

[lameid]

I am starting to see this more and more.

Any thoughts on what can cause undesired behavior that a decompile does not fix? Obviously the only thing to do is go to a backup or somehow regenerate a file.

The last one I saw was really bizarre. There is quite a bit of code called on the form at various events but it works all the time for other forms. What this form did instead of displaying the record source with criteria, it opened the related target table, scanned through all the records on screen until it hit the one in the where clause and then stopped on the records in the where clause. The oddity is the rowsource is set on the form's Load event.

I know this is one of the black hole type subjects but all I have at the moment is Virus or just so old (many changes) the thing is prone to corruption neither of which I have good thoughts on confirming or solving.

 

[MajP]

just so old (many changes) the thing is prone to corruption

I would create a new database. Then import your objects in starting with your tables. A lot of times this helps. Always do that going from design to production.

 

[lameid]

Interesting... In this one case, someone likely changed the form several times after an import as it was not quite what was needed.

It's an interesting system. Because Access is good at Rapid Application Development, it is used in this case to make data collection systems that often have repeated types of information (forms) from database to database. So the objects are all exported (transferdatabase) to target files as part of the construction process. I will get around to testing this though for this case.

Any thoughts on weird that tends to happen after objects are transferred? The building database has more forms in it for selecting forms and the like; all the prebuilt (known) forms as possibilities; and is around 75 MB give or take. A resultant frontend is usually in the 10 - 20 MB range. Obviously it is too big and proprietary to go into specifics.

 

[lameid]

I just confirmed once corrupt always corrupt on this object, an import does not fix it.

I may take the time to import the big builder file sometime to a fresh file to ensure it is as clean as possible. Even so it would not fix anything that was inherently corrupt.

What I probably need is a tool to log all the objects properties and code in one file, dump them and regenerate everything with code in a new file. And of course there should be intermediate magic to make sure everything is clean. It's the regenerate part I can't even get my head around for an estimate as somethings have to be done with specific code like createcontrol, createreportcontrol.

 

[MajP]

Are you referring to SaveAsText LoadFromText options? If so see discussion.

http://allenbrowne.com/ser-47.html

 

[lameid]

SaveAsText / LoadFromText had completely eluded me until now. Many thanks, that's a much simpler procedure to get clean objects.

 

[MajP]

These are undocumented, unsupported capabilities so I do not even know if they still work in newer versions. I have tested in the past and was successful.

 

[Darrylles]

Bit late, but if it helps...

A decompile / re-compile is another option that generally seems to be over-looked.

http://www.fmsinc.com/microsoftaccess/performance/decompile.asp

ATB,

Darrylle

Never argue with an idiot, he'll bring you down to his level - then beat you with experience.

 

[strongm]

>A decompile / re-compile is another option

Although the subject of this thread would suggest that in this case it was not overlooked, it just didn't help.

 

[Darrylles]

Lol - touche.

I must be 'topic title blind' - sorry.

In actuality, I read through these posts and got distracted because I immediately thought of a generic tool that I have created that allows me to check for key-word terms (function calls etc) throughout all VBA module code within Access applications, and then attempted to find it on my pc / server - had a server problem which developed into a major problem.
(This functionality may not immediately register as useful to you, however, it did to me, because if this issue was related to specific function calls - this would enable you to easily locate all calls to the function).

Apologies again for stupid post. ;-)

After saying that, this does not sound to me like typical 'meta-code' corruption - it sounds like incorrect code implementation (whether that be a VBA 'bug' or developer error).
It may 'seem' that once the error occurs - it continues to fail - indicating meta-code corruption, but are you 100% sure that some data is not stored incorrectly, somewhere, that ensures that it will always fail when run again?

(I use 'meta-code' to refer to internally stored / 'compiled' code - maybe there is a better term)

My two cents worth - and never say 'never'!

Darrylle

Never argue with an idiot, he'll bring you down to his level - then beat you with experience.

 

[lameid]

I am a little suspicious of how big the global stack must be for this particular behemoth. I think that may explain part of its tendency to corrupt. Appropriate scope is not something well understood by all and something I fix when I can.

 

[lameid]

I finally tried exporting all objects to text and loading them into a new file... plus an import of tables since SaveAsText does not work with tables.

The curious thing is the file is about 40% bigger even after a decompile and compact. The only thing that is unusual is that the database is old and has gone through several versions of Access and that might have something to do with it.

In my experience even if record locking is on a compact drops the file size back down, so I am at a loss as to what is different here.