Altair RISE

A program to recognize and reward our most engaged community members

Nominate Yourself Now!

Multiple traps on same Detail. Is it possible?

Hi All,

I am using Datawatch Monarch 14 and was wondering if it is possible to set multiple traps on the same detail, located on different lines.

Example: I want to set the detail for a specific page AND a specific date, which are on different lines of the same header.

Thank you!

Best regards,

Laurentiu

Find more posts tagged with

English

Monarch

Accepted answers

All comments

Altair Forum User

Hi Laurentiu,

There would normally be two approaches this.

Generally, it can be easiest and safest to bring in all records from all pages, regardless of whether you want to keep all the records or not. It should then be relatively easy to create a filter to isolate the records you *do* want in the table. A generic trap on the date such as ÑÑ/ÑÑ/ÑÑ may work?

In general, it is usually safe to be selective on the traps for the detail, but if you use the same technique with headers or footers, it is possible to get the wrong header information added to detail lines. You mention detail and header in your question, so it may not be an issue to be aware of.

The "grab everything and filter" approach should work with Monarch Data Prep Studio and Monarch Classic.

If you do want or need to use selective trapping, then there are two options in Monarch Classic that may help.

The ‘Character List Trap’ allows you to specify multiple characters in a single space. It’s the Greek theta symbol.

For example, to grab 06/01/01 and 12/01/01, you would specify 0 and 1 for the 1^st character and 6 and 2 for the 2^nd character. But this would also grab 02/01/01 and 16/01/01.

Alternatively, Regular Expression trapping gives you very precise control, but RegEx is a programming skill in its own right (one I don’t have!).

If you can post an example of your report, then we may be able to come up with a specific solution.

Regards,

Steve

Altair Forum User

Laurentiu,

Another possibility would be the use of a multi-line trap. Are the page number and date always the same number of lines away from each other? For example, date is always 2 lines below page number?

Altair Forum User

Laurentiu,

Another possibility would be the use of a multi-line trap. Are the page number and date always the same number of lines away from each other? For example, date is always 2 lines below page number?

Hello Stephen,

This is exactly what I want.

Line 1: Trap on page number 1. (to exclude all other pages)

Line 4: Trap on date. (to exclude previous dates)

Both traps in the same detail.

The problem is that I can only select one line at a time, and the text that I write for trap doesn't change when I change the line.

So if I write page 1 and then select line 4 to write the date, I will still have "Page 1" Instead of August written there. (they are on the same column so they overlap in the trap)

Looking forward to your answer.

(I have meanwhile found a workaround, but it would still be useful for future cases if I could use 2 traps on the same detail on 2 different lines

Thanks and best regards,

Laurentiu

Altair Forum User

Hi Laurentiu,

There would normally be two approaches this.

Generally, it can be easiest and safest to bring in all records from all pages, regardless of whether you want to keep all the records or not. It should then be relatively easy to create a filter to isolate the records you *do* want in the table. A generic trap on the date such as ÑÑ/ÑÑ/ÑÑ may work?
In general, it is usually safe to be selective on the traps for the detail, but if you use the same technique with headers or footers, it is possible to get the wrong header information added to detail lines. You mention detail and header in your question, so it may not be an issue to be aware of.
The "grab everything and filter" approach should work with Monarch Data Prep Studio and Monarch Classic.

If you do want or need to use selective trapping, then there are two options in Monarch Classic that may help.
The ‘Character List Trap’ allows you to specify multiple characters in a single space. It’s the Greek theta symbol.
For example, to grab 06/01/01 and 12/01/01, you would specify 0 and 1 for the 1^st character and 6 and 2 for the 2^nd character. But this would also grab 02/01/01 and 16/01/01.

Alternatively, Regular Expression trapping gives you very precise control, but RegEx is a programming skill in its own right (one I don’t have!).
If you can post an example of your report, then we may be able to come up with a specific solution.

Regards,
Steve

Hi Steve,

Thanks for the tipp with the theta symbol, I will make good use of it in the future. ;-)

I was actually wondering if you can set up multiple traps on same detail which has multiple rows.

Example:

Line 1: Trap on page number 1. (to exclude all other pages)

Line 4: Trap on 05.08.2017. (to exclude previous dates)

Best regards,

Laurentiu

Altair Forum User

Hello Stephen,

This is exactly what I want.

Line 1: Trap on page number 1. (to exclude all other pages)
Line 4: Trap on date. (to exclude previous dates)

Both traps in the same detail.

The problem is that I can only select one line at a time, and the text that I write for trap doesn't change when I change the line.
So if I write page 1 and then select line 4 to write the date, I will still have "Page 1" Instead of August written there. (they are on the same column so they overlap in the trap)

Looking forward to your answer.

(I have meanwhile found a workaround, but it would still be useful for future cases if I could use 2 traps on the same detail on 2 different lines

Thanks and best regards,

Laurentiu

Laurentiu, I am glad to hear you've found a workaround.

If you want to try the multi-line trap, what you'll need to do is select 4 lines (or however many it may be) on the report, then select "Replace Sample Text" from the ribbon. This will create a multi-line trap. By default, the trap will look at line 1 (in your case, "page number"), but you can select the "Trap Line" dropdown and change it to line 4 if you want to trap based on the date.

After you've trapped the lines, you can create the individual fields on their respective lines within the sample area.

This picture illustrates a multi-line trap, and perhaps will give you a little more insight than my words:

Altair Forum User

Hello Stephen,

This is exactly what I want.

Line 1: Trap on page number 1. (to exclude all other pages)
Line 4: Trap on date. (to exclude previous dates)

Both traps in the same detail.

The problem is that I can only select one line at a time, and the text that I write for trap doesn't change when I change the line.
So if I write page 1 and then select line 4 to write the date, I will still have "Page 1" Instead of August written there. (they are on the same column so they overlap in the trap)

Looking forward to your answer.

(I have meanwhile found a workaround, but it would still be useful for future cases if I could use 2 traps on the same detail on 2 different lines

Thanks and best regards,

Laurentiu

Lauretiu,

Thinking specifically about Reports, it may be useful just to think of the trap and the data as two separate entities.

For the trap you are looking for a pattern somewhere that repeats and allow you to identify the row or rows that make up a record.

In its rawest form the pattern is not in any way interested in data content. Just patterns for the template.

In some cases it is useful to use what might also be "data". If it is possible to that it may be very convenient but one still needs to think of it as a pattern to be discovered when the report is parsed.

For the data, in many cases, all of the fields trapped and extracted by the pattern of the trap and the definition of the position of data field within the sample lines defined may be useful for some analysis but it is often the case that we will not want to work with all of them all of the time.

If you need two specific values only and they are on the same row of the sample data record then you can effectively trap and filter at the same time.

In general is is unusual to be able to that, especially if the resulting model is to be re-used for future reports. A more generic model tends to be better and far more flexible for repetitive use.

So one traps generically and then we can filter the results to get only the required records that you wish to work with in the table.

One of the benefits of working that way is that very often several variations of analysis can be defined in a single model. Another is that an existing model can be rapidly re-deployed for other purposes.

There are, of course, many more special approaches that we can take to extracting information from reports or other data sources. There is much to look forward to in the future.

HTH.

Grant

Altair Forum User

Lauretiu,

Thinking specifically about Reports, it may be useful just to think of the trap and the data as two separate entities.

For the trap you are looking for a pattern somewhere that repeats and allow you to identify the row or rows that make up a record.

In its rawest form the pattern is not in any way interested in data content. Just patterns for the template.

In some cases it is useful to use what might also be "data". If it is possible to that it may be very convenient but one still needs to think of it as a pattern to be discovered when the report is parsed.

For the data, in many cases, all of the fields trapped and extracted by the pattern of the trap and the definition of the position of data field within the sample lines defined may be useful for some analysis but it is often the case that we will not want to work with all of them all of the time.

If you need two specific values only and they are on the same row of the sample data record then you can effectively trap and filter at the same time.

In general is is unusual to be able to that, especially if the resulting model is to be re-used for future reports. A more generic model tends to be better and far more flexible for repetitive use.

So one traps generically and then we can filter the results to get only the required records that you wish to work with in the table.

One of the benefits of working that way is that very often several variations of analysis can be defined in a single model. Another is that an existing model can be rapidly re-deployed for other purposes.

There are, of course, many more special approaches that we can take to extracting information from reports or other data sources. There is much to look forward to in the future.

HTH.

Grant

Hi Grant,

Thanks for the reply. Indeed in the end I have found a trap in the report pattern, not in the data itself.

Best regards,

Laurentiu