I have a large quantity of applications developed for a client that reformat data for import. The import requires the data to be in multiple lines. /b[/quote]Was this data originally a text block by any chance? If so have you looked at the potential for using the new-to-V8 TEXTLINE function?
If not originally a text block I think you could ignore this post ...
Guess I wasn't real clear. I am importing into another product that requires the chr(10) to break the record into two lines. The input to Monarch is a single line. I am inserting a linefeed CHR(10) using a calculated field. When I export to a text file, Monarch v8 changes the chr(10)to a chr(20) which is a blank. Is there a way to keep it from changing CR(13) or LF(10) to blank?
When I export to a text file, Monarch v8 changes the chr(10)to a chr(20) which is a blank. /quoteThis is interesting. I tried to build a sample text file and model using a calculated field as gmc described. In trying to find a solution for gmc's problem, I ran across an anomaly...
I created the calculated field "Chr Test" with this simple formula:
[font="courier"]asc()[/font][/quote]And it instantly became clear why gmc was having trouble using Chr(10) in that he isn't getting what he expects - Monarch evaluates Chr(10) to Ascii 0. That's not a typo - that's zero. Not 10, but 0. :confused:
If you put any other number in the Chr function, the Asc function returns that number; under 10 and over 10 are fine, but not 10. :confused:
:confused: :confused: :confused:
If you run a search using "export crlf" is should turn up 3 posts of varying ages which contain related information, though perhaps not a conclusive definition of how the export is intended to work. I seem to remember getting a full explanation once but can't remember where that might be.
That observed, your requirement is slightly different in that you are trying so split a line that was not previously split. (As I now understand it.)
The only suggestion I can make is one that is on the posts you will find with the search.
In simple terms when you define how you want to split the field rather than inserting a crlf insert something else 'unique' to the file and then run a program like the MSRP utility to change the dummy code to crlf after the export.
I would think it should be possible to make a batch file (or program) to make the process unified.
Of course I am assuming that the field type you are exporting to will allow you to read the file and apply the changes.
Thanks for your replys and ideas. I did some additional testing and it is clear that Monarch version 8 replaces any Linefeeds with blanks. 01-09 and 11-15 are untouched. But a 10 (linefeed) clearly is replaced with a 20 (blank). I export to a text file, so it is obvious when you see the raw results in a Hex editor. Also, this is working in Version 7. I can't think of a character that 100% would not exist in any data, so MSRP is only a 99% solution. Since the stripping of LFs was an addition in Version 8, is there any export option to leave the output untouched?
Thanks for your replys and ideas. I did some additional testing and it is clear that Monarch version 8 replaces any Linefeeds with blanks. 01-09 and 11-15[/b] are untouched. /b[/quote]Does that mean you could insert a CHR(13) and it would work and you could then change that to a 10 post export?
Looking at the short term response (which may also be the long term response), there are some quite obscure characters once you get above 128. Although I have no idea what you are reading on the input side and there is always the possibility that sometimes the higher character numbers may alternate for something in another language, I would imagine that most of them - 170 for example, are obscure enough to be safe. And you could always check for the existence of your preferred character before processing using the EXAMINE utility.
Using a combination of characters as a substitute string may also be an option which would improve the odds for successful export.