T.Watz Red Ribbon

Ok, now they've updated the status-page with An incident in our database infrastructure has resulted in an interruption of service for some customer accounts. 01:27 PM

Seems to be up again

"A datacenter-wide incident in our EU Central facility has negatively impacted customers local to that datacenter when attempting to access accounting functionality. Operations Engineers were notified of the issue by monitoring and are working to resolve it as quickly as possible. 09:07 AM" accounting functionality? The…

We had the same issue here (eu2). But now it's working again

It is now resolved, but I want to express my disappointment on how it was handled. I didn't get a single update or time frame during the downtime. We were down the majority of our business hours.

Yeah, I've filed a case and got the response that they are looking into it. Our vendor has also called and reported the problem.

It seems snappier for us now and I don't get constant logouts but I can still not save any sales orders. I get a suitescript error.

And as usual, the status page says that everything is fine. How is this statuspage even updated? Shouldn't this be automatically tested and updated?

Yep, down for us too. (EU2) This is not acceptable.

The status page now says that is has been resolved, but it definitely has not been resolved for us. We don't get thrown out anymore but portlets and other UI-parts does not work. aaand now they've removed the "(resolved)" from the status page.

And now it changed back:…

Info has been posted on https://status.netsuite.com/ now "A datacenter-wide incident in our EU Central facility has resulted in a degradation in performance for customers local to that datacenter when attempting to access accounting functionality. Operations Engineers were notified of the issue by monitoring and are…

Just received an update: [B][B]Current Status: [/B][/B]Testing/Pending Release

we're on EU2 and it is down for us.

I hope that there is something wrong on the case status, because it just jumped back to: [B][B]Current Status: [/B][/B]Open - Under Investigation

They have filed a defect for us now #429240 if you need to reference that. Classified as a S2.

My hunch seems correct, even though I added yet another loop of updates on all lines in the large before submit script, the server-time didn't increase. It may not be the actual change of the values that takes time, instead it may be some server-checks that gets triggered on each line that has been changed during each…

It's non-inventory items.

Hi Olivier, no commenting out the nlapiCommitLine does not work. The revrec-dates does not get updated when I do that. regardning removing the "[...], true, true)" from the setlines. I'll try and see if it has any effect.

Hi, thats a generous offer Olivier. The script that I just described is a very small and basic one. We have one other but that is far more complex and very new as well, so I need to discuss it with our solution provider first and I have faith in them. But if you would create a script that in the beforeSubmit event copies…

With some testing, I've noticed that one of our beforeSubmit scripts is using the function nlapiCommitLineItem(type) to change every single lineitem. From what I can read about this function in the netsuite help, this function commits the line to the database (it also states that it is the equivalent of clicking "Done" on…

Yeah, I've already contacted support a month ago. They've collaborated with the technical writers(?) and just concluded that this is normal according to the documentation. It doesn't seem as they even tested our environment. They just quoted a small section of a suiteanswer. (I haven't had the last word with them yet as I…

Hi al3xicon, Yes this is all beforeSubmit. The other script that I mention that is far more complex (abt 1000 lines) use the approach that you mention and it has the same or similar issues. It also seem to take up 60 seconds of server-time on a 30 line order but it probably use the nlapiSetLineItemValue several times per…

I've read now that there is nlapiSetLineItemValue(), I guess that the thinking of the person writing the script thought that since we edit two fields, it is better to commit the line once with CommitLineItem instead of setting the two field separately with SetLineItem. Anyone know if this is true?

Hi Bodnar, Yeah I've installed that. That's how I figured we needed to fix the aftersubmit scripts. Before, we didn't have that much empty space instead we had a script that would take around 40% of the total time. Now, APM reports that the replacing beforesubmit script just takes a fraction of the time the aftersubmit…

Yeah, I'm sure that they are run one after another. But my thinking was that since the small beforesubmit-script which iterates over all lines once and commits them takes ~40s and the large one that iterates over all lines 4-5 times still takes about the same ~40s. My theory was that the server somehow merges all actions…

Nope, changing to two nlapiSetLineItemValue() instead of nlapiSetCurrentLineItemValue() didn't increase performance but it didn't decrease it either. I wonder if the system somehow processes all the lineitem-changes made by a beforesubmit script before it moves on to next script. Ie, would merging the little script into…

"User Event Script Type (Answer Id: 43800) If you check on the second diagram and read the steps on the overview of what occurs on beforeSubmit and afterSubmit operations, it explains the following on step 1 when data is sent to the application server: "processes the submitted data and performs specified validation checks…

Hi, I did run the mass updates manually. I also tried to run it on a much smaller subset of contacts. ie only the contacts related to one customer. This however did still not populate the Last Sales Activity-field. And as usual when you contact support, the first response has nothing to do with the actual problem. I say…

Hi, I just installed this bundle yesterday and ran the mass update for our 53000 contacts and 17000 customers. First, the contacts update ran for several hours, and had problems with ~10000 contacts. The customers all ran ok. No contact or customer have any info in the Last Sales Activity-field. I've just filed a…