Home Forums eaDocX queries Cant generate EADoc for models in mySQL repository

Home Forums eaDocX queries Cant generate EADoc for models in mySQL repository

Viewing 15 posts - 1 through 15 (of 30 total)
  • Author
    Posts
  • #6857
    Raelene Rushing
    Participant

    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….

    🙁

    #6858
    eadocX Support
    Keymaster

    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.

    #6859
    Raelene Rushing
    Participant

    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 🙂

    #6860
    eadocX Support
    Keymaster

    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!

    #6861
    eadocX Support
    Keymaster

    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)

    #6862
    Raelene Rushing
    Participant

    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

    #6863
    Ken Norcross
    Participant

    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.

    #6864
    eadocX Support
    Keymaster

    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.

    #6865
    Ken Norcross
    Participant

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

    #6866
    rick sipin
    Participant

    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.

    #6867
    rick sipin
    Participant

    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.

    #6868
    eadocX Support
    Keymaster

    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.

    #6869
    rick sipin
    Participant

    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

    #6870
    eadocX Support
    Keymaster

    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.

    #6871
    rick sipin
    Participant

    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
Viewing 15 posts - 1 through 15 (of 30 total)
  • You must be logged in to reply to this topic.

Compare pricing and features

Choose the eaDocX edition that’s right for you and your team

Compare Pricing

Download a free trial

Take a free, no obligation, 30-day trial of eaDocX. Discover for yourself why it’s the world’s best-selling Enterprise Architect extension.

Download