DataStoreException: The handle is invalid.

[Scott]

Ok, what's going on... perhaps I'm using OpenAccess incorrectly. Am I supposed to only have one domain model and put all tables in that one model.... that's currently not the way I'm doing it... I'm putting every logical entity into it's own model... I've already run into an issue with the connection name getting goofed up and/or confused that I resolved by giving every model it's very own connection in the web.config file... a bit annoying but ok... i can live with it i suppose....

Now I'm getting this other very odd error... what am I doing incorrectly? See error details below, and code snippet it came from.... By the way.. this code was working... but I've added some more code elsewhere since writing this code... and now it doesn't work... it's like OpenAccess is reusing stuff across the application that it doesn't need to be.... or needs to be reset upon each use??

***** Code snippet *******
public IList<Customer> GetCustomers(Guid userId)
{
    IList<Customer> customers = null;
    using (UserAdminContext dbContext = new UserAdminContext("UserAdminConnection"))
    {
        var query = from c in dbContext.Customers
                  from a in c.UserCustomerAssociations
                  where a.UserId == userId
                  select new Customer() { CustomerNumber = c.CustomerNumber, CompanyName = c.CompanyName, Identifier = c.Identifier };
                
                customers = query.ToList<Customer>();
    }
    return customers;
}

****** Error ******
Error executing query: Telerik.OpenAccess.RT.sql.SQLException: A transport-level error has occurred when receiving results from the server. (provider: Shared Memory Provider, error: 0 - The handle is invalid.)
   at Telerik.OpenAccess.RT.Adonet2Generic.Impl.PreparedStatementImp.executeQuery()
   at OpenAccessRuntime.Relational.conn.PooledPreparedStatement.executeQuery()
   at OpenAccessRuntime.Relational.fetch.FetchResultImp.Execute()
SQL:
SELECT a.[CustomerNumber] AS COL1, a.[CompanyName] AS COL2, a.[Identifier] AS COL3 FROM [Customer] a JOIN [UserCustomerAssociation] AS b ON (a.[CustomerId] = b.[CustomerId]) WHERE b.[UserId] = ?                                        Telerik.OpenAccess.RT.sql.SQLException: A transport-level error has occurred when receiving results from the server. (provider: Shared Memory Provider, error: 0 - The handle is invalid.)
   at Telerik.OpenAccess.RT.Adonet2Generic.Impl.PreparedStatementImp.executeQuery()
   at OpenAccessRuntime.Relational.conn.PooledPreparedStatement.executeQuery()
   at OpenAccessRuntime.Relational.fetch.FetchResultImp.Execute()

**** Inner Exception *****
A transport-level error has occurred when receiving results from the server. (provider: Shared Memory Provider, error: 0 - The handle is invalid.)

[Thomas]

Hello Scott,

using a new context for every domain entity type is certainly not the way OpenAccess prefers, although it is legal and should be working. Our main idea is that the domain model should reflect the classes you need to express the entire schema logically, and that the context is the main entry point that gives you access to all the data. Your approach is like dividing the logically connected database instances into atoms. The side effect is, that many more connections and in-memory structures are needed to get the same domain model handled. My assumption is that your SqlClient-level problems are created by this: to many connection opened to the same database. You did rename the connection strings, but they all point to the same database, a situation that is also not preferred by the ADO driver.

Why did you choose to split the model into many models? My advice would be not to do that but to use one model to express your database needs.

All the best,
Thomas
the Telerik team

[Scott]

Using an ORM is new for us... in the past we have done all of the data access ourselves with custom written classes. We used ADO.NET's connection pooling so re-using the same connection string multiple places was never an issue for us.

Why did we use multiple domain models?? The answer is easy... using one domain model for the entire database seems like it would not scale very well at all... not to mention it would become darn near impossible to maintain in the long-term. As the database grew, so too would the domain model.... it makes entirely more sense to break it down into smaller models to overcome this....

Since OpenAccess appears to have an issue with this... we have moved over to one domain model per database... and the problem seems to have gone away (hopefully permanently) On a side note.. we also made sure to clear the cache and restart any previously running web servers... to be certain we were starting fresh...

We may have to look at other solutions if the domain model gets too big and thus un-maintainable....

We did however see something in the documentation about aggregating metadatasource classes or something to that nature that looked like it allowed breaking the model down, and then aggregating it into one model programmatically? That may be an option for the domain model getting too big... but for now we can resort to throwing everything into one model.

Long story short.... eventually if an application continues to grow in size and number of database tables grow with it... eventually it will make sense to break the model up, so any direction you can give to that would be appreciated... Thanks in advance!

[Zoran]

Hello,

 Actually we have planned into the direction of allowing split between the domain models, either in different files, or one file but multiple layers, but it is so far in our long term goals so I can't promise you time-frame when such feature will be implemented. However, the aggregate metadata source is a solution that is available currently and you can use it to achieve the same goal at the moment. What you should do is to have two models in two rlinq files, and then initialize a context in the following fashion:

XmlMetadataSource firstSource = XmlMetadataSource.FromUrl(@"c:\FirstRlinqFile.rlinq");
XmlMetadataSource secondSource = XmlMetadataSource.FromUrl(@"c:\SecondRlinqFile.rlinq");

AggregateMetadataSource aggregateMetadataSource = new AggregateMetadataSource(
   firstSource , secondSource);

EntitiesModel context = new EntitiesModel(aggregateMetadataSource );

All the best,
Zoran
the Telerik team