Limit to the number of primary sessions in Robust design?

[brunner]

I am using the Robust design (closed captures) in MARK to analyze a fairly large mouse dataset (~11 years). For most of our trapping grids things have gone fairly smoothly, but for a couple of trapping grids there were more than 100 primary sessions (each consisting of two days of trapping), and here I am having troubles with MARK crashing when it tries to make the database (right after I enter in the time intervals and hit OK).
The error (below) is the same each time for at least two datasets, both of which worked before I added a few extra session (and yes, I checked for anything strange with the files). I have reinstalled MARK and tried it on a different computer with a new installation. They are fast computers (Xeon 3.2GHz, 2GB RAM, WinXP Pro). All of this makes me think that perhaps the crashing is not simple bad luck and instead it might be something I am doing wrong or perhaps a limit to what MARK can handle.
I would appreciate any suggestions to make this work!

Thanks!

Jesse


The error reads like this:

Error Code: 2 [BOUND ERROR ]
Subsystem: Base
Function: ArrayGet
Argument: 0
CallStack:
MYTOPAPPWIN:CREATEPIM (Line: 201)
MYTOPAPPWIN:CREATEPIMS (Line:327)
MYTOPAPPWIN:FILENEW (Line: 257)
MYTOPAPPWIN:NEWFILE (Line: 3)
APP:START (Line:688)

and then I get buttons for Ignore and Abort. If I hit Ignore I get:
Error Code: 50 [ACCESS VIOLATION]
Subsytem: VO-CODE
Error Subcode: 5333
Arguement Number: 2
Description: Apllication Code Error causing Access Violation
and then the same CallStack text. Then, no matter what I hit I get closed out of MARK. It does seem to create the .FPT , .DBF, and .CDX files, but if I open the .DBF file it crashes MARK.

[brunner]

Just in case anyone else has this problem, here's what happened:
Gary White was kind enough to look into it for me. He told me, "Nobody has ever run >99 primary occasions, and I had a formatting problem with reading 100 as a zero because only the last 2 characters were read," and sent a new executable that fixed the problem. Thanks Gary!