What happens after DAO:Databas [2004] Out of memor

[Josef Stadelmann]

I have just done a model integrity check and it took a while unless it was done.

Then I have found in my model a package belonging to a reverse engineerd binary, belonging to a framwork assembly SYSTEM.

It was empty before, now after the integrity check, it shows me the 3 hard boys again; hard boys because the drive me crazy ona atempt to delete them in the project browser.

<<struc>> Int32, Object and String classes.

I deleted them again. Afther the error message box "DAO.Database [2004] Out of memory! has shown up at least about a few hundred time, wasting my time, sorry, one can only press the stupid OK button, no other chance like <OK> is offered, like do the same for all. After enought waiting and praying I have arranged that the package folder SYSTEM was empty; to be precise, is shown empty in the project viewer.

So I was thinking that it is a sniff to delete the package folder SYSTEM as well.

Unfortunately this is not a sniff but an anoying return of the same stupid error message box DAO.Database [2004] Out of memory.

Now that happens while my memory is used to 1.65 GB from4 GB on a Vista machine with SP2 installed.

Any hints how to configure EA to really make use of available memory on a Vista machin?

And it happens after the integrity of the model database was done by allowing to repair/ recover from errors. And it wa said that no errors are found.

I wonder if anyone of you has loaded a few Microsoft Framework Assemblies into a model by revese engineering from binary and then tried to delete this framework .NET model.

I am curios what the outcome of such experiments from other users is.

Josef Stadelmann

just bougth an EA System Engineering License today to have all included, but can't remember that checked such a bougous option like DAO.Database out of memory !  

[qwerty]

Try looking into Sparx program folder. A file named DBerror.txt. You might send this to Sparx. (No idea whether that exists only from V9 on...)

q.

[Eve]

In version 9 that will be in %appdata%\Sparx Systems\EA.

[Josef Stadelmann]

Thank you; the file exists in fact; unfortunately only for the last error seen. Would be nice if all the hundreds of errors I had to quit with <stuipd-OK-btn> would have made it to the log.

Any other logs out there?

Josef

10.05.2011 17:38:12
DAO.Database [2004]

Out of memory.

Context:
      delete from t_connector where Connector_ID in (94318,94240,94241,94242,94262,94263,94264,94265,94277,94278,94279,94280,94281,94288,94289,94290,94291,94297,94319,94320,94322,94325,94328,94331,94332,94334,94336,94282,94283,94284,94285,94286,94292,94293,94294,94295,94296,94338,94340,94350,94353,94363,94364,94365,94366,94367,94371,94376,94343,94345,94347,94356,94358,94360,94381,94384,94391,94392,94395,94399,94400,94401,94406,94408,94415,94419,94386,94388,94389,94410,94413,94414,94427,94430,94432,94441,94442,94443,94444,94445,94446,94447,94448,94449,94456,94460,94462,94463,94465,94467,94468,94471,94453,94454,94455,94475,94482,94483,94498,94499,94500,94501,94502,94543,94506,94546,94547,94548,94576,94579,94594,94595,94596,94597,94623,94625,94626,94627,94628,94509,94510,94514,94517,94518,94519,94520,94553,94560,94561,94562,94563,94564,94565,94566,94567,94568,94569,94570,94571,94581,94584,94600,94603,94613,94614,94615,94616,94620,94629,94630,94631,94632,94633,94649,94651,94683,94685,94686,94687,94688,94689,94690,94691,94692,94693,94635,94638,94642,94643,94652,94654,94655,94657,94659,94660,94662,94663,94668,94679,94694,94695,94696,94697,94698,94699,94700,94701,94702,94703,94704,94705,94706,94707,94708,94709,94710,94711,94712,94713,94714,94715,94716,94717,94718,94719,94720,94721,94722,94723,94724,94725,94726,94727,94728,94729,94730,94731,94732,94733,94734,94735,94736,94737,94738,94739,94740,94741,94742,94743,94744,94745,94746,94747,94748,94749,94750,94751,94752,94753,94754,94755,94756,94757,94758,94759,94760,94761,94762,94763,94764,94765,94766,94767,94768,94769,94770,94771,94772,94773,94774,94775,94776,94777,94778,94779,94780,94781,94782,94783,94784,94785,94786,94787,94788,94789,94790,94791,94792,94793,94794,94795,94796,94797,94798,94799,94800,94801,94802,94803,94804,94805,94806,94807,94808,94809,94810,94811,94812,94813,94814,94815,94816,94817,94818,94819,94820,94821,94822,94823,94824,94825,94826,94827,94828,94829,94830,94831,94837,94838,94839,94840,94841,94842,94843,94844,94845,94846,94847,94848,94832,94833,94834,94835,94836,94897,94898,94899,94900,94901,94902,94903,94904,94905,94906,94907,94908,94909,94910,94911,94912)

[qwerty]

No. I'd recommend to send this as bug report to Sparx. I also had this Out of memory message in various circumstances but unfortunately learned about the DBerror.txt only the last few days.

And yes: the file should contain ALL messages. Pls. note that in your bug report.

q.

P.S. Silly to say that, but instead of working with this buggy MS Access EAP files it is also possible to use a local data base server (e.g. MySQL). This will avoid the Out of memory message but definitely it's a bit more clumsy to handle than out-of-the-box EAP files.

P.P.S. It does not really help to switch to Jet 4 (from the options). The error message is only different...

[Geert Bellekens]

In your case the problem is that the element you are trying to delete has too many relations.
What I would do is delete the connectors directly in the database.
A query like

Code: [Select]

Delete from  t_connector
where start_Object_id = <object_id>
or End_Object_id = <object_id>should do the trick.

Geert

PS. replace <object_id> with the object id of the element you are trying to delete.

[qwerty]

Geert,
the query is not one issued via automation but directly from EA's gutts. I have similar lengthy queries also failing. So your answer should be: "Sparx: split the queries into managable chunks"-

q.

[Josef Stadelmann]

And do not forget, I have only reverse engineered those Microsoft Assemblies belonging to .NET and in particular to WCF 3.5.

I have reverse engineerd about 7 DLL's.

But I must admit they each have a certain complexity.

And I think it is this complexity which is perfectly resolved during reverse engineering phases but later fails if one likes to delete i.e. all or a part belonging to a certain assembly i.e. wcf 3.5.

what you offer migth work for a EA engineer and GURU but not for me. Also where can I read more about internals or the Database itself?

I am by far not a DB Guru, hence I will avoid doing anything by hand, as long as I can. The chance that I loos all my models is much bigger, and I like to avoid this.

So, please Sparx, split and handle the chunks properly or make real use of all my available memory, I have 4 GB on my Vista LENOVO but at the time the failure happens the first time, and even thereafter, after <stupid_OK> is pressed, the task manager shows me 1.85 to 1.9 GB used and is  not growing.

But thank you very much for the hint, which I would try out if I would be a DB guru, but I am far away from that and in particular don't have know-how about the EA DB.

Also I do not use a repository, like Orackle 10g or vice versa. Hence which "DAO" tool is appropriate to do what you offer me to do?

Josef

[qwerty]

Josef,
you need to report this officially via the bug report page (see this side below): http://www.sparxsystems.com/registered/reg_bug_report.html

q.

P.S. EAP = MS Access Database. So the DAO (Dümmstes Anzunehmendes Operationssystem) messages are from Windoze's guts. You can only avoid them by asking Sparx to circumvent them or by yourself switching to some SQL server.

[Geert Bellekens]

Josef,

There are many ways to access EA's database directly.
You can use MS-Access and open the eap file with it, or you can use a generic sql editor/executor (e.g. http://www.sqlmaestro.com/products/anysql/)
You can even execute sql queries using in scripts using the API.

This is of course a workaround to get past the current issue, a bug report is in order to get it fixed properly.

Geert

[qwerty]

Geert,
the above SQL was generated and logged during some internal operation of EA (during an import). It should NEVER be executed stand-alone! It is just a single out of many failing queries where the context is not known. So Josef: please just report the message.

As a possible work around: set up a local MySQL (or whatever) repository and perform the import with that. When you're done you can do a project transfer to an EAP file.

q.

[Geert Bellekens]

Qwerty,

I know that the delete statement with the very long list of id's is generated by EA.
The reason it is trying to execute this is to delete all connectors connected to the element Josef is trying to delete.
So if you delete all connectors manually (using the query I suggested) EA won't try to delete all those connectors with that ridiculous sql statement, and therefore the delete action should work without a problem.

Your workaround surely is (a lot) safer, but requires more work.

Geert