Method Community

For some reason an old screen of mine is behaving differently all of a sudden. I have not made any recent changes to this screen. A grid loop is being performed in an action but it's now running unbounded (entire table scan for 17,588 ActivityJobItems) rather than being constrained to the job items for the particular Activity ID.

What would cause this?

I also saw this happen today and had a different customer report the same thing.

I'm also seeing other very strange behavior on my sales order screen. Custom validation errors and subsequent user messaging (ShowMessage) is popping up that shouldn't be on sales orders. It's like certain actions are firing in very strange ways and I have no idea how that can happen.

It's preventing my salesmen from putting new orders in the system and holding up our fulfillment process.

There's definitely a problem with the Start Loop Through Grid action. I'm seeing this on my Sales Order screen right now, too. The query is running unbounded with no constraint for the current sales order hence a LOOP OVER THE ENTIRE TABLE!

Here's the debug trace for my sales order screen's Loop Through Grid action. See my note at the end...

Query for Loop:SELECT ROW_NUMBER() OVER (ORDER BY VIEWACCSALESORDERLINE.[LINEORDER] ASC) as [ROW_NUMBER], [viewaccSalesOrderLine].[RecordID], [viewaccSalesOrderLine].[TxnLineID], [viewaccSalesOrderLine].[Desc], [viewaccSalesOrderLine].[Quantity], [viewaccSalesOrderLine].[Rate], [viewaccSalesOrderLine].[IsRatePercent], [viewaccSalesOrderLine].[Amount], [viewaccSalesOrderLine].[Invoiced], [viewaccSalesOrderLine].[IsManuallyClosed], [viewaccSalesOrderLine].[Other1], [viewaccSalesOrderLine].[Other2], [viewaccSalesOrderLine].[hiddenInternalCUSTOMFIELD20], [viewaccSalesOrderLine].[hiddenInternalCUSTOMFIELD3], [viewaccSalesOrderLine].[hiddenInternalCUSTOMFIELD4], [viewaccSalesOrderLine].[hiddenInternalCUSTOMFIELD5], [viewaccSalesOrderLine].[hiddenInternalCUSTOMFIELD6], [viewaccSalesOrderLine].[hiddenInternalCUSTOMFIELD7], [viewaccSalesOrderLine].[hiddenInternalCUSTOMFIELD10], [viewaccSalesOrderLine].[hiddenInternalCUSTOMFIELD9], [viewaccSalesOrderLine].[hiddenInternalCUSTOMFIELD8], [viewaccSalesOrderLine].[hiddenInternalCUSTOMFIELD11], [viewaccSalesOrderLine].[hiddenInternalCUSTOMFIELD12], [viewaccSalesOrderLine].[hiddenInternalCUSTOMFIELD13], [viewaccSalesOrderLine].[hiddenInternalCUSTOMFIELD14], [viewaccSalesOrderLine].[hiddenInternalCUSTOMFIELD15], [viewaccSalesOrderLine].[hiddenInternalCUSTOMFIELD16], [viewaccSalesOrderLine].[hiddenInternalCUSTOMFIELD17], [viewaccSalesOrderLine].[hiddenInternalCUSTOMFIELD18], [viewaccSalesOrderLine].[hiddenInternalCUSTOMFIELD19], [viewaccSalesOrderLine].[hiddenInternalCUSTOMFIELD1], [viewaccSalesOrderLine].[hiddenInternalCUSTOMFIELD2], [viewaccSalesOrderLine].[UnitOfMeasure], [viewaccSalesOrderLine].[TxnMethodFlag], [viewaccSalesOrderLine].[hiddenInternalCUSTOMFIELD21], [viewaccSalesOrderLine].[hiddenInternalCUSTOMFIELD22], [viewaccSalesOrderLine].[hiddenInternalCUSTOMFIELD23], [viewaccSalesOrderLine].[hiddenInternalCUSTOMFIELD24], [viewaccSalesOrderLine].[hiddenInternalCUSTOMFIELD25], [viewaccSalesOrderLine].[hiddenInternalCUSTOMFIELD26], [viewaccSalesOrderLine].[hiddenInternalCUSTOMFIELD27], [viewaccSalesOrderLine].[hiddenInternalCUSTOMFIELD28], [viewaccSalesOrderLine].[hiddenInternalCUSTOMFIELD29], [viewaccSalesOrderLine].[hiddenInternalCUSTOMFIELD30], [viewaccSalesOrderLine].[TotalAmount], [viewaccSalesOrderLine].[LineOrder], [viewaccSalesOrderLine].[ItemDetails], [viewaccSalesOrderLine].[TMCInvoicedQty], [viewaccSalesOrderLine].[TMCInvoicedAmount], [viewaccSalesOrderLine].[TMCInvoiceNote], [viewaccSalesOrderLine].[TotalWeight], [viewaccSalesOrderLine].[Fields], [viewaccSalesOrderLine].[Products], [viewaccSalesOrderLine].[TMCPrintMe], [viewaccSalesOrderLine].[LotNumber], [viewaccSalesOrderLine].[SerialNumber], [viewaccSalesOrderLine].[SquareFootage], [viewaccSalesOrderLine].[InvoicedAmount], [viewaccSalesOrderLine].[InvoicedQty], [viewaccSalesOrderLine].[RemainingAmount], [viewaccSalesOrderLine].[RemainingQty], [viewaccSalesOrderLine].[IsFullyInvoicedTMC], [viewaccSalesOrderLine].[Class], [viewaccSalesOrderLine].[Class_RecordID], [viewaccSalesOrderLine].[Item], [viewaccSalesOrderLine].[Item_RecordID], [viewaccSalesOrderLine].[ItemFullName], [viewaccSalesOrderLine].[ItemName], [viewaccSalesOrderLine].[Weight], [viewaccSalesOrderLine].[PackAmount], [viewaccSalesOrderLine].[ItemType], [viewaccSalesOrderLine].[ItemParentFullName], [viewaccSalesOrderLine].[ItemVendor], [viewaccSalesOrderLine].[SalesOrderRecordID], [viewaccSalesOrderLine].[SalesOrderRecordID_RecordID], [viewaccSalesOrderLine].[SORefNumber], [viewaccSalesOrderLine].[SOCustomer], [viewaccSalesOrderLine].[SODate], [viewaccSalesOrderLine].[SalesRepPreferredName], [viewaccSalesOrderLine].[Customer], [viewaccSalesOrderLine].[SalesOrderTMCSalesOrderStatus], [viewaccSalesOrderLine].[SalesOrderSalesRepRecordID], [viewaccSalesOrderLine].[SalesOrderTMCServicedFromClassName], [viewaccSalesOrderLine].[SalesOrderTxnDate], [viewaccSalesOrderLine].[SalesOrderLineGroupRecordID], [viewaccSalesOrderLine].[SalesOrderLineGroupRecordID_RecordID], [viewaccSalesOrderLine].[SalesTaxCode], [viewaccSalesOrderLine].[SalesTaxCode_RecordID], [viewaccSalesOrderLine].[ActivityJobItemWorkOrderID], [viewaccSalesOrderLine].[ActivityJobItemWorkOrderID_RecordID], [viewaccSalesOrderLine].[LocationBin], [viewaccSalesOrderLine].[LocationBin_RecordID], [viewaccSalesOrderLine].[LocationSite], [viewaccSalesOrderLine].[LocationSite_RecordID], [viewaccSalesOrderLine].[TenantID] FROM viewaccSalesOrderLine WITH (nolock) WHERE (viewaccSalesOrderLine.TenantID=@TenantID OR viewaccSalesOrderLine.TenantID IS NULL)

Number of records returned:19848 <<<<<<< --- SHOULD BE LOOPING OVER 2 LINE ITEMS ONLY, NOT THE ENTIRE TABLE. CURRENT SALES ORDER ID AS CONSTRAINT IS MISSING FROM THE QUERY

This could be really damaging as we run table loops all over the place in Method. We could be executing logic over entire tables and messing up A LOT OF DATA if I'm thinking about this properly

I've deactivated all my user logins until this issue is fixed. I'm just really freaked out seeing unconstrained queries running over entire tables. Really wish someone at Method would confirm the issue, provide some feedback on this. Thx 

I had a client complaining to me late today about not being able to do anything in Method because everytime he saves something, he's getting these system messages (in yellow) at top of the screeen saying "Processing XYZ records from a total of 9,567".  All his screens are custom screens and nothing has changed on our side for months/years.  I saw that Method was doing an update this week so clearly it's affecting a function.  I didn't dig into this any deeper than checking the number of records in the assoicated table for the screeen and noticed that they matched exactly with the message for the total number to be process; i.e. it's running through every record of a table, everytime, thus Method is clearly broken right now.  In this specific case, the table involved was the SaleRecieptLine table.  

Ditto. The same yellow message showing record looping progress was what caused me to look into the issue further as well. That's what led me to turn on debug trace and pull the sql being executed. The total record count matched that of my entire SalesOrderLine table. This started yesterday around 2:30PM CST but I didn't get a chance to really troubleshoot and understand the issue until ~4:00-4;30.

I can't believe there's no automated testing on new Method check-ins & builds to catch something like this. Freaks me out re: the stability of the platform that we rely on for business operations.

My users cannot use Method until the issue is resolved and we won't be able to run our business this morning. DOWN.

We just wanted to confirm that we're on it, and will get back shortly with an update.

-Method Team

Awesome. Thank you

It appears looping is working correctly again. Any reason I need to hold off putting users back on the system? Thx

Hi Blake,

We just spoke over the phone. We rolled back the update that we deployed yesterday so this is no longer an issue. You’re safe to re-enable your users and our development team is investigating what caused this. Can you explain what your loop is meant to accomplish so that we have further context to investigate?

You mentioned that you don’t think that you have any corrupt or lost data due to this, but there is certainly the potential for this. If anyone else who’s following this thread believes that they have lost or corrupted their data due to the looping issue, please give us a call at 1.888.925.6238 x2 or email support@method.me and let us know. We perform backups of every account on a daily basis and may be able to use these backups to correct this. We apologize for any inconvenience that this may have caused.

--Audisho

Thank you. I think all my data is fine. Luckily the screens my users are on each day don't make use of data updates in grid loops. Just some read-only validation logic but nothing that does bulk updates/deletions, thank God.

Hopefully you guys now have some automated tests for this going forward.

Wish we could go back to the days of stage sites for these kinds of updates.  I shudder to think what could have happened had this update gone out, say tomorrow, when our clients run a bunch of start of the month routines like sending out recurring invoices and sales receipts to their customers.  Can you imagine what they might have looked like?

Hi,

I think I need database rollback. The question I want to clarify are:

1. Can you give more input about this system issue, so we can do more check befoe making rollback decision? Is it only for Grid Loop or other functions?

2. How long does it take to rollback the database? 

3. When the data got recovered, any impact to our local QuickBooks? Let say, if the database is back to Sep/28/2015, will QuickBooks update the data input in Sep/29/2015 to Method, or QuickBooks will be notified to remove data input on Sep/29/2015?

4. Does it impact the data only, or will it reover the screen/actions?

---

Alex