Just how do those EAP files grow anyways?

[paddler]

 Hi

 As I have documented here in the past ( pls don't ask) I am working on a version of EA on a laptop while the client struggles with IT to get EA installed on the corporate network.

 Ok, so I am in the situation where I am responsible for backups. I used to perform XMI exports ( hey, don't knock it) and this worked until I found an issue with the import... I moved to exiting EA and copy/pasting the EAP file to CD.

 What I'm noting is that the file itself does not seem to grow on a weekly basis. Does the back end of the EAP file ( I understand it is based on Access) grow in segments? Does it "extend" itself only when the current set of tables is full?

 I'm getting concerned that the darn EAP file isn't growing....

 Ciao  

[Eve]

I'm afraid I don't understand the internal mechanics of access files.  But as far as I know, they leave deleted rows in, marked as inactive in some way.

So, your eap files would grow fastest if you were doing things like repeated XMI imports etc.

[Paolo F Cantoni]

Hi Paddler,

with ANY MS Access db, you should compact and repair as often as is feasible (for example - just after backup).

With later versions it's not quite as important as with earlier versions, but it's good practice.

This will recover any unused internal space and also check/repair any internal inconsistencies (very rare).  It also improves performance because the records are consolidated.

Don't worry too much about lack of growth.  There's usually a spurt at the beginning, but after a while things settle down and the model tends to stabilise.

HTH,
Paolo

[Geert Bellekens]

I thinkt he lack of growth is inherent to how a database in general works.
If I understood correctly a database usually already allocates a certain amount of room for new data, so it doesn't have to fiddle with the actual file size every time a row gets inserted.
I can also image that the space for the deteleted rows gets recycled for new insertions.

In general there is not a 1:1 relation between the database size and the amount of data in it.

Geert

[paddler]

Cool

Thanks guys.

 I am not used to using Access and didn't know if it behaved like other database engines wherein "chunks" of space is allocated and your file size does not appear to grow.

 Paolo, not being an Access guru, are you suggesting using EA tools to do the repair or MS Access tools?

 I am hesitant to use anything outside of Sparx as these steps may not (??) be supported by Sparx and may bugger the database

 Suggestions welcome.

 We just got a foot of snow this week!
 

[paddler]

Never mind!

 I found the tools

Thanks
paul

[RoyC]

Which - the database management tools or the snow shovel and gravel pan?

[Paolo F Cantoni]

Never mind!

 I found the tools

Thanks
paul

For the assistance of others, the EAP management tools are under (surprisingly - because under EAUI stuff usually isn't where you expect it...): Tools|Manage .EAP file>

HTH,
Paolo

[skiwi]

You can also (and more easily) use, if you have it, MS access to repair and compact .eap files.

[ruffp]

Hi,

Yes this constantly growing files are a "feature" of MS-Access.

I remember the time when I made a small exe command line application wich takes a mdb as parameter and compress it.

It was useful as we were able to schedule the compression without human interaction.

I don't know if with the latest access, they provides such tool from the command line.

Tell me if you're interested by such tool or if you know ho to do it automatically.

Cheers
Patrick

[son-of-sargasso]

AFAIRecall, there was always a way to compact (N.B. not "compress") an Access file from the command line.  

Since I don't have a M$ environment anymore, I can't really give you any more than that, but maybe someone at the www.databaseadvisors.com mailing lists might be able to help.

btw, the "original" access model (which was actually called "OpenAccess" by the way), implemented the database as a "filesystem within a file" which may explain the way in which it seemed to surge between circa 1.5MB to around 4 or 8MB or whatever it does these days(?)). A binary examination of the mdb file back then would reveal "vast" expanses of |0H0H| which would gradually fill as deletions, and in some case mods, didn't actually overwrite the previously used xHxH areas, but simple grab some of the 0H0H area.  Hence the "ancient need" to compact regularly.  Because if you didn't, it would simply "grow the mdb" by the next tract size to provide more empty space.  In those days, a compact would achieve "huge and miraculous" mdb file size reductions (as long as your database wasn't just growing via added data).  
N.B.  I have no idea about how M$Access (aka) the .eap rdms implementation works now (>Office 2003)!!!

hth
bruce

[ruffp]

AFAIRecall, there was always a way to compact (N.B. not "compress") an Access file from the command line.  

Yes you're right, the option /compact does the job. I think I made this solution because we did not want to install office on the server but it s so far away

I think the EAP can be a good solution for single user project and for demonstration purpose, but we will more recommend to use a DBMS for bigger projects with multi-users.

Cheers,
Patrick

[beginner]

Just a not directly related question to the Access-ories: I exported our model from SQL Server which turned out to be an over 50 Meg EAP file. Now (all of a sudden?) I observe occasional busy loop times in EA of several seconds time. It looks like the access to Access seems to be at its limits. Could that be? (N.B. I have done all shrinking and consistency checks already.)

b.

[Paolo F Cantoni]

Shouldn't be.  Is it random or consistently in one area?

Paolo

[beginner]

I'd say randomly. When I work with the EAP export it's roughly once per minute where CPU for EA goes  up to 100% for about 10 seconds (and even more strange the last time this only started after working half an hour or so without any delay?!). It's just on this big one and it occurred "all of a sudden" - means I worked with similar exports before without problems. It's really strange and the only explanation I could think of was that some query in Access takes extraordinary long under odd circumstances. So I thought I ask here. Maybe someone has an idea...

b.