Database has reached maximum size

[matxxx]

Hi all,

we are running Enterprise Architect 8.0.856 (yes I know, old) and have a very huge middleware project modelled with EA.
It has been working for several years now but it seems like the project starts to be too bug.

Since a couplye of days I have been running into troubles while creating an .EAP file.

My steps are:
* Create a New Projekt
* Project Browser -> Package Control -> Import a Model Branch -> Fina a Model Branch (.EAP) file
* Here I just select an EAP file that contains the information for the entry package.
* I am asekd to type in the SVN working copy path
* Then the import process from SVN starts.

After a longer while I receive an error:

"DAO.Field [3036] Database has reached maximum size."

The EAP file for the project I created is then pretty much exactely 1.048.000 KB which is the 1 GB maximum size for projects.

The same process worked fine just one week ago and since then I have not been changing so much.

My idea was to remove packages:
* First I removed packages using an old compacted EAP file -> Still the same problem while creating a new EAP file.
* Then I removed old packages and the references in the XML file structure manually. I assume that Enterprise Architect generally only removes the references to a package XML file and never the real file. -> Still the same problem while creating the EAP file.

The problem is, that I currently don't know why my model does not become smaller. I have been deleting many packages till now that are all for sure bigger than my changes of last week.

I know that Enterprise Architect does not expect models with that size, but we are handling a huge data model with many diagrams in an environment that is highly audited.

I am happy for any advice or idea you can give me, as I have no further ideas at the moment how to solve that.

Thanks a lot!
matxxx

[smendonc]

Version 8? time to upgrade.  Having said that.

I don't remember the menu structure for v8 anymore, but you should have an option that allows you to do database i.e. 'eap' maintenance.  One of the sub options is to 'Compact' the database.  The 'eap' file is just an Access database (very old version) which doesn't automatically return space to the free pool until the 'compact' has been run.

You should do this after you have a backup of the original.  With large models it's also safer to use a real database backend.

As I don't use version control I wasn't sure if you started a new eap file and then tried to import from SVN.  The above won't apply in that case as it assumes you have an eap file that has seen many changes over a period of time.

Stan.

[Geert Bellekens]

Also check if you can purge the auditing logs.
A client of mine reduced the size of their .eap file from 240 MB to 35 MB by just clearing th auditing logs.
Worth noting they only had the auditing option on for about 3 months

Geert

[matxxx]

Hi!

Yes version 8. Unfortunately it is not always easy to get the necessary budget for an upgrade. Unfortunately this has not been my decision  

To clarify my setup as I might not have been clear enough:

• I have a huge structure of XML files in SVN.
• I have a EAB file (model branch file) with about 1 KB of size that only contains some information in a <BranchVCSpec> tag pointing at the root xml file.
• I load the whole project in an EAP file.
• Enterprise Architect loads the whole information from SVN and creates the database in the EAP file, which throws the error because of exceeding 1 GB of file size.

So this means I can't compact the file size of the EAP file, because I already can't create it.

Before this issue, I also compacted the file size every time I did that and my compacted file size was about 45 MB. But I am only able to do that after I created the original EAP file from the SVN repository.

@Geert: Thanks for your idea, but the auditing logs have never been activated.

Does anybody have another idea?   :-/

Thanks

[qwerty]

I would recommend to use some real SQL server rather than that Mickeysoft toy M$Access.

q.

[Geert Bellekens]

I don't understand why you would need to recreate the .eap file each time.
I've done .eap files with SVN in the past too, but I always just kept my .eap file and never needed to create a new one.

Geert

[matxxx]

I don't understand why you would need to recreate the .eap file each time.

In the past years, we experienced that the EAP files are affected by an "aging process".
We had several people working in parallel on the same project. Each person with his own local EAP file, but in the background the same XML structure.
From time to time the EAP file became too old: Several people changed several packages over a period of time and the user was not able to do a "Get All Latest" with that file.
The solution was: Creating a new EAP file with the newest version of the XML structure. That solved the problem till the file became "old" again.

We are aware that this might be a problem of the old Enterprise Architect version we are running, but still we need to fix that. We have a very quick release cycle with parallel projects that all affect the data model. We can't really wait for an "EA upgrade project" at the moment.

[Geert Bellekens]

I wouldn't know a solution that requires less time then upgrading and/or using a DBMS.

Geert

[Uffe]

Are you using JET 3.5 (the default)? If so, it might be worth trying to switch to 4.0 -- although I'm not sure if JET 4.0 support was included in EA 8.

From http://support.microsoft.com/kb/275561: "To accommodate the change to Unicode data and enable all existing data to be successfully converted, the internal unit of storage (the page size) was increased from 2 kilobytes (KB) (2,2048 bytes) to 4 KB (4,096 bytes). This enabled an increase in the maximum database size for Microsoft Jet databases, allowing them to go from a maximum of 1.07 gigabytes (GB) in earlier versions of Microsoft Jet, to 2.14 GB for Microsoft Jet 4.0."

A page on upgrade issues can be found here: http://allenbrowne.com/ser-48.html.

Please note that I've no idea how well this might work for you. It's possible that the 1GB max size is in EA itself: http://www.sparxsystems.com/support/faq/database.html. But given that the error message seems to be coming from the database rather than EA it should be worth a try.

In terms of content, you should also check the t_document table, especially where DocType='Baseline'. These can stack up, are not indicated in the GUI, and as a general rule are not referenced from other tables so you should be able to delete them behind the scenes without causing database corruption.

HTH,


/Uffe

[matxxx]

I solved it.

I reverted revision by revision backwards till I was able to create the EAP file again.

The commit that broke the model was a very small. Just a dependency from a quite big package to another one. I think the package xml was corrupt afterwards as all the Class elements in the XML files disappeared.

Before the xml file had about 230.000 lines, afterwards 550 only. I guess we should refactor that package and remove  old references.

Anyway, I guess that corrupt package might have caused a problem while creating the EAP file.

Now the EAP file has a file size of 650MB before compacting it.

I will do some cleanup jobs now and might also split the above mentioned package. Hopefully this will solve the issue till we finally can upgrade to a newer EA version.

Thanks guys for your ideas!

[jakson]

Also check if you can purge the auditing logs.
A client of mine reduced the size of their .eap file from 240 MB to 35 MB by just clearing th auditing logs.

Our EA database is now ~90 MB. Before "Integrity check" it was ~200 MB.
Of course I was shocked

[skiwi]

Unfortunately it is not always easy to get the necessary budget for an upgrade.

An approach to take in this situation is to point out that your company is using an unsupported product, thereby putting at risk your company's investment in its models.
Plus as a bonus for upgrading you get improved usability, features, and functions.

write the paper recommending an upgrade, its scarcely a budget buster

[Uffe]

Very good point, skiwi!  [smiley=thumbup.gif]