MDM 5.5 (SRM-MDM 2.0) - language restrictions on MaxDB

[Former Member]

According to Note 822018 - MDM 5.5 Release Restriction Note

<...>
MDM 5.5 repositories on MAXDB
Due to specific data base restrictions MDM 5.5 repositories
can contain no more than 17 languages when working with MAXDB.
<...>

We had several crashes of MDM due to the fact, that the default installation is delivered with all (= 23) languages and the documentation is not explicitly telling, that at least 6 languages need to be deleted.

Could someone tell me what restriction that is?

Markus

[Former Member]

Hi,

for some unknown reason(s), MDM uses one table for all languages at once, meaning: an additional language will not cause new rows to exist, but to add new columns to that table.

On the other hand, the version of MaxDB used by MDM 5.5 has some restrictions concerning the maximum length of one row when it is send from database kernel to application. And this maximum length is exceeded if 18 or more languages are used at once. OK, no crashes should occur, but more than 17 languages would not do either, because they all together form too long resultrows.

With newer versions of MaxDB and application side I see chances to increase this number. But I am not familiar with the version - strategy of MDM. So, please don't ask me, which versions could be used and when this could happen.

But, may I ask what kind of company you are working for that more than 17 languages are needed?

Best wishes,

Elke

[markus_doehr2]

Hi Elke,

> for some unknown reason(s), MDM uses one table for all languages at once, meaning: an additional language will not cause new rows to exist, but to add new columns to that table.

I see...

> But, may I ask what kind of company you are working for that more than 17 languages are needed?

We don't need them - we just had crashes because of that fact.

Aside from a small "restrictions in MDM 5.5" note above there was totally no information, that WE as customers need to remove some languages before we can do certain tasks with the MDM. Since we weren't aware of that the MDM instance crashed (737832/2009).

Markus