Zadkin

A variable with a script scope seems new. I am still missing a variable with a window scope, as a session can have more than one window. The window variable problem can be solved but I find it very complex.

Is the big red part a calculated field containing the data of the 60 fields? If so, I would put it on a layout covering two pages with the other 8 fields in header and footer. When printing I expect the header and footers to be present on both pages, the big text field split over the two pages.

Is the big red part a calculated field containing the data of the 60 fields? If so, I would put it on a layout covering two pages with the other 8 fields in header and footer. When printing I expect the header and footers to be present on both pages, the big text field split over the two pages.

Is the big red part a calculated field containing the data of the 60 fields? If so, I would put it on a layout covering two pages with the other 8 fields in header and footer. When printing I expect the header and footers to be present on both pages, the big text field split over the two pages.

I needed a summary at the end of each page. I found nothing better than giving each record a page number and grouping by page number. In your case, I would go the long way: Count the number of lines of each group to calculate the position of the summary and print out the report peace by peace. Ex: Print A B (not C as it is on 2 pages, then C D E (not F as ...), ... I would probably use in this case a specific Group table to set the calculations and steer the reporting. Solution 2: use a specific page field and give each record its page, as a second summary field. In v6 there is probably the possibility to put a page break on a summary.

I needed a summary at the end of each page. I found nothing better than giving each record a page number and grouping by page number. In your case, I would go the long way: Count the number of lines of each group to calculate the position of the summary and print out the report peace by peace. Ex: Print A B (not C as it is on 2 pages, then C D E (not F as ...), ... I would probably use in this case a specific Group table to set the calculations and steer the reporting. Solution 2: use a specific page field and give each record its page, as a second summary field. In v6 there is probably the possibility to put a page break on a summary.

I needed a summary at the end of each page. I found nothing better than giving each record a page number and grouping by page number. In your case, I would go the long way: Count the number of lines of each group to calculate the position of the summary and print out the report peace by peace. Ex: Print A B (not C as it is on 2 pages, then C D E (not F as ...), ... I would probably use in this case a specific Group table to set the calculations and steer the reporting. Solution 2: use a specific page field and give each record its page, as a second summary field. In v6 there is probably the possibility to put a page break on a summary.

Your solution seems nearly correct to me, but use a concatenation of If or Cases and not a single Case statement. If( PatternCount(qq; x); "J.Ickx;"; "") & If( PatternCount(qq; y); "I.Grec;"; "") & ... The final ";" is a problem but can also be solved with some inspiration

Your solution seems nearly correct to me, but use a concatenation of If or Cases and not a single Case statement. If( PatternCount(qq; x); "J.Ickx;"; "") & If( PatternCount(qq; y); "I.Grec;"; "") & ... The final ";" is a problem but can also be solved with some inspiration

Your solution seems nearly correct to me, but use a concatenation of If or Cases and not a single Case statement. If( PatternCount(qq; x); "J.Ickx;"; "") & If( PatternCount(qq; y); "I.Grec;"; "") & ... The final ";" is a problem but can also be solved with some inspiration

Point 3 is not usefull in your case. I used it when I locked down individual records, besed on a status record on record level. By attributing the record to one specific user for example or in a definitive frozen state. In an administrative layout the records where still editable and the status could be changed to a more editable state.

Point 3 is not usefull in your case. I used it when I locked down individual records, besed on a status record on record level. By attributing the record to one specific user for example or in a definitive frozen state. In an administrative layout the records where still editable and the status could be changed to a more editable state.

Point 3 is not usefull in your case. I used it when I locked down individual records, besed on a status record on record level. By attributing the record to one specific user for example or in a definitive frozen state. In an administrative layout the records where still editable and the status could be changed to a more editable state.

I used in v6 the 'limiting access on a record-by-record basis' option to make the edition of a record dependent of - a global status field (view or edit state) - record status field (record locked as it is an audit trail, or only modifiable by a specific user) - layout ( backdoor to the previous, the record is locked but the administrator can still 'solve problems') The use of a limited access based on a global status field could be your answer.

I used in v6 the 'limiting access on a record-by-record basis' option to make the edition of a record dependent of - a global status field (view or edit state) - record status field (record locked as it is an audit trail, or only modifiable by a specific user) - layout ( backdoor to the previous, the record is locked but the administrator can still 'solve problems') The use of a limited access based on a global status field could be your answer.