You could do it either way. There are other factors to consider as well

1. Will this validation rule/ruleset probably need to be used by other stored procedures? If so, make it a stored proc to avoid double maintenance.
2. If not, how are the skills of the programmer(s) that would be coding this routine? If their VFP/C#/etc. skills are far better than their T-SQL, go for a business object.
[these are just the first two that I could think of in the limited time I've got...]

If this list (and addenda added by others) doesn't help the choice, my personal preference is to use a shared DLL for this. If it's a validation routine that does a lot of data-munging, I prefer VFP for that.
The reason I prefer the DLL, is that I would much rather not have anything that shouldn't get to the database get to it in any way. Simple example: required fields - if they aren't given, the process shouldn't make it to the database.
Others have different preferences and their reasons for having them, so you'll need to consider what your preferences are from the answers received.


>I am working on a Foxpro 8 application that will use data from MS SQL 2000.
>
>Another team is working with C# and Dot Net to build an Internet edit system for the data from my Foxpro application.
>
>We both want to use the same validation procedure.
>
>Would an SQL stored procedure be a good way to do this or would we be better of to write a DLL we can share.
>
>We will pass one record (or possible numerous) to validation and the validation will simply give us back a list of the errors from that record (or NONE means it is OK).
>
>Please give me your advice.