Assuming this is a multi-user system
I don't know that it's inherently good or bad. If there's no reason to centralize the data access from a business standpoint, having a client app talk directly to the database isn't a problem. You'll want to build a decent data access layer regardless of whether it's done in the client or through a centralized data access server.
You mentioned multi-user, depending on the data and usage you may have transactional issues to deal with which might be an argument for centralizing things, but they can be handled from multiple clients as well.
Pretty common requirement for business applications, so GOOD.
Don't try to use MS Access as the back-end for a multi-user app, though. That would be BAD.
For security reasons, I prefer to access a database through a web service. That way, you don't have to have the database userid/password in the client application.
I would recommend using stored procedures, since inline database coding is not safe (eg. sql injection) and if there are changes you need to make to the stored procedure in the future it is a good possibility that you will not have to roll out an updated application (depends on how it is coded).
If you are worry about some type of race conditions between the users then you could use Commit/Rollback Transactions.