I can't see an obvious way to define a field name but, depending upon what you are going to do with the extracted data, there is some scope for including the MONTH of the column as DATA (simply select it as detail data?) and then add a calculated field so that that line (or those lines, depending upon the source layout of the report) will always be sortable to the top of the data set by some method. e.g. the header line sort value = 1 and anything else = 2 for example.
At least that way you would know that the first row of data represented the column headers/field names. If your are simply publishing the results that mioght be adequate. If you are onward processing it might be enough for the next program to understand the first data line as representing field names.
I don't know that this will help but offer it in case it does.
I would like to use these names as the field names in my output table instaed of the Month1, Month2, Month3 that I have at present?
[size="1"][ June 06, 2003, 04:58 AM: Message edited by: Grant Perkins ][/size]
Grant's suggestion is the best solution to this issue which I too have had to deal with (example: reports that show the most recent 12 months of activity, etc.)
As Grant suggests, I would seek to create a detail trap which not only catches your data but also the month names as the first row of your Monarch Table. Since you would likely catch the month names on every page of the report, I'd then try to filter that excludes every row of month name data except for row #1. I am not working off my work laptop now; so I can't test this to be certain; Monarch may not allow a filter based on the ROWNO function.
Assuming you are able to pull the above suggestion off, I'd also change your output settings to not include the row names as your first row of output, since your month names are actually in the data table as the first row...
Failing all this, the awful kludge solution would be 12 different models with the correct month names as the column names...
Thanks for you help guys, I was coming to much the same conclusion myself. Now I've just got to get my head round a trap that will pick up the text of the headers without picking up a lot of the dross. There should be a law against designing reports without considering trap constraints first smile.gif[/img]
Traps to get specified header rows can indeed be fun. I've known what looked like identical headers to be different on different pages if, for example, it happened to be a continuation page for a set of data rather than the beginning of a new set on a new page. That really caused some confusion!
I'd be happy to give a second opinion if you get stuck (and security of the report is not an issue). Send me a Private Message if you feel it appropriate.
One way to sort all the headers to the top of a list (provided they can be uniquely identified and segregated from the real data) would be to simply have a calculated field that uses an IF statement. E.G. IF Field A value = 'Something unique to a header line' then New Field = 1 else New Field = 2. Then sort on New Field and strip off unrequired lines. Or perhaps just a simple summary output would be enough. It all depends upon what you want to do with the results.
Hope this helps.
Thanks for you help guys, I was coming to much the same conclusion myself. Now I've just got to get my head round a trap that will pick up the text of the headers without picking up a lot of the dross. There should be a law against designing reports without considering trap constraints first smile.gif[/img] /b[/quote]
[size="1"][ November 18, 2002, 02:20 PM: Message edited by: Grant Perkins ][/size]