>The key that I am using was a primary key when it throws the error. In SQL Server it is an identity field. Since it is a primary key, it is made unique by default. When I take off the primary key from the SQL Server field, it saves fine. Now I do the exact same thing with my other tables without problems thus far.
>
>What I understand you are saying is to remove the primary key designation from this field, and allow the business object to generate the primary key? I would assume you mean to use the RetrieveAutoIncrementPK = true, which is what I am currently doing? So when the procedure inserts it will insert the value into this field without issue or conflict with SQL Server?
>
>Am I understanding this correctly?
>
>Thanks...That makes since.


I read your other post and hope that solves the issue. But for clarity, I wanted to expand on what I was saying here. I was not suggesting that you turn of Primary Key for your primary key field in the database. I was asking about how the value was generated. In SQL Server you can set a default value of NewID() I think is what it is called. In the business object you can set the default value also. I was wondering if in the case of this table the two were bumping heads. I leave my PK in the database set as a Primary Key but I do not set the default value in the database. I have been setting the default value in the business object.

You really do need your database to enforce its rules and protect the data besides the application doing that. But it can protect the values in the primary key field without creating it. Then it is up to the application to create it.
Let me know if that makes sense
Tim