Home/ Questions/Q 8666095
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-12T17:38:41+00:00

I have to extract data from a saved search and drop each column into

  • 0

I have to extract data from a saved search and drop each column into a csv file. This search is routinely over 300 lines long and I need to parse each record into a separate csv file ( so 300+ csv files need to be created )

With all the previous searches I have done this with the amount of columns required were small (less then 10) and the amount of joins minimal to none, so efficiency wasn’t a large concern.

I now have a project that has 42 fields in in the saved search. The search is built off of a sales order and includes joins to the customer record and item records.

The search makes extensive use of custom fields as well as formula’s.

What is the most efficient way for me to step through all of this?

I am thinking that the easiest method (and maybe the quickest) is to wrap it in a 

foreach (TransactionSearchRow row in searchResult.searchRowList)
{
     using (var sw = System.IO.File.CreateText(path+filename))
     {
      ....
     }
 }

block, but I want to try and avoid 

 if (customFieldRef is SelectCustomFieldRef)
 {
     SelectCustomFieldRef selectCustomFieldRef = (SelectCustomFieldRef)customFieldRef;
     if (selectCustomFieldRef.internalId.Equals("custom_field_name"))
     {
       ....
     }
  }

as I expect this code to become excessively long with this process. So any ideas are appreciated.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Using the NetSuite WSDL-generated API, there is no alternative to the nested type/name tests when reading custom fields. It just sucks and you have to live with it.

    You could drop down to manual SOAP and parse the XML response yourself. That sounds like torture to me but with a few helper functions you could make the process of reading custom fields much more logical.

    The other alternative would be to ditch SuiteTalk entirely and do your search in a SuiteScript RESTlet. The JavaScript API has much simpler, more direct access to custom fields than the SOAP API. You could do whatever amount of pre-processing you wanted on the server side before returning data (which could be JSON, XML, plain text, or even the final CSV) to the calling application.

    • 0