Newline characters and dataport

Business Central/NAV Developers Forum
1

Hi, people

I often have trouble when importing text files with dataport. It looks like the newline character is not always recognized.

Is there any known issue about it?

Presently I’m fighting with a dataport which should import a set of records from a text file.

The file holds 14 records, each record has 57 characters + a newline character (standard enter key). The dataport has the FileFormat property set to Fixed, everything else is on default value. Navision version is 4.01

When I run the dataport only the first record is read. I’ve tried other combinations of characters as RecordSeparator but to no avail…

Any suggestion?

2

Have you tried , too?

3

Hi, All. Happy Easter for those who celebrate it. [:)]

Here I am again with the same problem. First of all I apologize to whom answered me the last time. It looks like I missed the answer and failed to give feedback.

Bad for me also, because I cannot remember how I managed to work around the problem.

This time I’m on 3.70b on a different machine and platform, but the description of the problem still fits (figures aside, of course).

I’ve searched the forum for similar questions and only found my own - am I the only one experiencing this kind of troubles?

I wonder what might I have done to win it? [^o)]

4

Windows file are + (Carriage Return + Line Feed) terminated, while Unix are only terminated

So I’m just wondering if that’s not the problem you’re facing.

Try setting the field separator of your dataport field to :

if this does not work, perform a test with the following property value too :

<CR/LF>

Let us know which value has worked for you (if any) [:)]

5

Once I got file with LF+CR (characters upturned) as record-end!

Another way: If possile, open your file in some editor (not Notepad) that can show you “invisible” characters like CR (dec 13, hex 0d) and LF (dec 10, hex 0a). Check out the characters in the back of the records/lines…

6

Thank you, Tarek

I apologize for coming back so late. I had to to find a work-around to be able to deliver the job, but, as soon as I’ve been able too, I tested your suggestions.

Unfortunately, none of the characters you mentioned seems to work. A few of them cause the file to be read as if there were a unique loooong record, most cause the process to end right after the first one.

I wonder if the latter might be caused by the DataItemSeparator property, which I left to the <> default value.The second line in the text file is always blank, which means just that sequence… I also wonder what I could put in that property, instead.

Anfinur, I would be happy to be able to see which characters are hidden in the file, but any text viewer I know is only able to show/hide little squares, dots and other weird things without any clue about what’s behind that.

7

Try Ultra Edit, this note editor allows you the view the hexadecimal value of the unprintable character, once you’ve figured out which Hex value end the record, you should be able to crack it

8

Silly me! I had forgotten about that UE function!

Anyway, it didn’t bring me anywere - I just discovered that the newline characters are CR/LF, which are recognized as they are or through the code, but there’s nothing to tell the end of the file from the void lines inside it. The first void line causes the dataport to stop, because it finds a double newline sequence.

The file doesn’t seem to have any particular character marking the actual last record.