Urgent! XMI Export Log file - where is it?

[Paolo F Cantoni]

We have a package we are trying to export and the export process is "blowing away"  EA.  We have specified that the export should be logged to a file, but when EA "carks it", there is no XMI output (even partial) and NO log file that we can find.  Where should we be looking for the log file, in the (vain) hope that it may contain information on the cause of the failure?  How will it be named?

TIA,
Paolo

[qwerty]

I asked that myself several times. Sparxian dialogues ...

q.

[Sunshine]

Not sure but have you looked in the folder.
C:\Users\<username>\AppData\Roaming\Sparx Systems\EA
I've found various files there like DBError.txt

[qwerty]

I think this flag is an "alternate fact". Definitely the log is written to a Sparxian server.

q.

[Paolo F Cantoni]

I think this flag is an "alternative fact". Definitely the log is written to a Sparxian server.

q.

This may be the case...  You set the flag in the "Package Control" dialog, but there's no indication in the "Save to File" dialog that logging is taking place.

It would opportune for a Sparxian to tell us what's actually going on.  At the moment, my export and the EA instance "evaporates" some time into the export.

Paolo

[Paolo F Cantoni]

Not sure but have you looked in the folder.
C:\Users\<username>\AppData\Roaming\Sparx Systems\EA
I've found various files there like DBError.txt

Hi Sunshine,

Yes, I checked the "usual suspects".

Paolo

[qwerty]

Sparxian aint got the hang of debugging. Swallowing MDG bugs is another of their favorites :-/

q.

[Eve]

I think this flag is an "alternate fact". Definitely the log is written to a Sparxian server.

q.

I can promise that this isn't the case. No Sparx Systems product ever connects, accepts connections, or writes to anywhere you don't request it to.

At one point the OpenID landing page pulled our logo from sparxsystems.com. Even that was removed.

Besides, our license agreement intentionally doesn't allow us to collect that kind of information outside of support services.

[Eve]

Where should we be looking for the log file

The log file will be created in the same directory as the target XMI. package.xmi will produce a log file package_export.log.

[qwerty]

I was just kidding - my way. But no, there is no log. Honestly.

q.

[Paolo F Cantoni]

Where should we be looking for the log file

The log file will be created in the same directory as the target XMI. package.xmi will produce a log file package_export.log.

As I said, NO log file... As I have argued many times in the past the purpose of the log file is to precisely leave a log in case of the death of the process.  It's why Scott of the Antarctic wrote in his journal, why captain Kirk creates his "captain's Log".

The log should be written to (as close as possible to the activity being logged) then left in a state that allows it to survive the death of the process.

I'll try some more tests to see if I can get a viable log.

Paolo

[Eve]

Yes, that is one reason for writing a log.

Even if it was being written live during the export I doubt it would give you enough information to find the problem.

I was just kidding - my way. But no, there is no log. Honestly.

Yes, that's what I thought. But security is of paramount importance to many Enterprise Architect users, I wouldn't want one of them stumbling onto this thread and taking you seriously.

[Paolo F Cantoni]

Yes, that is one reason for writing a log.

Even if it was being written live during the export I doubt it would give you enough information to find the problem.

[SNIP]

With respect, that's NOT the point. Just the metadata associated with the file will reveal valuable information.  For example - when it was last written to will reveal how far into the process the execution got. 

Accepting the observation that most Sparx logs aren't of significant use in diagnosing the problem since they export data of dubious value anyway (and, unlike qwerty, I'm NOT joking)⁽¹⁾. The log should at least tell us which parts of the process executed correctly - and so reduce the diagnosis burden.

Here's a thought, why not ask the users what they'd like to see in the various logs produced?  What would help them to figure out what the problem might be when most of the internals of Sparx processing is hidden from them?

Paolo

⁽¹⁾ For example, in the export log itself, the log tells you the types of source and target, but NOT the actual connections involved.  If you know the actual connections involved, you can work out what the types were, you can't go the other way.  We do a lot of transfers for various purposes.

[Eve]

I'm not disagreeing with you about the logging. Is is insufficient, but it's hard to get traction on getting that changed.

Is this in reference to 19113593, or is it some other issue?

[Paolo F Cantoni]

I'm not disagreeing with you about the logging. It is insufficient, but it's hard to get traction on getting that changed.

Is this in reference to 19113593, or is it some other issue?

"What is this 19113593 of which you speak?" 

No, I haven't received (AFAIK) any notification of a ticket with that ID.  I can find other tickets in my mail.  I was, however, speaking in the general case.

Paolo