>>>I am using INDEXSEEK in the stored proc. of my DB to check on the validity of the primary key that I am about to assign. The call is as follows:
>>>
>>> IF INDEXSEEK(m.cKey, .f., m.cTable, "PKey")
>>>
>>>Works great on my machine, whether from within VFP6 or via the EXE file of the app. On site, however, whenever it is invoked, the error message "Cannot find file INDEXSEEK.PRG" (or words to that effect) pops up. I had the client check the \WINDOWS\SYSTEM folder--the VFP6 DLL's are in place. Any ideas out there as to what might be going on??
>>>
>>>TIA.
>>>John
>>
>>
>>You should not have to check the PK. By definition, it is unique for every record and is NOT user generated. Define a field as the PK and have a stored procedure generate the PK using the default value defined in the DBC. If you need more information, see the article on my web site.
>
>Craig:
>
>Thanks for kicking in here.
>
>The PK is being generated by my program; however, since the app will be on a heavily-trafficked network, and since you-know-what happens, I just want to be double safe and check it before actually putting it into place. I will certainly read your article and appreciate you making it available. I still can't figure out, however, why VFP's new function, tailor-made for this type of situation, doesn't work as advertised . . . .
>
>Thanks, again, for the words of advice.
>
>John

You can't move the record pointer inside an SP, but INDEXSEEK isn't supposed to move the record pointer. There must be something else involved. However, if you generate your PK properly, you won't get duplicates.