6 Replies Latest reply: May 15, 2014 10:10 AM by Grant Perkins RSS

    Non-Trapped Rows

    sarndt _

      Is there a way to trap all rows that weren't previously trapped by my templates.  I have about a 1600 page report that has most of the rows trapped.  But some elude my templates.  And I would like to just see the untrapped rows for a quick review.

        • Non-Trapped Rows
          Data Kruncher

          The only real way to view the lines that don't get trapped is to review the report window screen by screen.

           

          If you're lucky enough to have some overall numeric total that appears on the report, then you can build a summary to ensure that your model balances to the original report. Alas, not all reports have overall totals.

           

          Can you post a short sample here of what is and isn't being captured, along with a description of your detail template trap line?

            • Non-Trapped Rows
              sarndt _

              That's what I was doing (review screen by screen)....I have header rows and other miscellaneous page header/footer rows that either don't get captured by templates I've set up or I haven't set up templates for.   These rows would be indicated by the lack of a > in the first column.   It would be nice to have an ability to capture all rows in a seperate template or table or something that are missing the > so that I can quickly views for header/footer rows I'm missing.

                • Non-Trapped Rows
                  Data Kruncher

                  To capture the lines that don't have a > in the first column, select the > character in the trap line, and then use the NOT toggle. You'll see that the > turns red and has a little line through it. Maybe do this in a new model, and paint the entire line as a single field to make it easier to review in the table window.

                    • Non-Trapped Rows
                      sarndt _

                      Not sure how to do that.   The > in the first column I'm referring to is the » symbol, which is used to indicate the line was selected.   Can I trap on this and use the NOT toggle?

                        • Non-Trapped Rows
                          Data Kruncher

                          Ah, sorry, I took it to mean that you had > signs in column 1. Never mind...

                           

                          You'll need to post a sample in order to progress here, I suspect. Please include a few samples of records that are being captured as well as a few that are not.

                            • Non-Trapped Rows
                              Grant Perkins

                              Hi,

                               

                              If you look at it from the base detail record and work up from there are you able to extract all of the detail lines successfully?

                               

                              If you collect unexpected lines that are unwanted as detail they will more often than not show up as erratic data patterns (literally the patterns) when scanning the table extracted. The same is also often true for append data if the append traps are not always working as required.

                               

                              If, however, the problems are entirely missed detail lines things are a little trickier and dependant on the expected predictable data formats.

                               

                              Running verification for the model may well help. However if the incoming report is of variable quality format with each new iteration you may need to check the model's success potential with each new report. Normally one would simply use it to ensure that the model was as required with no potential anomalies and then save the model with no need to re-verify unless something changed.

                               

                              Normally missing detail rows will have only a small number of anomalies to work around via re-defining the trap. One change should catch many of the errent rows. However if there are a lot of rows being missed for different reasons then it may be better to seek an entirely different approach for the model as a whole. That opens up many potential approaches  - too many to cover on a 'just in case' basis so a representative sample of your specific needs would be very helpful if you are in a position to provide something.

                               

                              Other than that you could look at including, during the development of the model, something like line numbers and page numbers and then look for missing pages or fewer than expected numbers of lines. These are just ideas - your source data and report might offer more successful alternatives.

                               

                              HTH.

                               

                              Grant Perkins