This site was built to compliment the existing NetSuite Professionals Slack Community by adding a means for members to easily find answers to common questions and to create a searchable database of those questions and answers.

NetSuite Professionals

1. Why not switch to a Map/Reduce?
2. You need to `catch` the error that happens

No big reason not to switch to map/reduce was just wondering if there was a way to do it within the sched script. Will a try/catch allow ns to move onto the next record?

Nearly impossible to say about your specific case without seeing any code, but in general JavaScript if you have
```for (...) {
  try { ... }
  catch (e) { ... }
}```
and an error occurs in the `try`, then the `catch` will execute and the loop will continue

or if you're using the Search Result's `each` callback:
```mySearch.run().each(result =&gt; {
  try { ... }
  catch { ... }
  return true;
});```


If you catch the error, then as <@U29PVMVAR> pointed out, you’ll usually be able to proceed (just be sure to log or handle the error that you caught in some way).  The suggestion of a Map/Reduce is a good one, though, because by default, an error processing one record will not affect any others, so it is almost the ideal tool for situations where you want to process a bunch of records or search results, and don’t want an error on one to stop the others.  Plus, there are other benefits such as better performance, and usually less concerns with hitting governance limits.

It does come with a bit of a learning curve, but i’d say it’s worth learning if you plan to write more scripts like this in the future.

map reduce script type comes with more complexity, both in coding and the execution model, so it is not an automatic 'better' choice than a scheduled script.

<@U5375UUJ2> true.  the biggest problem I have seen is “runaway” Map/Reduce scripts that people want to stop, but there really is no mechanism to do so.  Scheduled scripts are self-limiting, as they will always run out of governance allowance eventually.  And they are more complex.  I generally see the performance benefits as worth the tradeoffs, but that is my personal opinion only.

I've run into an issue with an M/R script where it's creating invoices, and some of those records don't have an invoice number or there are duplicates. I moved the functionality to `map` from `reduce`, which has (according to the docs) less of a chance of parallelism. I need to reach out to NS to see why it's happenning.

exactly, - scheduled scripts have a more predictable sequential execution that is easy to write and easy to read. I reach for M/R scripts when I have both a highly parallel process and I actually _need_ the performance.

Also notable, by default I believe NS doesn't do ANY parallel execution of a M/R - so its performance would be on par (or possibly slower due to stages) than the default scheduled script?

We’ve done some internal tests and found that for a typical scenario of running a search and editing / saving one record per search result, that even a single-threaded Map/Reduce script runs faster.  If performance isn’t a major concern yet, then it’s not worth considering.  Our typical processing volumes are usually quite high, though, so we see a significant benefit in most cases.

I did some early testing and found the opposite, though I don't remember the exact difference in speed.