none
Access # module limits RRS feed

  • Question

  • We have a 2003 adp with 36 forms, 47 standard and class modules, and 886 reports (all of which have code in at least 1 event) resulting in approximately 950 modules. 

    We periodically receive a “Save Operation Failed” message when either compiling or running compact and repair.  In an effort to resolved this issue we have rebuilt the adp by decompiling using the \decompile switch, and importing the objects into empty adp in chunks, compiling and compact/repair each time.  We cannot find any corruption.  It takes 7 minutes to compact and repair.

    Another problem is that when we close the adp it disappears from the desktop but remains in the task manager for some time, up to a couple of minutes.  If we try to re-open it while it is still resident, we get read only messages and it does not function properly.

    We know there is a 1,000 module limit, but are there issues even before that limit is reached, for example with 950 modules?  Are the two problems above related?  As we are continuing to develop new reports, is there an option that will accomodate this (exceeding the module # limit) or an upgrade path that would help stabilize the app?

    Internal suggestions have been to split the nearly 900 reports into different functional groups.

    Thursday, April 26, 2012 4:07 PM

All replies

  • Hi PK Tidewater

    PK Tidewater wrote:

    We have a 2003 adp with 36 forms, 47 standard and class modules, and 886
    reports (all of which have code in at least 1 event) resulting in
    approximately 950 modules.

    We periodically receive a “Save Operation Failed” message when either
    compiling or running compact and repair. In an effort to resolved this
    issue we have rebuilt the adp by decompiling using the \decompile switch,
    and importing the objects into empty adp in chunks, compiling and
    compact/repair each time. We cannot find any corruption. It takes 7
    minutes to compact and repair.

    If many of these reports have the same event code inside you should consider to move the event code out to a standard modul and convert it to a public function and just call this function by setting "=yourFunction()" in the reports event property. You then can set the hasModule to False and get rid of many modules. You also may try to use generic code for your event procedures. I understand that changing 886 reports is a lot of work. You can automate it in VBA by opening the report in the design mode and manipulate it by Code, including finally set the hasModule property to false.

    Another problem is that when we close the adp it disappears from the
    desktop but remains in the task manager for some time, up to a couple of
    minutes. If we try to re-open it while it is still resident, we get read
    only messages and it does not function properly.

    seems like the connection hangs. Did you try to close all opened connections manually before closing the ADP?

    We know there is a 1,000 module limit, but are there issues even before
    that limit is reached, for example with 950 modules? Are the two problems
    above related? As we are continuing to develop new reports, is there an
    option that will accomodate this (exceeding the module # limit) or an
    upgrade path that would help stabilize the app?

    It's possible that you don't count all modules. Maybe there are some corrupted modules inside, too. Try a /decompile.

    Henry

    Friday, April 27, 2012 4:49 AM