6 Replies Latest reply on Apr 24, 2013 6:34 AM 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

        • 1. Re: Quasi-Numerics
          Stephen Huston

          Just a thought: isn't the find criteria regarding rowCounts redundant anyway anyway ? Can you even generate a positive invoice balance without a line-item row? It seems like a search on the date-range and balance > 0 would be enough and avoid any issues related to the unstored calc counting child records.

          • 2. Re: Quasi-Numerics



            Redundant?  Yes.  But a FIND fails manually on both fields.



            • 3. Re: Quasi-Numerics
              Stephen Huston

              I suspect that you are using a relationship for the set field on INVOICES::_cnInvoiceTotalBalance; ">0". Without knowing that relationship as well as the unstored calc, it's hard to troubleshoot what may be going wrong on the Find.


              Is there a reason that the Invoice total isn't scripted to set an indexed numeric field in the Invoice record itself when the record is committed? Using a script trigger to set the invoice value to an indexed number field in the Invoice record should solve the problem and really speed things up by not using an unstored calc across a realtionship. Finds on related unstored calcs are, at best -- when they work -- really slow. That's one of the structural performance issues that script triggers can resolve.

              • 4. Re: Quasi-Numerics



                I think the gist of the matter is this:  the script has worked daily for 18 months.  Now it does not.  It has not been edited or changed. I feel that implies something far, far different.



                • 5. Re: Quasi-Numerics

                  No worries… I was just trying to be helpful…



                  Good luck with it



                  Owen Jackson | Group Projects

                  Crombie Lockwood Group

                  DDI: 09 357 4817 | Cell: 0274 899 786 | Fax: 09 623 9901


                  Description: Description: anzac poppy_scaled down

                  • 6. Re: Quasi-Numerics



                    I realize I could code more efficiently and "modern", client financing permitting, but I really think I am seeing some form of index corruption.  Checking backups and clones now.