>>The application reside on the network drive. And in no other part of the application this error occurs. So I can't see that the AV would cause this problem just in this specific point. And not always but quite often.
>>Thank you.
>>
>>>Is this on a local drive, or is this off a network share?
>>>Is there a possibility of an antivirus/antimalware interfering?
>>>
>>>I'd seen situations where some operations (like PACK) that may implicitly involve closing a file and immediately re-opening it would be interfered by an antivirus (e.g. the moment the file is closed, the antivirus opens it scan it -- the re-open operation ends up failing because the antivirus has the file opened exclusively).
>
>I vote for the network drive problem. We have got many problems when data was accessed from client PCs (Win7 or better) and Server was Win2008 or better, because when those SO combinations occurs, they start using SMB2/3 network protocols, that are optimized for network communications but in detriment of file locking, which tend to crash or fail.
>
>This could explain why it works on your PC, explicitly on your local drive.
>
>May be this reading can help to diagnose the problem:
>
>Re: Network Slow Query / Christof Wollenhaupt / 2014.12.18
>http://leafe.com/archives/msg/497230
>
>Data corruption when multiple users perform read and write operations to a shared file in the SMB2 environment
>https://support.microsoft.com/en-us/kb/2028965/en-us?wa=wsignin1.0
>
>Regards.-

First, thank you for the reference links; I will follow the links and read.

But as far as what you refer to as "network drive problem", when user call SQL Select and then tries to create index tags, the temp dbf and the cdx are created on the local drive. So I can't see how the network drive can influence this. The server where the application reside is Server 2003. But I am not sure the server is the problem; although anything is possible.