Even though its a popular DB, we’re struggling to get eaDocX to play nicely with mySQL: we have to make lots of calls direct to the EA DB, and the SQL dialects are different. We can do SQLServer and Oracle, as these are the ones we see most often.
I’ll have a look again at getting mySQL to work.
Don’t worry – it’s nothing that you’re doing!
In the meantime, can you dump the data from mySQL into EAP in order to produce your documents, just until I get the mySQL to work ok?
Sorry for the bother.
Had a bit of a wasted day yesterday looking at this – I didn’t realise that EA doesn’t support the latest version of mySQL, so had to de-install 5.6 and go back to 5.5, and now I think there are some secret 5.6 bits still around.
I have complained to Sparx!
OK – All up and running now with EA and mySQL.
…and I just ran a few QuickDocuments (always a good way to test lots of bits of eaDocX and EA) and they seemed to run just fine.
What exactly were you doing in eaDocX to produce the error ?
Are you able to send me an XMI, which I can load into my lovely new mySQL database ? (firstname.lastname@example.org)
As I said in another post, I’m currently waiting to be sent some examples of where eaDocX DOES NOT work with mySQL.
I have done a quick regression test, with the bits of eaDocX where I use bespoke SQL (as opposed to the EA API) and it all seems fine.
Maybe it didn’t work for me before, because I was using a too-new version of mySQL (5.6) which isn’t yet supported by EA.
I can give you a case where EADocx doesn’t “play well” with MySQL. Create a tagged value attribute on an element of stereotype Archimate_BusinessProcess. Generate a report where the element is part of the package added to the report (insert section using current selection). Open up the profile for the ‘Table of <> Activities. Select the ‘tagged Value’ option to add a new attribute to the profile’s table. You’ll get an error message where it reports the table myschema.T_OBJECTproperties doesn’t exist. The issue seems to be in the forcing of uppercase in a portion of the table name. MySQL shows the table as ‘myschema.t_objectproperties’ and I believe this mixed case access by EADocX is what’s causing the issue.
I’ve found the place where you’re having troubles. My test environment – which has mySQL running on the same Win7 machine as EA, doesn’t produce this error.
I’ve fixed it anyway, so the table no longer has a mixed-case name in the SQL. Hopefully this will fix your issue: I don’t have any way to tell!
Fix is built into v126.96.36.199 which is now available from eaDocX.com.
Well I just installed the 188.8.131.52 fix, and the problem is slightly different. Not sure why the EA and MySQL DB Drivers don’t communicate well on table name cases, but your fix has changed the table name T_OBJECTPROPERTIES to all upper case, and MySQL has this table name in lower case. I now get the error that table ‘myschema.T_OBJECTPROPERTIES’ doesn’t exist.
Would you be able to get me a build to test where you force the table names to be lower case? If so, I’ll give it a test again as soon as I see your note.
I think I made everything upper case as that works OK with SQLServer and Oracle.
Can you manage to do a Quick Document, because that uses lots of other tables which are all addressed using upper-case table names.
So in general, we have really good luck with all of the documentation features. Attached is an exported profile that we’ve been using. It’s just that we see a few places where the table case name causes problems, as I noted in prior posting. I’d like to be able to add tagged attributes to my profile tables, as it allows us to add attributes like ‘acceptance criteria’ as we document EA objects.
The other place where the mixed case showed up was reported to me regarding stereotypes, but I’ve been unable to reproduce it. I need to get with my associate and let you know where we are seeing this problem specifically.
I suspect that since most all of the other tables work without issue, there may be an issue with how the tagged attribute control on the profile table formatting screen is getting the table name, and that it’s being done differently than w/ all the other accessors.
This reply was modified 8 years, 11 months ago by rick sipin. Reason: re-add attachment