Always avoid running SQL commands against the raw data (unless you are fixing corrupted data). 

The Visual Integrator module is how you import bulk data into Sage 100, and it does all the required BOI data validation (which would be skipped in a SQL script).  If your VI job's input data matches an existing primary key, it will update.  If not it will add.

To upload your rollup codes / UDFs, add AccountKey to your source data.

Thanks.  That is what I always thought, but I was not able to figure out the VI import file.  I thought in this case, it would be okay to do the SQL update since it appears there would be no need for data validation of integration with other files.

I had a situation where I was forced to pull in data using SQL (millions or rows of history from Oracle, for a customer converting to Sage 100, and it would have taken weeks just to run the import, let alone the posting process).  It was a nightmare of trial and error, resetting, then trying again.  There are so many little details that you wouldn't think of until you test (something simple like not stripping out illegal characters from a field can cause a crash).

VI saves you from all that, by doing all the necessary work... it is worth learning how to do it the proper Sage 100 way.

I do UDF updates by SQL (changing a line flag for an automated process) but for anything else, I avoid direct SQL data edits.