Crash while running code (XP Sp2, Jet4 Sp8)

Topic

New Reply

I’ve run into a strange problem in a database I’m trying to update that is using 2002 format. Because of some issues with code and form constructs, we need to sweep the database and reset the data source for each form and report. A module to do that exists, and normally works just fine. However for this database, it gets about halfway through the 400 objects or so and produces a most unusual error message which I’ve attached. In addition, at that point the database has blown up from ~16MB to ~115MB. Has anybody else seen anything like this????

Reply | Quote

Replies

I’ve certainly never seen anything quite like that, Wendell. However, since the code runs in other databases, I have to suspect a corrupted object in this database that is causing the blowup.

Reply | Quote

My suspicion is that it is the size of the VBA portion of the project that causes it – wish I could do a complete redesign, but the client and the primary developer don’t think it’s viabable. I don’t think it’s maintainable.

Reply | Quote

I’ve not seen such a thing before in Access.

What is ‘interesting’ is that the message comes from the C++ runtime library rather than from VBA or Access itself. If i had to go looking for the cause of the problem, i’d look at the calls from VBA to those libraries.

Reply | Quote

I’ve not seen such a thing before in Access.

What is ‘interesting’ is that the message comes from the C++ runtime library rather than from VBA or Access itself. If i had to go looking for the cause of the problem, i’d look at the calls from VBA to those libraries.

Reply | Quote

My suspicion is that it is the size of the VBA portion of the project that causes it – wish I could do a complete redesign, but the client and the primary developer don’t think it’s viabable. I don’t think it’s maintainable.

Reply | Quote

What a problem! The whole thing revolves around a database that works on my desktop (and did on my laptop) but blows up on client computers. Same version of Access and patches, Win2000 on theirs, WinXP and Win98SE on mine. The symptom that spells trouble is when you compile the database and then can’t save the VBA project. We’ve actually saved the entire database to text, and then rebuilt it from scratch, and it fails to link subforms when you do that – it compiles and you can save the project however. Really bizzare, and I can’t find any definitive limits on what the maximums for VBA are. It has over 50K lines of code so it is complex. But it has been working until we tried to make some changes – the old version is still working BTW.

Reply | Quote

Is there 2003 in the mix anywhere? That sounds something like the problems that popped up in 2000 after Office 2002 “updated” the vbe6.dll.

Reply | Quote

Not that I’m aware of – but I haven’t checked the versions of that dll – I’ll take a peek.

Reply | Quote

Not that I’m aware of – but I haven’t checked the versions of that dll – I’ll take a peek.

Reply | Quote

Is there 2003 in the mix anywhere? That sounds something like the problems that popped up in 2000 after Office 2002 “updated” the vbe6.dll.

Reply | Quote

As Charlotte says, sounds like a dll problem, … but how is it that a message comes from the C++ runtime?

I’m trying to understand how that even enters the picture.

Reply | Quote

Actually, I guess it doesn’t. The C++ error comes from a process used to rebuild a database from text, much as you would if you used Visual Source Safe. The error occurs in sweeping through all the form and report objects to reset their RecordSource property, since the original developer use Me. to refer to controls where the object name is the same as the DataSource, and Access finds it to be ambiguous and won’t compile. (I always use Me! and type in lower case, though I try to give controls distinct names.) Why reseting the RecordSource fixes the issue I’m not quite sure, but I think that process is causing the error, and it seems to happen on PCs where there is not gobs (e.g 1GB) of RAM. The Project Save problem initiated the use of that process. Hope that clears things a bit.

Reply | Quote

well, I found nothing in the MSDN with the wording in the error dialogbox, either.

Reply | Quote

well, I found nothing in the MSDN with the wording in the error dialogbox, either.

Reply | Quote

Actually, I guess it doesn’t. The C++ error comes from a process used to rebuild a database from text, much as you would if you used Visual Source Safe. The error occurs in sweeping through all the form and report objects to reset their RecordSource property, since the original developer use Me. to refer to controls where the object name is the same as the DataSource, and Access finds it to be ambiguous and won’t compile. (I always use Me! and type in lower case, though I try to give controls distinct names.) Why reseting the RecordSource fixes the issue I’m not quite sure, but I think that process is causing the error, and it seems to happen on PCs where there is not gobs (e.g 1GB) of RAM. The Project Save problem initiated the use of that process. Hope that clears things a bit.

Reply | Quote

As Charlotte says, sounds like a dll problem, … but how is it that a message comes from the C++ runtime?

I’m trying to understand how that even enters the picture.

Reply | Quote

What a problem! The whole thing revolves around a database that works on my desktop (and did on my laptop) but blows up on client computers. Same version of Access and patches, Win2000 on theirs, WinXP and Win98SE on mine. The symptom that spells trouble is when you compile the database and then can’t save the VBA project. We’ve actually saved the entire database to text, and then rebuilt it from scratch, and it fails to link subforms when you do that – it compiles and you can save the project however. Really bizzare, and I can’t find any definitive limits on what the maximums for VBA are. It has over 50K lines of code so it is complex. But it has been working until we tried to make some changes – the old version is still working BTW.

Reply | Quote

I’ve certainly never seen anything quite like that, Wendell. However, since the code runs in other databases, I have to suspect a corrupted object in this database that is causing the blowup.

Reply | Quote