Discussion created by StephenWonfor on Apr 23, 2013
Latest reply on Apr 24, 2013 by StephenWonfor


FMP11 on Server 11.

I have a client who prints invoices once a week (rather than as generated - a business decision).

The setup is an Invoice::InvoiceDetails connection and we print from Invoice Details.

I have a script that figures out the dates for Monday to Friday of last week and then loops through the invoices, binding them into a PDF for each day.

These are then opened and printed. We found that a looping print routine ran into some odd memory errors and crashed a lot - the PDF method works.

I have a search that goes where the key bit it this...

Enter Find Mode [ ]

Set Field [ INVOICES::Date_Invoice; $SearchDate ]

// Set Field [ INVOICES::_cnInvoiceRows; ">0" ]

// Set Field [ INVOICES::_cnInvoiceTotalBalance; ">0" ]

Perform Find [ ]

If [ Get(FoundCount) > 0 ]

...print to pdf etc.

The two lines that are commented out were designed to ignore void invoices - no details and to only print positive balance invoices.

This has been working for about 18 months. Users reported it no longer functioning.

Now it fails if I include the row and balance counts. Both are unstored calc's with numeric results.

I placed the _cnInvoiceRows field on the invoice layout. I am looking at a 4 on the current record - 4 rows visible, but if I search that field for "4" in that field I get no records. It's like it's not a number anymore.

If I sort by _cnInvoiceRows I get a numeric sort - 1,4,6,6,6,12,13,21 etc.

_cnInvoiceRows = Count(invoices_LINE_ITEMSid_invoice_stInvoice|::id_invoice) //result is numeric

I created a dummy number field, replaced _cnInvoiceRows into it. Easy to search and I find what I expect.

This is weird. I have another routine that is failing along the same lines - searching in ORDERS for orders with total > 0. Seems like something is broken.



"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan