Your requirement looks very similar to the one the Frankc has [url="http://mails.datawatch.com/cgi-bin/ultimatebb.cgi?ubb=get_topic;f=1;t=000876"]here[/url] which, at the time of writing, is the post immediately below yours.
Have a look at that one for a start and see what it offers you.
[size="1"][ May 02, 2006, 05:34 PM: Message edited by: Todd Niemi ][/size]
I recommend using Monarch Pro to open your pipe-delimited file as a database (File -> Open Database...) not as a report file.
It is possible but a bit cumbersome to create a trap on such a delimited file; should be unnecessary if you treat the delimited file as a database instead.
There is quite a bit of material on Monarch Pro with pipe-delimited files, including this thread which I hope is useful to you (plus, do a Search of posts containing "pipe" - see link toward upper right corner of page):
[size="1"][ May 01, 2006, 05:31 PM: Message edited by: Todd Niemi ][/size]
Gareth stated in that thread that Mike links to:
Unfortunately, we are not likely to allow the pipe character as a trap character in the future. /quoteMy question is, Why not? It would certainly help with files that have the pipe as a delimiter, and overcome the limitations of using the database import (read the link for those problems), or for those who are not on Pro versions.
I agree that pipe delimited files are common especially in the UNIX world, but then so are csv and TAB delimited files and both of those would, I reckon, leave you with potential problems if you tried to trap on the separator character.
TAB might be a problem anyway but comma offers some potential for for normal traps in reports and does not have a conflicting special character. But I doubt it would be very viable for a floating trap if you wanted to break the line into more than 2 fields based on the first comma on a line. And if I am right about that then I would also be correct to observe that a pipe delimited file would also be unlikely to give the desired results in a typical pipe delimited file.
If that is indeed the case then having a pipe as a trap character won't offer much - it's not a very common character in reports, at least not one that is critical for trapping purposes. And the way around it would be to swap | for , or some other character, using MSRP.EXE or a similar tool if you favour something else.
That's my limited view based on past experiences - have I missed something?
Grant (about to experiment ...)
After experiment ...
Using V8 for this quick look.
In principle where the lines are fairly consistently populated and you can select a sample row that has at least 1 char data width for every possible field, it looks like the floatig trap can work, though I would be careful to define field that filled the spaces between delimiter characters even if that may lead to spaces at the beginning and/or end of the fields. This may mean painting the fields manually rather tha using the auto field feature.
Also you need a sample line that has at least 1 char space in place between the delimiter characters even when a field might be empty. If no space no field can be defined.
My guess is that for some extracted files that might be difficult to achieve. In which case a dummy report line would be required to ensure tha all fields can be defined.
As I said earlier, it could get messy. For my money reading the file into Monarch as a database would be preferable with the second choice being the calculated field with the 'split' function in preference to a floating trap. But when it comes down to it it is a matter of personal choice within the parameters of what is available.
[size="1"][ June 17, 2005, 08:19 PM: Message edited by: Grant Perkins ][/size]
I agree Monarch is flexible enough to allow a work around to almost any problem. Currently we employ a strategy of replacing all “|”(s) with “”(s) and designing a floating trap based on the “”. This works fantastically .
All of the "special" characters holding meaning in traps are very uncommon to text reports with the exception of the "|".
The "|" is very common as a delimiter or, as in the case of the example given above, a decorative character.
The other characters are great choices. The Character representing a Numeric Or Trap, (The |), should in my opinion be more "exotic".