Cant generate EADoc for models in mySQL repository

[Raelene Rushing]

We have a mySql repository where we have been trying to generate documents with our trial version of EADocx….this generates errors….

Here’s the error:

Microsoft OLE DB Provider for ODBC Driver
MySQL/ODBC 5.1 Driver/mysqlld-5.1.52/Table ‘*****.T_OBJECT’ doesn’t exist

We access the database repository and the T_OBJECT table does exist and contains all the elements of our model

But, if we export the model to a file based .eap repository…EADocx works fine…

We also created a new mySql repository thinking that the original one might be corrupt…but alas still didn’t work with a mySql repository..

Any help would be appreciated….

🙁

[eadocX Support]

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.

[Raelene Rushing]

Thought that might be the issue….

We are currently evaluating this product…yesterday was our first day…..we love the UI interface…..think this alone make the product very valuable….

Unfortunately we will be using mySQL as our repository for now and future….

Can you please keep me abreast of your progress towards getting mySQL to work, so we can make an educated decision on whether to purchase the product…..

Don’t believe having to export the model to a .eap file is a good solution unfortunately…..

I don’t want to post my email address but assume you can get it through me registration? if you could send me updates on your fix that way…I’d appreciate it 🙂

[eadocX Support]

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.
Grrrr.
I have complained to Sparx!

[eadocX Support]

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 ? (support@eadocx.com)

[Raelene Rushing]

We will work on generating a small XMI file…it’ll take us a several days to get the electronic file to you

We were generating a “quick document”….several different models….one with lots of complex diagrams/elements/packages…one with just one package/diagram/element

[Ken Norcross]

I would like to put my vote in for mySQL support also, I have recently found out that our choice for a central shared sparx repository will be mySQL.

[eadocX Support]

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.

[Ken Norcross]

Thanks for the always quick replies. I learned today that I was mistaken, we will not be using mySQL! Thanks.

[rick sipin]

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.

Please let me know if you want sample data, etc.

[rick sipin]

Should have included the following:
MySQL 5.0.77 redhat-linux-gnu(x86_64)
MySQL ODBC 5.1 Driver
eaDocX 3.3.1.2 Professional Edition
EA Version 10.0.1004

We’ve had really good luck running eaDocX with our EA enterprise repository on MySQL DB using this combination of editions, just this mixed case table access issue pops up now and then.

[eadocX Support]

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 v3.3.10.4 which is now available from eaDocX.com.

[rick sipin]

Well I just installed the 3.3.10.4 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.

Thanks
-Rick Sipin

[eadocX Support]

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.

[rick sipin]

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 11 years, 3 months ago by rick sipin. Reason: re-add attachment

[Author]

Posts