They would both go in the BO when validating through the CheckRulesOnCurrentRow event.  This was just to show that you may need to query uncommitted records as well in addition to those checked on the server to get 100% coverage.  This isn't always necessary, I just thought I would bring it to your attention.

Hi Trent

Thanks for you comment. The other solution is in the BO, this validation you mention, Where should it go? I think that in the Validating event of the control, but I'm not sure.

About localization, I'm working in two apps right now. One has localization for every part of it because is English/Spanish, but the other no, that's why I'm using only direct text for messages.

Kindest regards

Everything is possible, just keep trying...

One other thought to cap off this post, all of the server side query information from my posts and others is on target, but if you have the need to query within the BO (uncommitted reecord) as well, call a Select on the CurrentDataTable to get a count of records:

You can use this in conjunction with the server side query.  Do one and then the other to make sure that there are no dupes on either side of the committed records.

Also, Ivan's suggestions about the localization records are good...it is a much better way to keep up with your messages, etc.  Especially if you have the need to localize an app!

Glad you got it going, Juan!

Just for you to think about, have a look at the Localization & Message Editor. It might be a good idea to start creating your messages with it, and then use it in your application using the message keys, instead of entering an string directly. This way not only you get a centralized editor for all your messages, but are only 1 step away from having a multi-language application.

Have a great weekend.

Hi Ivan

You are right. Thanks

Before read this, I take a look to StrataFlix and found the same thing, I just adapt to my own BO and all works. Thanks for you help.

Kindest regards

Everything is possible, just keep trying...

Sorry Juan, I should have read it more carefully.

Have a look at your IF statement:

You are testing if it IS unique. You probably want to test if it is NOT unique.

Hi Ivan

I have one record, after add the first if I add a new one (with different number) fires the duplicate record message, also if I try to edit the same record.

Regards

Everything is possible, just keep trying...

Hi Juan.

Have a look at your table and see if you don't have already more than 1 record with the same NumeroGuia content.

Hi

I take a look to the samples provided for check for duplicates, but I can not find how to work on this.

In the same situation as Edjy, Where does should the Function IsUniqueCode should go.

I put this in the BO like this:

Public Function IsUniqueCode(ByVal IdRegistro As Integer, ByVal GuiaNumero As String) As Boolean

Dim cmd As New SqlCommand("SELECT COUNT(*) FROM GuiasEnvios WHERE IdGuia != @idGuia AND NumeroGuia = @numeroGuia")

'-- Create the parms. The reason you include the current record PK is so that the current record

' will be ignored and only look for other records with the same code value.

cmd.Parameters.AddWithValue("@idGuia", IdRegistro).SqlDbType = SqlDbType.Int

cmd.Parameters.AddWithValue("@numeroGuia", GuiaNumero).SqlDbType = SqlDbType.VarChar

'-- Execute and return the results

Return CType(Me.ExecuteScalar(cmd), Integer) = 0

End Function

 and call this way in the BO:

Private Sub GuiasEnviosBO_CheckRulesOnCurrentRow(ByVal e As MicroFour.StrataFrame.Business.CheckRulesEventArgs)

If IsUniqueCode(Me.IdGuia, Me.NumeroGuia) Then

Me.AddBrokenRule(GuiasEnviosBOFieldNames.NumeroGuia, "Duplicated")

End If

End Sub

But when I edit the record It says that the record value is duplicated, so it's not ignoring the current record. Also if I add a new one.

Hope you can point me in the rigth path.

Regards

Everything is possible, just keep trying...

Trent, Greg,

Thanks again for the good advice.

I will create the scalar method just to be on the safe side.  In this case, the payments will be created only by one user, just to make sure it is correct, and this is done once a year.  I just wanted to add a bit of code to make sure in case that person need to delete a payment record (which of course has not been paid) could do so and that the routine to do it should make sure not duplicate payments records be created. 

In this case the PaymentScheduleBO should always have filled with all the payments to validate, but the scalar method idea will add another safety and fool proof this process even more.

Edhy Rijo