I think I may have this figured out. I am going to create a Script Flag field that will hold a 1 if the scripts I only want run once per record have been run. Then have my script check that field before doing anything. Exit if Script Flag = 1. Otherwise it runs.
To suggest anything, we'd need to know more about how you have set this up and which of those ~12 records for a given day you'd want to print.
If you still haven't gotten this to work, perhaps you can post a more detailed example of what you are trying to do with your database.
My print layout is 24 columns (I attached a snippet of it). Each column is one long portal which I have dropped my fields onto. The database relationship is set up to show the record data based on the date. I did come up with a way to get the printing working right but I am unsatisfied with it as I am seeing some anomalies during testing.
My script to find the records to print sets the find field as START DATE ... END DATE. I need a way to further narrow that find to only find 1 record for each day, that way I can use the "Print records being browsed" option to print a sheet out for each day. The amount of records per day can vary anywhere from 12 to 24. If I just set only the Date in the find, then I will get 12-24 pages per day because it finds all the records for the day.
Is the first column one portal, and the second column another portal, and the third column another, etc, or is the layout one portal in a multi-column layout?
It is unusual for the best printing option to be to print a portal, because usually portals are used when there is a variable number of records, and the user may want to scroll the list on-screen. When you want to print what amounts to the contents of a portal it is more usual to silently take the user to the portal's source table, to a dedicated print layout, then return them to their original screen. Then you have many more options about how to present the records.
Maybe if you can guarantee that the on-screen portal's size will always be enough to display the records required then that technique may not be necessary, but it still limits you with exploting date range finds, sub-summaries, page-breaks, etc.
I think the way you seem to have it set up now would mean you have to find the first date, print it, find the next date, print it, etc. If you used the more conventional technique above you can find the date range in one find, then sort it, sub-summarise, and have page-breaks as well.
Maybe I have completely mis-understood what your question is - sorry.
Yes, there are 24 portals in the layout with all the fields dropped on top of them. Maybe a crazy way to do it but it was how I figured it out. :S
I attached a screenshot of what it looks like when I turn on edit mode. Maybe crazy looking?
So that one screen is one day? Is it one record = one screen = one day?
"if you want to print one day because I can just have it omit the current record, then show only omitted, and it will still print all the days records because of the way the layout is set up." That sounds like that method of finding one record means that is showing one day. So if one record = one day, then 3 days = 3 records. So that is where I am confused: I don't understand how one record (found via show omitted) is one day, but 3 days found is 36 records.
Or do you mean that each day has about 12 records, but the omit-trick lets you decide which of the 12 records for that day you want to print? If so, what is the distinguishing feature that makes that record for the day the particular one you want to print? Why not add that as an additional search criterion?
Each day is 12-24 records. If I search for say... 9/6/2011 ... 9/9/2011 then I get a result of 36-72 records. So if from there, I click Print and select Records being browsed, then I will get 36-72 pages instead of 3. If I select Print current record, I will only get one day - the day of the record in focus.
I need to somehow only select only 1 record from each day that way when I select Print records being browsed, I will get the 3 pages with however many records were done in those 3 days (because I have the relationship set for Date = Date and portals). I am wondering whether there is a way to do that without having to add an additional field to my database. I had it printing correctly by adding a key that would count up starting from 1 and then reset when a new day was detected and then I would add 1 to the search parameter to get only 1 record per day but this method relied on a triggered script that somehow ended up bugging out during testing a few times and not setting the counter back properly which meant there were extra 1s and more records found than there should. Or it could be possible that I just wasn't paying attention during my testing and acidentally bypassed my script. But like I said, I'd rather not do it the way I am doing it in the first place.
Yo have a traditional parent - child pair oftables - like having a Sales Order header table, and then a Sales Order Items table. One Sales order has many Item records, all associated to their parent by the SalesOrderID. Call up one Sales Order Header and you will see all its item records in a portal. You've got that set-up... but without the header table. You have self-related every day's record to the same file, so as you've seen if there are 12 records for one day, all related to each other, then you will get 12 records each with identical portals.
My suggestion would be to defer to convention, and have one header record = 1 day, then create each day's record in another table, as a child of that header record. You will be able to do so much more, easily, with that set-up.
However, to print what you want now, you might not even have to do that. Just create another layout with the field in the portal in the body section, and make it a multi-column report. Find the date-range and sort it by however it is sorted in the portal listing.