t_umlpattern

[Thomas Mercer-Hursh]

I have had a residual tacky bit dealing with an OpenEdge repository relating to t_umlpattern.  This doesn't seem to be a table that I am actually using anywhere, but when I do the initial transfer from EABase to create my base OpenEdge repository I get an error on 15 t_umlpattern records which is either "The XML for UML Pattern `X' is too long and the preview image has been removed" or "The XML for UML Pattern `X' is too long and X has been set to an empty string.  I am assuming this has to do with JET files allowing 65K characters in a memo field, while OpenEdge has Notes and PatternXML defined as character, which means a max of 32K (actually less since it is 32K per record as well) and EA apparently won't use the CLOB fields available in OpenEdge.

But, like I say, this functionally doesn't seem to impact us, but then every time I transfer one of these models to an EAP, I end up with another set of error messages.

Presumably, I could just delete all the patterns and that would be fine, but is there some kind of cleanup activity I can do that will just get rid of the errors and leave as much as possible in place?

If I go to UML Patterns under Resources and try to view them, the ones where the message related to the preview will open, but there is no preview (duh!) whereas the ones set to empty string are listed, but can't be viewed.

I am happy to muck around in the data directly, if that helps.  I'd just like to clean up my base so that I am not getting errors all the time on the transfers.

[Thomas Mercer-Hursh]

Well, not exactly a stunning list of responses, eh?  So, is there any way to export these patterns at all?  I don't see it on the resource export and there is right-click import, but not export, and anything I have tried for exporting them from Access has given me an error relating to the row being longer than 65K.

[KP]

I assume they are the GOF patterns. They are available from this page (in Java, C# and language-free versions) so you might be best off just blowing them away and reloading them...

[Thomas Mercer-Hursh]

I expect that will yield the same issues since there are files for individual patterns there which are 74K.  I suspect they are just that big.

[Eve]

I would remove all the patterns that can't be handled at all from your OpenEdge repository.  Then export the patterns as reference data, and re-import them into the eap file you are normally transferring from.

This should avoid future errors.

[Thomas Mercer-Hursh]

I don't see any reference to patterns in the Export Reference Data dialog.

I think, though, that the base problem here is that the patterns are simply too big for the 32K character limit on Character variables in OpenEdge and in cases where that isn't true, the combination of the pattern and notes blows the 32K limit on records.  I think that in order to support these patterns in OpenEdge, there would need to be support for OpenEdge CLOB data by Sparx.

[«Midnight»]

What about a trigger or something on the OE side? Is this possible? EA seems to be quite tolerant of triggers and stored procedures being used to extend the schema.

[Thomas Mercer-Hursh]

You mean a trigger that would take the attempted update and flip it over into an alternate table that used CLOBs and vice versa on read?  Interesting concept ... which I might explore if I felt any need to use the contents of this table.  Right now, it doesn't seem to apply to what I am doing so my biggest interest in trying to handle it is to maintain compatibility with standard product ... but I might try to get someone else to handle it.

[«Midnight»]

Before you go too far, remember that my suggestion has a - critical, fatal? - weak link. You would be in serious trouble if you had to do a round-trip with an EAP file as one of the nodes.

[Thomas Mercer-Hursh]

Any EAP file which we might have would be created by a Transfer from the OpenEdge DB, so it should be OK.