Update Multiple fields at once

[CCWeedcontrol]

I trying to figure out a better/simpler way of clear multiple fields(meaning making the attributes in fields " ") at once but not all, just specific fields.

I can do it with field calculator but that means i would have about 70 field calculators in the scrip.

How else can this be done, examples?

[BlakeTerhune]

Check out the new Calclulate Fields tool introduced in ArcGIS Pro.

Edit:

You could still use Calculate Field, just put it in a loop of field names.

[CCWeedcontrol]

How would I pass the certain fields and query ( "IS NOT NULL") to use arcpy.CalculatorField?

[BlakeTerhune]

Is there some new requirement that you only need to null out fields that are not null? It's okay if CalculateField nulls an already null field value; you don't need to query them out. If you want to do a query first, either use Select Layer By Attribute first or (what I would recommend) is using the UpdateCursor method mentioned by @curtvprice.

[curtvprice]

This can be done in Python (either script, command line, Notebook, or using the Calculate Value tool in Model Builder),  with the arcpy.da.UpdateCursor method

The Calculate Field tool can only update one field at a time.

with arcpy.da.UpdateCursor(tbl, ["FLD1", "FLD2"]) as rows:
    for row in rows:
        row = (" ", " ") # or (None, None) (None and blank are not the same)
        rows.updateRow()

[JoeBorgione]

I’m with @curtvprice for using an update cursor. 

A couple thoughts to add though; a table with 70 empty fields seems like a boat anchor to me. What value do empty fields bring over deleting them altogether?  I also suggest using  <Null> value over ‘’ if you must keep them. 

[curtvprice]

Hi @JoeBorgione - just a digression about "fat" tables with many fields - with shapefiles and (gasp) coverages, empty string fields take up a lot of space and slow things down, as the physical space (eg a 255 byte string field) is used whether there are data in the field or not. However, in the world of geodatabases (which live in highly indexed data structures behind the scenes) empty fields and short string fields do not actually take up space. Also shapefiles don't store null, just ' ' or 0 for string fields.
Back in the day (1980s, 1990s) we would make tables as skinny as possible by normalizing data (lookup tables) and joins to speed things up - not so much a concern with geodatabases. In geodatabase design you are often better off with fewer, indexed, "fat" tables to keep schemae as simple as possible.

[JoeBorgione]

@curtvprice  Excellent points. I’ve been working on a couple large data migrations lately from some old databases (Oracle 7) and have encountered whole tables where multiple complete fields are empty. I just don’t see the value in bringing those fields over to a new and modern database (EGDB / SQL server back end). Call me old fashioned and admittedly I am but Null values will always be my preference over empty’.  Then again:

[BlakeTerhune]

Another option would be to copy the feature class to scratch or memory workspace with only the fields you want to keep their values, truncate the original table, then append back the records and values to keep; everything else will be nulled out.