|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
CSV and field lengths |
« View previous topic :: View next topic » |
Author |
Message
|
murdeep |
Posted: Tue Jun 12, 2012 6:24 am Post subject: CSV and field lengths |
|
|
Master
Joined: 03 Nov 2004 Posts: 211
|
Quick question that I think I already know the answer for after reading the doc.
I have modelled a pipe delimited record and it parses no problems. Now I want to take it one step further and impose field lengths so that I can have the parser throw an exception that a field is too long before I do a database insert.
My testing shows that setting the string length on my type definition doesn't force the MRM to reject the record if the data exceeds the length.
The doc seems to indicate that I can have delimited variable length but if I specify the length the data must be padded to the length which will not be the case with my data. Here's a quote from the doc:
Quote: |
Variable Length Elements Delimited
In a complex type with Variable Length Elements Delimited separation, some elements are determined by their length, and other elements are delimited. This combination of a delimited and a fixed-length format follows rules that are associated with both formats. Lengths can be given and used, but they are not mandatory.
If a length is present for a textual element, it is used, and a delimiter is not needed to terminate that element. The element must be padded to the correct length, and cannot exceed that length.
If no length is given for a textual element, the delimiter is required.
For non-textual elements, the length is determined by the Physical Type of the element. See MRM TDS format: Determining the length of simple data values.
A complex type with Variable Length Elements Delimited separation that contains only variable length elements resembles a complex type with All Elements Delimited separation. If it contains only fixed-length elements, it resembles a Fixed Length type.
|
So is it possible to have delimited fields that can vary in length but not exceed a specific length and don't have to be padded?
Regards |
|
Back to top |
|
 |
lancelotlinc |
Posted: Tue Jun 12, 2012 6:27 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
|
Back to top |
|
 |
kimbert |
Posted: Tue Jun 12, 2012 6:29 am Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
The MRM parser behaves like an XML parser. If it can parse the data then it will, regardless of the facets in the schema. If you want it to strictly validate against the min/maxOccurs and facets in the xsd then you can do that by setting 'Validation' to 'Content and Value'. |
|
Back to top |
|
 |
murdeep |
Posted: Tue Jun 12, 2012 9:44 am Post subject: |
|
|
Master
Joined: 03 Nov 2004 Posts: 211
|
Thanks for the replies.
During some more experimenting I saw that when I define my complex type as "All Elements Delimited" that a check box named "Observe Element Length" was made available and when I check it it causes the parser to enforce the length I specify when defining local elements. So I think this is what I want. |
|
Back to top |
|
 |
kimbert |
Posted: Tue Jun 12, 2012 11:38 am Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
Yes, the 'Observe element length' property will meet your requirements.
Please note, though, that 'Observe element length' property does *not* make the parser validate all of the facets ( Value Constraints ) in the message definition. If you want that, you must set Validation to 'Content and Value'. |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|