> he said my database designed was bad, and it won't work with SQLServer database.

I'm not sure it's accurate to say, "it won't work with SQL Server"

>The main issue with my design is I always keep calculated fields, which store how many stock onhand in store, warehouses, etc, while he said I shouldn't have any calculated fields, thus avoid record locking, if I want the figure I should recalculate them from the invoices. We have argued about this issue for a long time and I don't know who is right. I can't imaging how I can recalculate 100.000 items before printing a stock onhand report.

Sounds like your associate is a purist and doesn't live in the real world. In fact, I think there are many commercial applications that are designed in the same way for the particular example you describe. To deal with record locking, one should use transactions so that no data is saved to any table unless all updates in the transaction are successful. While you certainly could use UDFs to calcuate on hand values on the fly (with appropriate indexes to aid with performance), in this case I'd probably go with your design.