The answer is most likely "Yes" although that assumes you are not using a very old version of Monarch.

How you do it will depend quite a lot on the exact layout of the report and what it offers to help you.

One way might make use of a multi-row field to populate the table and then break that up into separate fields using calculated fields and some functions. (Which functions will depend on which version of Monarch you have.)

Another way might be to use an overlapping Append Template and a field with a preceding string to identify its applicability.

If you are not already familiar with such concepts try a search through the forum files for "Multi-row" or "multi-line", perhaps with and without the hyphen, and "preceding string". There are some recent examples of the use of these ideas and quite a number scattered back through older entries.

Thank you Grant!! I'm using version 7, but would consider upgrading if it would provide a better solution. I'm not familiar with overlapping templates, but will do some research on this forum. What's your recommendation on upgrading? Thanks again for your time!

Thank you Grant!! I'm using version 7, but would consider upgrading if it would provide a better solution. I'm not familiar with overlapping templates, but will do some research on this forum. What's your recommendation on upgrading? Thanks again for your time![/quote]

Sacha,

I would ALWAYS recommend and upgrade since new Monarch releases invariably add something useful to our Report Mining tool kit and Version 8 and 9, especially the Pro versions of course, delivered a lot.

That said I don't believe you would need[/i] an upgrade to solve this problem.

The overlapping template traps are not something you will find documented in many places - except the forum!

By design Monarch always expects an Append template template to be gather data from BEFORE a detail record. By making the trap for an append the SAME as for the detail record you ensure it will apply form the same point and also RESET every time there is a new detail record identified. So the APPEND data will NOT be applied to more than one detail record. In this case this is a good thing.

However the potential uses for this are somewhat constrained. If the data we want to capture always exists then we don't need this approach. If it does not always exist we need some way to identify it ONLY when it DOES exist. Therefore we really need some sort of TAG or Label in the report that allows us to identify the field we want only when it exists. The field we create will, of course, exist for every records BUT unlike a regular field definition it will only be populated when the preceding string is there as well.

The other interesting aspect of the preceding string approach is that we don't need to know or specify which line the field may be on if it is there. Monarch will find the first occurrence that matches on any line between the trap line and the start of the next template. It will do this no matter how many lines the trap sample is set to PROVIDING the field uses either the "Preceding String" or "Preceding Sting on the previous line" options in the advanced properties for the field.

Of course you do need something that is UNIQUE to the positions before the field you want to grab to make the preceding string work and not all reports provide that. So while the concept is a sound one it may not be possible to use it on every occasion because there may be no way to reliably identify the field by a preceding string start point option.

If your actual report format makes this difficult or impossible because it lacks a tag of any sort, the next best thing may be to simply take the entire block of characters from line 2 onwards using a multi-line field as part of your detail template. Exactly how you define that will again depend on the actual format of your report but one way or another you will be using the field's advanced properties to define how the multi-line field end point is to be identified.

Having collected a block of characters you then split the block into the separate field you need using calculated fields and some of the many Functions Monarch offers for field manipulation. I can't be much more specific that that without seeing the real report but I think it is fairly certain that there will be a way, maybe several ways, to approach that split.

If you find you do need to develop a solution using the multi-line extraction then there may well be some clear benefit to upgrading to Version 9 since there are a couple of function enhancements that came after V7 which make working with text blocks quite a bit easier in this sort of situation.

The potential for developing an easier solution more quickly would probably justify the upgrade cost in most situations. (Perhaps not if you have a very extensive network installation of Monarch with a lot of licenses - unless of course everyone gains something from the updates in which case it would still be justifiable. Working with PDF files might be a big help for example?)

All of this is actually easier to do that to describe.

Have a go at it. If you get stuck let us know and consider whether you can make available a sample (cleaned of sensitive information but not losing anything that might be useful for trapping/preceding strings) of the actual report for which a working model might be created and sent to you.