Locked mdc files long after connections should be released

[Constellation Rob]

We operate Cognos 8.2 with a number of Powercube data sources. The cubes are refreshed daily and the mdc files copied away to suitably named folders, e.g. "Monday", "Tuesday", etc.  Cubeswap is used to point the data sources at the appropriate folders. Naturally, following the swap, any locks on the previous day's mdc files are gradually released ready for the following week.

This generally works well - however, we have a puzzling problem whereby a single mdc file remains locked all week. It's always the same file and in the same folder (Wednesday). We are at a loss to understand the reason for this.  All other cubes are fine, as is the same cube on other days. To free the lock we have to reboot the server.

Clearly something is happening on a particular day to prevent a particular connection from properly closing, thus retaining the lock on the file. Has anyone else encountered a similar problem? All suggestions are welcome as to what might be causing this, as we're baffled. Thanks.

[RobsWalker68]

Hi,

Do you have anti-virus software running?  I have encountered situtations like this where the various transformer directories haven't been excluded from the anti-virus scope.  Something to check out maybe.

Rgds

Rob

[cognostechie]

You do not have to reboot the server. Just bounce the cognos service.

[MFGF]

One other thought - have any of your users scheduled a report to run multiple times every Wednesday?  It's possible that something like this coule be maintaining the data source connection.

Regards,

MF.

[Rutulian]

Hi Rob,

There's a sysinternals tool that will help you inspect file handles which might get you a bit further: http://technet.microsoft.com/en-gb/sysinternals/bb896655

I haven't used this particular one myself, but Sysinternals utilities are normally jawdroppingly comprehensive.  This will let you check if it's Cognos or some other process (eg AV or Transformer) that's locking your .mdc file, and force-clear the lock if it seems like a good idea.  I'd be inclined to be pretty careful about this, the service-bounce approach sounds like the best workaround until you snag a root cause.

Regards,
Alexis