Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Label printing
- Thread starter Clewley
- Start date
- Thread starter
- #3
What is happening now is that each time a group of mailing labels is to be printed, there needs to be a separate sheet in the printer, so the labels don't print one on top of another. What I would like to do is have the ability to print, say, 7 labels on a sheet. Then, place that sheet back into the printer, and the next time I print labels, have the labels start printing in the 8th position on the sheet, so as to not waste a lot of label sheets. I hope this clears it up. Jim Clewley
Global Financial Consultant
Unisys Corporation
james.clewley@unisys.com
Global Financial Consultant
Unisys Corporation
james.clewley@unisys.com
Well, the problem I see is that you look like you are talking about running the report multiple times; each successive run could/would have additional mailing labels, but you don't want to print the labels that were already printed from the first (or previous) run. Is this correct?
I'm fighting some sleep depravation, so bare with me... there might be a better solution. However, the only one that comes to mind is putting a parameter on the report which would signify where to start.
With your example, 7 labels are on the first run of the report; the next run of the report would then have a parm. that would allow the user to input where to start: label #8. You would then use this in logic in the Fetch() to do one of two things:
1. Ignore the first 7 records (parameter - 1), and also use this to determine where on the page (in the flow) to start printing new records/labels (knowing the location of each label on the flow would be necessary).
2. For the first 7 records (parameter - 1) send blank rows to the report, then fetch the remaining records as normally would be done.
This second option "should" allow nothing to be printed overtop of the previous printing, and to start where you left off before. Beware, this is untested!
As far as setting some variables which Actuate could pick up on for the next run(s) of the report, no easy thing comes to mind. You would essentially have to have this in a .bas file, and modify the bas file during each run... and I'm not sure that's even possible.
On the other hand, if there was a database column to hold this info... you could write to the database each successive run and update that field -- but the logic to keep this in line, so that you're not wasting resources after it becomes multiple pages, and .... it could get nasty, not to mention performance. You'd have to hit the db to get the data, then do it again to update. A whole new can of worms there.
Again, sorry if any of this is incoherant.
Good luck!
Bill
I'm fighting some sleep depravation, so bare with me... there might be a better solution. However, the only one that comes to mind is putting a parameter on the report which would signify where to start.
With your example, 7 labels are on the first run of the report; the next run of the report would then have a parm. that would allow the user to input where to start: label #8. You would then use this in logic in the Fetch() to do one of two things:
1. Ignore the first 7 records (parameter - 1), and also use this to determine where on the page (in the flow) to start printing new records/labels (knowing the location of each label on the flow would be necessary).
2. For the first 7 records (parameter - 1) send blank rows to the report, then fetch the remaining records as normally would be done.
This second option "should" allow nothing to be printed overtop of the previous printing, and to start where you left off before. Beware, this is untested!
As far as setting some variables which Actuate could pick up on for the next run(s) of the report, no easy thing comes to mind. You would essentially have to have this in a .bas file, and modify the bas file during each run... and I'm not sure that's even possible.
On the other hand, if there was a database column to hold this info... you could write to the database each successive run and update that field -- but the logic to keep this in line, so that you're not wasting resources after it becomes multiple pages, and .... it could get nasty, not to mention performance. You'd have to hit the db to get the data, then do it again to update. A whole new can of worms there.
Again, sorry if any of this is incoherant.
Good luck!
Bill
- Status
Similar threads
- Locked
- Question