Right you are. It's probably the limited way we are using it that has kept us clear of problems, as we have not had stability problems with it even though we have not explicitly been turning off backgroundfetch in the connection string.

I thought I remember reading somewhere a few years ago that the latest version of the ODBC driver (the latest now being several years old) is more thread-safe than older versions... i.e., that the backgroundfetch parameter is not as dangerous as it was at one time. But now I cannot find that reference!

>According to mskb#269881 VFP ODBC driver should be used with backgroundfetch=no to avoid a bunch of problems.
>
>>Some of the answers I have found are so obtuse that I'll post them here to save others the pain... assuming there is anybody left in the world who is still using the VFP ODBC driver.
>>
>>This is what I've found:
>>
>>If you use "backgroundfetch=no" in your connection string, those TMP files do not get created. If you leave backgroundfetch out of the string, the default is "yes", and they will get created.
>>
>>Furthermore, the setting of backgroundfetch apparently also determines the security identity of the table accessor. That is, if backgroundfetch=no, then the accessor is the server's IUSR identity. But if backgroundfetch is ON, then the accessor is the server's IWAM identity.
>>
>>The gotcha here is that (depending on your initial security settings) you might need to go back and reset security on your tables if you change the value of backgroundfetch. Otherwise IIS will crap out with an ODBC error.