Before insert you could do a select on identity column for existing records. ie:
SQLExec(lnHandle,'select identitycol from myTable my where exists (select * from ##temptable tmp where my.f1=tmp.f1 and my.f2=tmp.f2 ...)','Existing')
But of course if fields are a lot coding this is cumbersome (if manually done:).
Cetin

>Cetin,
>Interesting idea. The problem is that I need to know what the PK is whether it's an existing or a new record. I need this for further processing in order to link related records.
>
>In the mean time I've made some (minor) progress with my SPROC. I just feel a bit clumsy coding in T-SQL ;-)
>
>>Daniel,
>>What about you still do it and create a temp table in SQL server, append to it, then use SQL server's 'insert/select'. I think it'd be faster then individual inserts.
>>In individual mode if there aren't too many fields you could create a unique constraint on those fields and simply do your inserts. If constratint fails, insert would fail and I don't think you need to do another check.
>>
>>Cetin
>>
>>>Cetin,
>>>Thanks for your answer.
>>>
>>>I forgot to mention that this import process occurs once per week. What basically happens is that each week about 30% percent of the payment instructions that we receive already exist in SQL Server. That's why I would like to simply pass each record and have SQL Server figure out what to do.
>>>
>>>If I do it on the client, then I have to send the data multiple times.
>>>
>>>>Daniel,
>>>>Without complexities of your design what I think :
>>>>Since you first parse in VFP what about doing unification on VFP side first. Once in a cursor/table say TableA :
>>>>
>>>>select * from TableA ;
>>>>union ;
>>>>select * from TableA ;
>>>>into cursor crsUnique nofilter
>>>>
>>>>Problem how would you send this to SQL server. I would create the table on SQL server, do a remote view, append to it and update. Or an ADO connection, add to recordset and updatebatch. Without BCP operations this sounds to be really slow.
>>>>
>>>>Cetin