Although I have seen this in other builds including 4.2, currently we are running 5.2.1.0. Our database is SQL 2012. We have the code exposed using WCF TCP protocol hosted as a Windows service. The error doesn't happen often but it has happened maybe 6 times in the last year. Some code that uses QuerySpec (self service) starts throwing these errors. It is like the code is looking at a different database or something. We have to restart the windows service to clear up the errors.

The code that throws the errors is located in specific entity classes, in the user code region.

The error handler that catches this is able to connect to the database and lookup the user login name, so the database is there and can be connected to.

It is a pretty random error, just wondering if you have seen anything like this or have any suggestions. Stack shown below, where "Database.TableName.FieldName" is different and corresponds to a specific field in the query.

The multi-part identifier "Database.TableName.FieldName" could not be bound. Exception Attributes: Message: The multi-part identifier "Database.TableName.FieldName" could not be bound. Exception type: System.Data.SqlClient.SqlException Source: .Net SqlClient Data Provider Thrown by code in method: OnError Thrown by code in class: SqlConnection Stack Trace: Method: System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action1 wrapCloseInAction) Method: System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose) Method: System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady) Method: System.Data.SqlClient.SqlDataReader.TryConsumeMetaData() Method: System.Data.SqlClient.SqlDataReader.get_MetaData() Method: System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString, Boolean isInternal, Boolean forDescribeParameterEncryption) Method: System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task& task, Boolean asyncWrite, Boolean inRetry, SqlDataReader ds, Boolean describeParameterEncryptionRequest) Method: System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, TaskCompletionSource1 completion, Int32 timeout, Task& task, Boolean& usedCache, Boolean asyncWrite, Boolean inRetry) Method: System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method) Method: System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method) Method: SD.LLBLGen.Pro.ORMSupportClasses.RetrievalQuery.Execute(CommandBehavior behavior)

The code that throws the errors is located in specific entity classes, in the user code region

Could you please a sample of this custom code?

I had forgotten that when the error is thrown, the referenced field that cannot be bound to isn't even in the current query. Here is the code that throws the latest error. Previous errors were similar, but in different programs.

Just thinking out loud, it doesn't make any sense to me. Previously I said it was like the database wasn't found, but actually it is more like trying to execute some code from a different method or something (the partial method shown is called by another main method, which does have a query with the field that could not be bound).

The code is a typical pattern I use. Declare a new query factory, setup the predicate expression and execute a query using TypedListDAO.

public static List<FeeTermDto> GetFeeTerms(int feeagreementId)
{
    var qf = new QueryFactory();
    var p = new PredicateExpression(FeeAgreementFields.FeeAgreementId == feeagreementId);
    var feeTerms = new List<FeeTermDto>();

            var qfc = qf.Create()
                .From(
                    qf.FeeAgreement
                        .InnerJoin(qf.FeeTerm).On(FeeAgreementFields.FeeAgreementId == FeeTermFields.FeeAgreementId)
                        .InnerJoin(qf.ContingentFeeTerm).On(FeeTermFields.FeeTermId == ContingentFeeTermFields.FeeTermId)
                )
                .Select(() => new
                {
                    FeeTermId = FeeTermFields.FeeTermId.ToValue<int>(),
                    FeeAgreementId = FeeTermFields.FeeAgreementId.ToValue<int>(),
                        FeeTermTypeId = FeeTermFields.FeeTermTypeId.ToValue<int?>(),
                    PassThru = FeeTermFields.PassThru.ToValue<bool>(),
                    CoCounsel = FeeTermFields.CoCounsel.ToValue<bool>(),
                    CoCounselPercent = FeeTermFields.CoCounselPercent.ToValue<decimal>(),
                    CoCounselCap = FeeTermFields.CoCounselCap.ToValue<decimal>(),
                    BillingNotes = FeeTermFields.BillingNotes.ToValue<string>(),
                    CreatedByUserId = FeeTermFields.CreatedByUserId.ToValue<int>(),
                    CreatedDate = FeeTermFields.CreatedDate.ToValue<DateTime>(),
                    LastModifiedByUserId = FeeTermFields.LastModifiedByUserId.ToValue<int>(),
                    LastModifiedDate = FeeTermFields.LastModifiedDate.ToValue<DateTime>(),
                    Version = FeeTermFields.Version.ToValue<byte[]>(),
                    ContingentFeeTermId = ContingentFeeTermFields.ContingentFeeTermId.ToValue<int>(),
                    StartingValueId = ContingentFeeTermFields.StartingValueId.ToValue<int?>(),
                    EndingValueId = ContingentFeeTermFields.EndingValueId.ToValue<int?>()
                    CalculateTiersById = ContingentFeeTermFields.CalculateTiersById.ToValue<int>()
                }).Where(p);

            var contingentFeeTerms = new TypedListDAO().FetchQuery(qfc);

Looks OK to me, no threading/shared object usage to see, but your problem does sound like a threading issue.

Do you have changes made to e.g. connection management in the selfservicing code? The new TypedListDAO will create a new connection instance and run the query on that one, by default, and all consuming code of the resultset will be created from there, it's not re-used across threads.

No changes to the connection management.

Previously I had refactored some shared code in a couple of places and the refactor process wants to pass the query factory object around instead of creating a new one. If I remember, I read in the docs it was OK to re-use the query factory object, but no need to as the object creation is very fast. Does this look OK or do you think it could be a problem?

// run some queries
var qf = new QueryFactory();
var qry = qf.Create().....

// call some shared function, passing in existing query factory
// note the calculation is called from other places in the code and each passes in their own query factory
var calcResult = CommonCalculationObject.Calculate(qf);

// run some other queries
var qry2 = qf.Create().....

Looks ok to me. A static/shared function isn't the problem, as the data passed in is unique per thread (caller). These things only occur if there's shared state among threads/requests (which can run on a different thread). this isn't that easy on selfservicing, hence my question regarding whether code was refactored

To be honest I don't know what it could be that is causing this. I assume you're not using catalog/schema name overwriting?

I can't get to it right now, but I think I need to hook up some automated testing tools and try to replicate the problem.

You can go ahead and close the ticket if you want. Thanks again for the help.