If you're binding directly to the DataTable itself in whatever ItemsControl you're using, then rasing PropertyChanged on your ViewModel probably isn't getting recognized as changing the bound entity. Fundamentally, DataTable and the child entities don't support INotifyPropertyChanged and INotifyCollectionChanged, so they are not acting the way the data binding would like them to be.
To "Hit it with a hammer" you could try Rasing PropertyChanged with String.Empty for the parameter, which means "re-bind everything", but that can be quite expensive, depending on the page.
Some better options:
You could try implementing INotifyCollectionChanged in the typed DataTable types, but this might be quite a pain depending on how complex your schema is.
A "more recommended" approach would be to look at going to something like Entity Framework to do your ORM work. You could then get back real entities that could implement INotifyPropertyChanged properly.
Another acceptable approach would be to use something like AutoMapper to convert the data table rows into real ViewModel entities and ObservableCollection<>s. You, of course, need to map them back to your data storage entities (be those data rows or whatever) at the end of the day, but there are plenty of tools to make this easier.
Generally speaking, not many people would recommend using DataTables (strongly typed or otherwise) for moving data around inside your application anymore. Too many of the useful tools (e.g. Validation, ORM, Data Binding) require you to have a real object that you can implement your own interfaces on (e.g. INotifyPropertyChanged). If you are working on a relatively "Green Field" application, I would spend a little time with Entity Framework or LINQ-to-SQL (which appears to be deprecated in favor of EF) and see if you can use one of these (or another ORM like NHibernate) to fill your needs.