There are lots of potential solutions to this problem.
For strings: I use validators that use reflection to get the maximum lengths of the strings from the column attributes on the LINQ entity properties and check these. Alternatively you could handle the error that occurs on insert if the column would be truncated.
For dates: You could do a sanity check on the date (i.e., must be after some reasonable date) that must be entered by the user or for dates that can be automated, use a database generated default and mark the property as autogenerated and read-only in the designer. Don't put these dates on the form so they aren't set in the entity when you post the page. This works for "Create Date", etc. For modification dates, do something similar, but have the value generated by an update trigger instead of the default on update.
For booleans (which default to false): validate the value provider has an attempted value for the field in addition to doing validation on the entity itself. Alternatively, you could make the column nullable and check that it's not null. Both are compromises, but the latter makes the data model fit the validation framework so I prefer the former.