>I agree with Naomi
>Not using the index is the best idea.
>That said, I've solved the problem in other cases by making sure that the .prg containing the UDF is in the same folder as the .dbf.
>
>
>
>
>I have an asp.net application that uses some vfp9 data tables. These tables are updated by an vfp9 application and the asp.net application. All is moving along just fine. Today however I hit something that is new to me and I hope that someone can lend some guidance.
>
>While in asp.net , I connect to to the vfp tables with the vfpoledb data provider. It appears as this driver is actually a mini version of vfp since I am able to use functions like ctod(myDate) and upper(myText) in my sql statements. However, today I attempted to update a vfp data table via ado.net that has an odd ball index tag that was built in the vfp application. Within the vfp aplication I build an index tag using the statement: index on XCTOD(date) tag c_date. XCTOD is a stored procedure that just changes ctod() a little. When the asp.net application updates the data table, that has this index, I get the error: error building key for index c_date. I guess the asp.net application via the vfpoledb driver really does not know anything about the XCTOD stored procedure.
>
>any thoughts would be appreciated.
>Neil Gorin

Very cleaver. Should I compile the prg also and place both in the directory.