- This topic has 11 replies, 1 voice, and was last updated 9 years, 3 months ago by
.
-
Posts
-
-
Hi,
I am working on Biztalk 2006. I have an orchestration which reads a positional flat file. This file has repeating records and then a trailer record. The repeating records can occur any number of times. I created the schema using the schema wizard.
The schema validates successfully when I click on "Validate Schema" or "Validate Instance".
However the receive pipeline throws the following error when it reads the file.
"Unexpected end of stream while looking for: Positional data (length is 4)"
I have tried putting the MaxOccurs property of the repeating record as unbounded. But that also does not work.The problem is that the receive pipeline is trying to read the last line after the trailer record.
Why doesn't the pipeline stop reading the file after the trailer record?
Any replies will be really appreciated.
Thanks in advance,
Semigeek
-
-
The instance always validates coz it is made based on the schema :D… when u set the test instance that is when the real errors start coming. Have you set the trailer while creating the flat file??
Take a look at this link and excuse me if you have extensive experience with flat file wizard, but I had a similar problem with delimited files and a run thorugh this link http://www.codeproject.com/useritems/FFSchemaWizard.asp(it is for delimited files but the child element configuration will be pretty similar for positional files) helped me out..why dont you paste a sample file with field positions, ill take a look.
-Mahesh
-
Hi –
Problem is the extra line feed at the end of the file. Although BT has read a full valid document, it sees there is still more data in the message after the trailer, and there is no structure to define this extra bit of data, so it is seen as an error.
I have the same issue. I used the Flat File wizard and, although it makes valid schema for the main file. It has problem with an extra line feed. I have not worked out a solution yet.
Unfortunately because there is no data – just the document delimiter, so it can't be defined as a record. That is the problem. It may be best to remove the extra line feed with a pre-process.
-wa
-
The flat file I need to read is a positional flat file with records being de-limited by CRLF. The document has repeating records and then a trailer record.
If I keep the MaxOccurs property of the repeating record to a fixed number (i.e. the no of records in the instance file) then the pipeline works properly. The extra line feed at the end does not cause any problem because it knows when to stop.
But when I change the MaxOccurs to unbounded, then it starts giving this error.
I have tried changing the Child Order to postfix, infix.. nothing works.
I am now trying to remove the extra line feed in my custom flat file disassembler. I still haven't had any luck. Will let u know it it works out.
Thanks for the replies,
Semigeek
-
have you tried creating a trailer record in the schema? Paste a sample file..ill check it out.
-Mahesh
-
I was able to remove the extra line feed in the custom flat file disassembler. But then I started getting another error. Biztalk was throwing an error while validating the instance.
The main problem is that the records in my flat file don't have any tag identifiers. If the MaxOccurs property for a repeating record is unbounded then I think tag identifiers are mandatory. Only then can Biztalk identify what type of record it is.
Now I've got 3 options
1. Tell the client to add tag identifier
2. Add tag identifiers in the custom flat file dissasembler
3. Remove the trailer record in the custom flat file dissasembler.
I leaning towards the 2nd option.
If anyone wants a code sample on how to modify the file in a custom flat file disassembler, let me know.
Thanks,
Semigeek
-
Tags are kept in flat files to identify when the context of the data is changing so if you want cities , states and something totally unrelated( lets say carname ,qty) then your file might look like
CityInfo -<this is the tag>
Denver Colarado
..blah blah
CarInfo-<this is tag>
Pontiac 10000
blah..blah..
Don't think you will need a tag for every record, nor do i think that if you set maxoccurs to unbounded than it will behave like that. Another solution i was thinking to test if this is really the problem is to set the maxoccurs to some very large value(how about 10000), this could also solve your problem eventually.
-
Why dont you test if this is really the reason, set the maxoccurs property to some very large value.
-
I've tried that also. It does not work.
I read on some other sites also. If the repeating record can occur any number of times then a tag identifier is mandatory. Some people have suggested other work around's but for me modifying the file in the disassembler seem to be the better option because I know how implement that.
Sheezzzz… Sometimes i think custom coding the entire thing would've been a better option than using Biztalk.
-
-
[quote user="Semigeek"]
I've tried that also. It does not work.
I read on some other sites also. If the repeating record can occur any number of times then a tag identifier is mandatory. Some people have suggested other work around's but for me modifying the file in the disassembler seem to be the better option because I know how implement that.
Sheezzzz… Sometimes i think custom coding the entire thing would've been a better option than using Biztalk.
[/quote]
When you set a fixed repetition on the detail record, you are giving it enough into to be able to identify a valid instance in the batch.
If you meet one structure it will pass that as a doc instance if you are configured to allow partial batches in. (I do not believe that Biztalk will take some of what's there and leave the rest without calling the rest an error.)But when you are leaving it *, it things there is more data after the last detail record, because there is a delimiter there, and there is nothing there, so it is calling the instance a failure.
-wa
-
-
-
-
-
-
-
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.