Hi, I see the longest alphanumeric domains (that I can find) are 256-300 characters. Is there any reason not to make one that is 999 chars long?

If it matters, this is with an Oracle database.

No reason. Try and you can set a domain of string type of 999 chars. Difficult to use, to show in forms, reports etc but you can.

No reason. Try and you can set a domain of string type of 999 chars. Difficult to use, to show in forms, reports etc but you can.

Hello,

i agree with zardoz,

what should be the benefit. How to handle such a string.

Regards

Hi Bernd,

there are good reasons for long table fields. in one case I had to use a table with 4 String Fields each with a 999-Domain to hold an XML-message with maximum length of 4K! There 999 was actually too short and I had to chop up the XML in program so that it clould fit in the table :mad:

More for my understanding . . . but why would you not consider storing the message in a TEXT type of field. I would think the parsing effort would be almost the same. Plus, TEXT does not have limits.

Hi Bernd,

there are good reasons for long table fields. in one case I had to use a table with 4 String Fields each with a 999-Domain to hold an XML-message with maximum length of 4K! There 999 was actually too short and I had to chop up the XML in program so that it clould fit in the table :mad:

yes, we are talking 'unlimited' XML data. Text is fine within Baan but too tricky for external apps to look at by ODBC. FYI - this is a legacy compatibility issue rather than part of a clever new design!

More for my understanding . . . but why would you not consider storing the message in a TEXT type of field. I would think the parsing effort would be almost the same. Plus, TEXT does not have limits.

"Standard" Text handling in Baan involves writing files, and you might get issues with line breaks when you try to store XML. So both from a performance point of view and for data integrity reasons Baan Texts would not be the first choice for implementing XML storage.