GRID MODEL - data object management

[GoogleCodeExporter]

What steps will reproduce the problem?
1.  Running the GRID model interface through MANY scenarios (literally
thousands of them)
2.  Interface mdb file accumulates temporary table size that is not
released by each iteration.
3.  This eventually pushes the interface mdb file to upper limit of mdb
size (2+ Gig).

What is the expected output? What do you see instead?
Ability to run multiple scenarios without file size accretion.

What version of the product are you using? On what operating system?
Latest version of the interface.  Win XP/SP2.  Access 2001 (just before
2003 installation by BTS on 12/3/2009).

Please provide any additional information below.
Once mdb gets to this size, repair/compact was impossible on my
workstation.  Had to move the file to another machine, which allowed repair
to complete successfully.  After this operation, size of mdb was 2.4 meg.  

After 4 hours of running after this fix was performed, mdb had grown to 225
meg, with NO RESULTS being written to this mdb (all output to csv files
elsewhere).  This behavior is problematic to long, multi-iteration runs of
the GRID model using the current interface design.  The implementation of
the Access Helper in .NET seems to be the primary cause of this, although
further investigation is likely warranted.

Original issue reported on code.google.com by MarkL....@gmail.com on 4 Dec 2009 at 5:45

[GoogleCodeExporter]

Original comment by MarkL....@gmail.com on 4 Dec 2009 at 5:55

• Added labels: Component-Persistence, Performance

[GoogleCodeExporter]

Added label for GRID

Original comment by ArnelMan...@gmail.com on 4 Dec 2009 at 6:02

• Added labels: GRID