The reason you are having trouble is that the table design is
wrong. You need to create a child table containing the value for
a producID, a CityID and the quantity.

Imagine the rework of your query when you add that 11th city

Your products table needs only to contain ProductID,
ProductName, ProductSupplier, ProductLeadTime... all the things
that are attributes of the product. Your Child table needs to
contain ProductID, CityID and QtyOnHand for that city. You
probably want to make a cities table as well with CityID,
CityName, CityState, such that you save a lot of typing by
picking the city from a combobox.

Then your summing up the quantities becomes a simple, easy to
build and easy to maintain summary query.

To answer your question, no you would not use DCount().  You would simply enter
an expression in a new query column of...

Total: reg0 + reg1 + reg2 + reg3 + reg4

If any if those might be null then you would need...

Total: Nz(reg0) + Nz(reg1) + Nz(reg2) + Nz(reg3) + Nz(reg4)

However; I should point out that your table structure is incorrect.  It's a
spreadsheet construct rather than a database construct.  A proper database
design would yield a table like...

Productid   ProductName   Qty   Reg
someID     "someName"      1      0
someID     "someName"      3      1
someID     "someName"      7      2
someID     "someName"      2      3

...and then you would be able to sum a *column* which is what aggregate queries
do well.  Any time you find yourself needing to aggregate across a *row* then
there is a good chance that you have a design problem.