A second problem with the procedure to print my pesticide use report is that the procedure stops after printing as opposed to continuing the procedure. This never happened in Pan 6. This is a destructive report that totally mangles the database, prints the report, then reverts to the file saved on disk. Since I don’t want the print form visible to the user, I open it at minimum size. The procedure stops after Closewindow and does not Revert.
If I had a procedure that knowing would ‘mangle the database’, I would probably export the data to another db that was specfically designed for this knowing that if something went wrong, terribly wrong, that my good data was secure.
It kinds of prevents against that accidental Save. You only make this mistake once before you become wiser to the possibilities.
Some 30 years ago I solved that problem by using a variable named “Task” to see what the user was doing with my files. They had to finish their Task before they could do anything else. In previous Pans, I could override all Apple and Panorama keyboard equivalents with my own and eliminate all Menu items so the user could only do what I programed and nothing else. Every procedure began with code that would immediately quit Panorama and save nothing if the Task was “Reports”. That technique was totally fool proof. I don’t see that Pan X can support this so I may have to change things.
Apparently Apple does not let procedures continue after the Print dialog command. I think it would be best to make a related database that the user can mess up, while keeping the data that needs to be preserved in another database.
Is this for real? Every one of my procedures that print have code after the Print Dialog statement. I talking Invoices, Work Orders, Product Labels, Packout Reports, Checks, Tax Forms and all kinds of other printouts. It would take hundreds of hours to develop the work arounds before I could ever use Pan X for my business.
If you have to go to a workaround, you might try adding a timer before the actual print statement. something on the order of:
starttimer "ExtraCode", "code",{If info("procedurename")="MyPrtgProc"
nop
else
//put remaining part of original procedure here
stoptimer "ExtraCode"
endif}
I’m guessing the check to see if the original procedure is running will keep the timer from executing prematurely. This may not be necessary since the timer should fire off automatically after the procedure finishes printing, but i included it just in case. Note that I have not tested this, so buyer beware.
I just tested my procedure for printing invoices. If I print an invoice for today’s date, an If statement triggers to select the other invoices for that date. This worked fine. Could the Revert statement be a problem in my other procedure? That procedure did execute the very net line which was Closewindow to close the report template
The Closewindow works. Then I get an error message saying “Field or variable [Revert] does not exist”. I tested a couple of other procedures and they continue after the Print statement so Revert seems to be the problem. Has anyone else had problems with Revert?
The wait statement requires a delay parameter of an integer value of 0 or more. Since you did not supply this delay parameter, Panorama thinks the next item Revert is a variable containing this value. Since there is no variable called Revert you get that error.
I’m really curious what sort of report is so destructive that it requires a revert to get the original data back. For most reports, simply removing summaries and possibly doing a select all is enough to get the original data back. If you needed to do some sort of running calculation (running total, for example) I would add an extra field for that purpose, so that the original data field wouldn’t be touched. In 40 years I can’t remember ever encountering a report that required the data to be destroyed to generate the report. If I ever did encounter that, I would definitely do that in a copy of the database, not the original. That could all easily be automated. But my first, second and third thought would be “isn’t there a better way to do this?”
The reason I use do destructive reports was for speed and because I couldn’t do it any other way. For example, in 2009 when I had a Mac G3 with 128 meg of RAM, documenting my July spraying took over 1000 records out of the over 12,000 in my Work Order File. Each production block must be documented separately for each chemical used. Most chemicals, either organic like I am, or convensional, are applied every 7 to 10 days to be effective, sometime more frequently, as replacement bugs are always flying in or hatching from eggs. A tank mix of 5 chemicals applied to 40 blocks takes 200 records to documant. If you spray in the morning and then in the afternoon, that is reported as a separate application requiring additional records because you have to determine the rentry interval and pre-harvest interval. California will confiscate your crop if your harvest too early and you and your workers can be poisoned if they re-enter too early. After sorting and grouping the records for the month, I then remove the detail to convert the first level summaries to detail records, then sort and group those for the final report. That report was 21 pages. The fact that I could eliminate all the menus and intercept all procedures with code to quit Panorama without saving made this safe and effective. I see that having the procedure make a temporairy copy of the file can work also since Revert is not working for me.
Another destructive report that that may be useful to many Pan users is my label printing. My Pan Inventory file includes my label report template, the design of which has been approved by my Organic certifier. This eliminates the need for a printer and enables me to print one label for a new product sample. I am the only farmer I have heard of that can print product labels with the Organic and Food Safety laws’ required production lot number to provide 100% product traceablity. An example is below. The lot number identifies the exact location where the product was harvested from plus the year and julian date that it was picked. Lot numbers must be on invoices and cases but since I can print them on my labels, I am required to do so. I use multi record invoices so I can groupup on the product code and total how many copies of each product are shipping that day. A lookup copies the lot number to the LOT# field in the Inventory file. I then loop through the products and use addrecord to duplicate each product record for the number of products going out. On a busy day I might print several hundred labels, adding hundreds of records to the Inventory file. Revert cleans it up ready for the next harvest day.
That doesn’t sound destructive to me. Couldn’t you easily mark these records as temporary, then easily delete them when you’re done, instead of using revert? Or, another option would be to use a second database for this, as suggested by others here.
