NO, this code is notbeing run in a background worker or service. 

It is directly executed as the result of a button click on the UI.

Here is a complete sample of the code. 

    StoredProcQuery queryGetEntityLock = VisiTrackEntityManager.Instance.GetEntityLockQuery ( pObjectId );

    // Reduntant just to make sure..  Should default to the EM upon which it was created.

    queryGetEntityLock.EntityManager = VisiTrackEntityManager.Instance;

    // Explicitly making sure that we are "DataSourceOnly"

    // Why would a server stored procedure ever do otherwise???  How could it?

    queryGetEntityLock.QueryStrategy = new QueryStrategy(FetchStrategy.DataSourceOnly, MergeStrategy.OverwriteChanges);

    // Just making sure..  Yep, of course it is...

    FPLogger.WriteTrace("Fetch Strategy:" + queryGetEntityLock.QueryStrategy.FetchStrategy, LogEventType.Database);

    IEnumerable enumLock = null;

    try

    {

        // Execute the stored procedure

        enumLock = queryGetEntityLock.Execute();

    }

    catch (Exception ex)

    {

        // Here we get an error!

        // “FetchStrategy for StoredProcQuery must be DatasourceOnly.”

        FPLogger.WriteException(ex, LogEventType.Database);

    }

Questions:

1)  Why would a Stored Procedure ever need to be told “DataSourceOnly” ?

2)  Why would the :Execute() not obey an explicit setting of the .FetchStrategy to “DataSourceOnly”

3)  As you can see we are neither accessing nor changing any Entity Manager data or settings.  

We are only executing a stored procedure in the current thread.  

How could this be affected by background thread operations?

        IEnumerable enumLock = queryGetEntityLock.With ( QueryStrategy.DataSourceOnly ).Execute ();