>>So what steps do you take before the user chooses
>>save? What you're saying is that you could check
>>before the user leaves the textbox that contains
>>the primary key.
>
>I feel like there is a confussion of terms in this
>thread:
>
>a) Stored Procedures are, by definition, linked to
>the database.
>
>b) SP are meant to enforce data integrity, based
>upon certain business rules (that in theory would
>be set in design time, but in reality i've found
>they usually evolve with the application itself)
>
>c) If what you want is to asure the portability of
>your SPs, you should be thinking in writing them
>using as much SQL as you can, after all you're
>dealing with Relational Databases, not
>OO-Databases.
>
>d) When you talk about checking for any kind of
>data validation in your FORMS (ideally all your
>data should be filled from them, but remember
>about importing data, browsing data, connecting
>from other tools to your data, etc...), of course
>you can think of catching errors that makes your
>FORM more User Friendly (for example validation of
>a range of dates, not empty values, etc.). For
>implementing this you can use any OO code, but u
>can not call this code to be a SP.
>
>Just wanted to say what i think (now i fell better
>:))
>
>BYE

Thanks Jose, I was trying to realize the best way to trap a user that has entered dup data into a primary key field, and I think I got alot of good advise. Thanks.