@Siena You need to analyze your script/scripts… generally: - If you can’t get what you need with a

search

or

lookupFields

. - If you can’t do what you need with

submitFields

. - If you can’t do what you need in

beforeSubmit

. - Then and only THEN you load the record…

I admit I do not agree wit this assertion.

@stalbert So you don’t like to load the record as your last resort?

correct. In general I feel a search is heavier and slower than a record load. So it depends on what you're doing - if I'm processing 1 million records and only need a couple fields, I'll use a search rather than loading a million records.

is lookupFields slower than loading the records?

When doing a search I got the columns and data I wish, when loading a record I can’t control or know how many fields the record would have and how much data… could be 10 custom fields on top of the standards and could be 500 custom fields…

@Siena Lookupfield is faster than loading a record and is based on search. The real answer is that search is faster (or close to the sames) for very specific data (record this type, id this number, for instance), but slower for everything else.

lookupFields

is a mini-search as far as I can tell. I agree with you @alien4u but I also don't know exactly how NS implements these different calls on the database. Maybe it's a restricted SELECT statement with searches and a * for columns with a record load, I dunno.

So really my suggestion would be the following:

have you measured that lookupField is faster than loading? I have assumed so but can't recall actually measuring it.

Most of the time I use them they are about the same

I could use lookupFields for some of this but I have a function already built to extract an address out of a loaded sales order and idk how that would even work with just field names since I'm loading the address subrecord... so maybe I have to load it after all

if it has a subrecord, use nlapiLoadRecord

yea thats what I was afraid of. So I guess I have to load the record after all, but if I'm loading it in multiple scheduled scripts it will still run the risk of throwing the RCRD_HAS_BEEN_CHANGED error

So the scheduled scripts are running concurrently?

@Siena Any particular reason to load the same record multiple times in different scripts?

sometimes this can come up through no fault of your own - for example some SuiteApp installed that works with the same record type.

It depends how the client sets them up, but they may be. And they may be working on invoices and item fulfillments in separate scripts, that all are created from the same Sales Order. Its the sales order loading that has me concerned now

Hmmm... the only thought I have is to just delay opening that record and try opening it later

Basically I have separate scripts running for Invoices, Item Fulfillments, etc, and I need information off the sales order that they were created from. So I load the Sales Order

@Siena You should post here some uses cases, maybe somebody here see how to approach those uses cases in a different way.

does the error happen on load or on submit?

It seemed to happen on submit

@Siena Right there…

Okay. Are you iterating through a list of record, or just opening one specific record?

Those script using the created from(Sales Order) should not be loading the record again to get data, for that you do a search and your problem is solved.

@alien4u I think she's changing data on the sublist, so it wouldn't work =/.

@Siena And you only need a search if you are getting line level data, otherwise just lookupFields.

COuld be wrong though

What I’m understanding is needed data from the Sales Order and not modifying the Sales Order from the Invoice or Fulfillment.

Mmm... yeah, in that case, a search would work too

So what led me to believe that maybe it was the SO being loaded was the case where 2 item fulfillments were being processed in my script (ie. iterating through a list of the records) and I had already loaded the SO from the first iteration, and it didnt like me reloading. But I also thought my script would have caught that separately before it ever got to where it was failing. According to the error it failed in a separate catch statement at the end of my code, on itemfulfill.save(). So implying it was the item fulfillment throwing the error, not the sales order. Tbh I am not sure what the error was caused by.

@Siena Your problem would be solve switching those record loads to searches.

So I'm loading the SO so that I can use

addr = so.getSubrecord({
                    fieldId: 'billingaddress'
                });

Yep, a full search

You may need a full search…

actually ideally, it's best to build it in the UI so you know what you want.

Yea that's what I'll do and then the fancy chrome extension can tell me what the search should be in suitescript 🙂

@Siena You may be able to get away with lookupFields getting the addresstext which is at the Sales Order body level.

Yeah that works

No because I need the fields individually for mapping purposes, and won't that just give me a string that I'd need to parse myself?

The other things you might look into is the 'Address Fields ...' join.

Hmm oh boy, I haven't run into that yet

At least that's what I'd do =/

Yea we might just be the mean bad guys who say no custom addresses allowed or something

Yeah. No prob. Try what alien4u said for now and I hope it works out for ya 🙂

Help is always good…

Thanks for all the help!