rick sipin

[rick sipin]

So here’s the result of a test that I ran. Again, here’s the versions we’re running which we’ve had decent luck with most eaDocX features using a MySQL repository:
MySQL 5.0.77 redhat-linux-gnu(x86_64)
MySQL ODBC 5.1 Driver
eaDocX 3.3.10.2 Professional Edition (updated recently to 3.3.10.4)
EA Version 10.0.1004

We’re running win7 – 32 bit clients and a few XP clients.

I had our MySQL repository cloned, and renamed all of the tables, and updated the tablenames in the usystables table to all be uppercase (i.e. T_OBJECT). Unfortunately, something in EA immediately took issue to this, and I could not open the repository, and was getting all sorts of errors where EA is expecting (through SQL pass-through I’m sure) lower case table names. At this point, I may try adjusting just the few places where we’re seeing eaDocX operation raise an error because of the expectation of an uppercase table name (as I mentioned in earlier post), but we may end up moving from mySql anyway. If you want most of the documentation features and EA to work using a MySQL repository, I’d still recommend the configuration we’ve had running for about 3 years now.

• This reply was modified 11 years, 4 months ago by rick sipin. Reason: version correction

[rick sipin]

I can do each of those, it’ll just take some time. As our repository has over 10K objects in it, I’ll have to do it on another instance, and involve our support staff. I’ll see if I can get different behavior on a windows instance. I’ll run some tests and get back to you on what we find.

Thanks again for the excellent responses. Hopefully we’ll track this down to a path that works for us. I’ll stick with the 3.3.10.4 build as it at least fixes the mixed case table name, which probably would remain an issue.
-Rick

[rick sipin]

OK, well that new build didn’t work. The tablename isn’t being completely reported in the error dialog – same add attribute operation as noted before – t_objectproperties shows up in the error dialog as Table ‘myschema.T_OBJECT’ doesn’t exist. Should note that the 3.3.10.5 build shows as a trial vs. a complete install like the 10.4 build did.

Want to give it another shot?

[rick sipin]

Thanks! I’m sure the issue is in the bowels of the ODBC driver. Having worked with a number of those over the years, there’s just some which are more ‘flaky’ than others. I suspect that this fix will be welcomed by a number of MySQL users. For anyone interested, the versions I listed in the first post on this thread have been really stable for us in both EA and eaDocX. We have quite a large corporate model repository with over 10,000 object in it.

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

[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

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

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

[Author]

Posts