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