Hi Terry
I pretty much had the function set up as you described, the problem arises when you type in a new order number, the seek function seems to find it already in the table, thus, it triggers the error method because I don't want duplicate order numbers. It seems that the order number is part of the table, even though I haven't written anything to disk. I thought this was occurring because of the control source for the text box being a field. I hope I have missed something basic.

Carmen

>>When you use the table fields as the control source, it seems more circuitous to check for existing order numbers before saving, etc.
>
>You could write a process for the LostFocus of the textbox that receives the prospective "new" order number. The lost focus could verify and then protect (if neceesary) that particular client's use of the order number for the next new order.
>
>You could make it stateless. Let's say an existing order number is entered. A stateless system would pull the existing order into the clients form to be edited. A new order number would populate the form with blanks.
>
>>Then if the user aborts the action, you have to unwind the whole process. Is there something basic that I am missing?
>
>Theres a lot to be said for seek, and index seek and hard binding table data to the client rather than SELECT INTO's and TableUpdate/Recvert. Its more painful, but the end result can be quick and cleaner. REPLACE and SEEK (etc) are old, but they're fast and solid - no guesswork for macro engines (TableUpdate (etc))
>to fail around or necessitate complicate roll back (macros?) procedures.
>
>BOL