To fake or not to fake

To fake , or not to fake that is the problem now. This is something I just realized after writting around two hundred tests that rely on completely faked dependencies, and around seventy which do not fake nothing. Those non-faking unit tests are those written for the lowest layer of the applicattion, the data access code which tests how my data retrieval code works with a real database with only the data faked. Those tests sometime rely on each other since sometimes one stored procedure or view is used by multiple different sources. And if I change one multiple tests will fall indicating to me or my team where we need to apply out changes also.
But on a faked enviroment, where all dependencies are faked if we change the logic in one dependency and write tests that pass for it we must manually go and look through the code and to find all the places where that dependency is used in order to update it to the newest state of the application. Why? If I didn't change the structure of the dependency or the type of results it returns the tests that use a fake of the dependency will pass since those logic changes will not automatically propagate to those fakes (mocks or stubs it is irrelevant which in this case).
No that is why I push for functional and acceptance tests in order to test the complete stack from ground up without mocking, but still those tests are often left aside since people who have written unit tests have decided that they are unnecessary duplication or effort, or worse botch them in such a was that those tests do not return any meaningful data to us.