AnsweredAssumed Answered

Save PDF script problem

Question asked by bgustin on Dec 6, 2017
Latest reply on Dec 6, 2017 by philmodjunk

Like • Show 0 Likes0
Comment • 5

I have this invoicing solution that has a script "save Order/Quote as pdf" that that occasionally wants to save all records. The solution has "Orders/Quotes" with related records to the line items on the order. The script should go from the "computer layout" to the Related Record "Print Layout" and save the single Order/Quote with its related records to a PDF on the desktop. Occasionally it will save all the found "Orders/Quotes" on the "computer layout" locking up the machine for a couple of minutes with thousands of order/quotes saved. We are running FMP13 on windows 10 machines. It has only happened on 2 of the 13 computers that have FMP. The only thing I can think is it skips the Go to Related records script step. Does anyone have any ideas how to keep this from happening?

DavidJondreau

Dec 6, 2017 11:46 AM

Correct Answer

I'm assuming the layouts are all based on the same TO and that's line items?

Are you sure there's a line item for the invoice they're trying to print? If there's no related record, that GTRR script step will fail and not go to a different layout. You can check of a related record first before the GTRR and show an error. Or even better, prevent the print attempt to begin with.

See the reply in context

No one else had this question

Outcomes

DavidJondreau

Dec 6, 2017 11:46 AM

I'm assuming the layouts are all based on the same TO and that's line items?

1 person found this helpful

Actions

mikebeargie

Dec 6, 2017 11:50 AM

I'd suggest wrapping everything from the "go to related records" (GTRR) step until the end in an If statement that performs:

If [ count( T01e_invoice....::anyfield ) > 0 ]
//Do all the stuff
Else
Show Custom Dialog [ "Error, no related items to print" ]
End If

That way you can proactively trap for errors that may cause unexpected behavior with the GTRR script step.

Or better yet, don't use GTRR at all, and rather set a variable for the invoice you want to print and do a find for it instead. Since you're printing an invoice from any one of four places, this makes a lot more sense:

Set Error Capture [ on ]
Set Variable [ $id ; Invoice::ID ]
Enter Find Mode [ no pause ]
Go To Layout [ Invoice Print ]
Set Field [ InvoiceItems::InvoiceID ; "==" & $id ]
Perform Find
If [ Get(LastError) = 401 ]
    Go To Layout [ original layout ]
    Show Custom Dialog [ "ERROR, invoice not found" ]
    Exit Script
End If
Print
Go To Layout [ original layout ]

1 person found this helpful

Actions

bgustin @ mikebeargie on Dec 6, 2017 12:36 PM

I think my problem was they lines on the "Order" weren't committed yet before they ran the script. I have added a commit record step and Mike's field count check. Thanks everyone.

Actions

mikebeargie

@ bgustin on Dec 6, 2017 1:10 PM

By nature, leaving a layout to go to another layout will auto-commit a record unless you have a specific trigger in place to block it.

Actions

philmodjunk Dec 6, 2017 1:17 PM

Yes, changing layouts commits the records. Changing windows, on the other hand (if the window remains open) will not. I've been bitten by that one.

And I'd think that:

Not IsEmpty ( RelatedTable::Field )

might execute a tad more efficiently than:

Count ( RelatedTable::Field ) > 0

Much of the time it makes no difference, but if you have a lot of records, the first might execute just a small bit faster.

Actions

5 Replies

DavidJondreau Dec 6, 2017 11:46 AM
Unmark Correct
Correct Answer
I'm assuming the layouts are all based on the same TO and that's line items?

Are you sure there's a line item for the invoice they're trying to print? If there's no related record, that GTRR script step will fail and not go to a different layout. You can check of a related record first before the GTRR and show an error. Or even better, prevent the print attempt to begin with.
1 person found this helpful
Like • Show 0 Likes0
Actions
mikebeargie Dec 6, 2017 11:50 AM
Mark Correct
Correct Answer
I'd suggest wrapping everything from the "go to related records" (GTRR) step until the end in an If statement that performs:
If [ count( T01e_invoice....::anyfield ) > 0 ]
    //Do all the stuff
Else
    Show Custom Dialog [ "Error, no related items to print" ]
End If
That way you can proactively trap for errors that may cause unexpected behavior with the GTRR script step.

Or better yet, don't use GTRR at all, and rather set a variable for the invoice you want to print and do a find for it instead. Since you're printing an invoice from any one of four places, this makes a lot more sense:
Set Error Capture [ on ]
Set Variable [ $id ; Invoice::ID ]
Enter Find Mode [ no pause ]
Go To Layout [ Invoice Print ]
Set Field [ InvoiceItems::InvoiceID ; "==" & $id ]
Perform Find
If [ Get(LastError) = 401 ]
    Go To Layout [ original layout ]
    Show Custom Dialog [ "ERROR, invoice not found" ]
    Exit Script
End If
Print
Go To Layout [ original layout ]
1 person found this helpful
Like • Show 0 Likes0
Actions
bgustin @ mikebeargie on Dec 6, 2017 12:36 PM
Mark Correct
Correct Answer
I think my problem was they lines on the "Order" weren't committed yet before they ran the script. I have added a commit record step and Mike's field count check. Thanks everyone.
Like • Show 0 Likes0
Actions
mikebeargie @ bgustin on Dec 6, 2017 1:10 PM
Mark Correct
Correct Answer
By nature, leaving a layout to go to another layout will auto-commit a record unless you have a specific trigger in place to block it.
Like • Show 0 Likes0
Actions
philmodjunk Dec 6, 2017 1:17 PM
Mark Correct
Correct Answer
Yes, changing layouts commits the records. Changing windows, on the other hand (if the window remains open) will not. I've been bitten by that one.

And I'd think that:

Not IsEmpty ( RelatedTable::Field )

might execute a tad more efficiently than:

Count ( RelatedTable::Field ) > 0

Much of the time it makes no difference, but if you have a lot of records, the first might execute just a small bit faster.
Like • Show 0 Likes0
Actions

Save PDF script problem

Outcomes

Related Content

Recommended Content