Works in Debug but not in runtime

[RichardH]

I've asked this question in different ways and haven't had a reply that fixes the problem yet. I'm getting desparate so I need to ask it again.

Why would something work in debug but not in runtime? Is there a problem within access where it doesn't keep up with changes made with vba?

 

[modest]

I have experienced this bug as well. The best way to get around it is to port over to a new database file and then run. Sometimes objects from within access become corrupt and are not able to fix. At least, this is the only thing I could find based on experience.

 

[RichardH]

Thanks for the reply. I wish it was that easy.
Problem is, sometimes it works, sometimes it doesn't, even with exactly the same criteria. I can run it and it brings back an error saying it's unable to find the query or table which is the recordsource, then run it again and it works fine. Run it again and it fails, it's driving me mental.
I've been testing with exactly the same data, doing exactly the same thing and it works around 30% of the time in runtime, but 100% in debug.

 

[DaveJHPT]

Have you tried decompiling?

Dave

 

[modest]

Please post your code. It sounds like you may just have a timing error.

 

[izyrider]

with stuff like that it's worth trying a /decompile as Dave suggests.

visit here
read ALL of it very carefully (especially the first three links). maybe also google around for other opinions on /decompile since everyone has their own favorite tricks with /decompile.

decompile a COPY of your db.

please, only run /decompile on a copy - it can kill some db permanently irretrievably stone dead.

izy

 

[modest]

Izy and Dave, that is very interesting. It decompiles the whole db file, not just the vba. I haven't ran into any problems that require this, but nevertheless I think this is a good procedure to follow. I think I will set up automatic decompiles every two weeks.

 

[The_Doc_Man]

Although it isn't the only time I've ever seen this problem, the LAST time I had it, I had an ActiveX control that needed to be re-registered. It was therefore a References problem to something that was NOT a normal .DLL file. So see if something like that applies. (Just a stab in the dark so if that ain't it, I won't really be surprised.)

Come to think of it, another time it was an ActiveX control for which I was manipulating the properties of a collection within the control.

So if that applies, give it a second look. If not, ... I tried.

 

[RichardH]

Thanks for all the replies, I appreciate it.
I tries the decompile that you recommended and it shrunk the db drastically. Very impressive.
Unfortunately the form stil doesn't work properly ) Never mind, I'll think of another way around it.

 

[izyrider]

baaaaaH

if /decompile didn't fix it then probably (sorry 'pologies in advance!) it's your problem (the canonical source (you followed the URLs, right??)) rather than A's problem (the compilation of your source).

check: references; ocx registration; something daft in the code (trust me! it happens to all of us), or something similar that is so blindingly stupid that you will never admit it in public on this site.

try copying your "system-event" code (all of the _click(), _AfterUpdate(), etc) to Notepad, then delete the "system event" A'code (in facie eccesiae /decompile after this delete).
then recreate the the "system-event" subs using the A-combos (i.e. DO NOT "manually" name the "system event" subs) and copy/paste the internals of the subs.

don't let redmond grind you down: A can be made to work, (it's just that you have to work even harder )

izy