Frank,

The BLG does an OK job of getting you started for business rules. It looks at the database schema and builds (some) rules based on what it sees. As you can see, it does not build a business rule for alternate keys. So you need to build these yourself. This is, however, not difficult. You need to:

1.) Create a stored procedure that returns the record that equals the key value you are attempting to save. Note, you will also need to pass a PK value so that when you are saving an existing record, you don't return the existing record. (When you are adding a new record you pass zero as this parameter and when you are saving an existing record you pass its PK.)
2.) Add a method in the business object code to call this stored procedure.
3.) Add code in your method that validates this column to include this check.

Your sp would look something like this:

/*  This procedure will return the country passed as parameter if the passed countryID parameter is zero  */
CREATE PROCEDURE [dbo].[CountrySelectByName]
(
	@Name char(40), @CountryID int
)
AS
	SET NOCOUNT ON;
	SELECT *
	FROM [dbo].[Country]
	WHERE 
		([CountryName] = @Name) and ([CountryID] <> @CountryID)
		

You could also code this to just return a count as opposed to sending back the entity as well, but you get the point.

Now just build your methods and rule code accordingly and your object has a rule to check for dupes.

HTH

>Hi,
>
>I want to disallow duplicate values from being entered. For example, I have a table of Countries where I do not want duplicate country names. I have set a UNIQUE constraint on the Country Name field in SQL Server, but the UI did not automatically pick this up. Should it?
>
>I then found some sample code in the Developer's Guide which does a dynamic SQL select to check for duplicates and this code is called as one of the business rules. My thinking is that if the timing is perfect, two people could run this code at the exact same time and the rule will not detect duplicates so the users will then get an error from SQL Server. I know this is highly unlikely, but it is possible.
>
>What is the best way to handle this?