OpenAccess Error with Multiple Custom Modules

Hello,

We have 3 custom modules using OpenAccess that are *not* based on Content. We have fairly simple model classes, with provider classes that are based on the OpenAccessContext class. This was taken partially from Josh Morales' forum post on Intra-site modules.

Not sure if it's a factor here, but we deviated from Josh's example by placing the guts of the module code (provider, model, manager) in a separate assembly, but used Josh's method of adding admin pages and registering the module as part of the web application code.

This all works fine for each module individually. We can access the admin page(s), add/edit items, etc. However, if we try to access the administrative page of either of the other two modules, we get the following error:

Hi John,

The scenario you describe seems fine. However, I am concerning about the providers ModuleName, which should be unique for each provider. If you are overriding this property in the OpenAccess data provider, make sure that is different for each provider. This property (IOpenAccessMetadataProvider.ModuleName) is used to identify the provider, and if you have more than one provider with the same module name, only the first one will register its mappings.
If this is not the case, can you please send us the implementation of your custom modules so we could investigate it locally?

Kind regards,
Vlad
the Telerik team

Was there a resolution to this?  I'm having the same exact problem.  I can switch between the two modules, but only one will work at a time.

I actually did not have this problem when developing against the local DB.  I am however, experiencing on the dev server.

Please advise.

Thank you.

Hello Amir,

What is the difference between the dev server and local databases? Are the projects running different versions of Sitefinity?

Regards,
Radoslav Georgiev
the Telerik team

Local version is SQLEXPRESS in Win 7. Dev server is Win/SQL 2008.   Local version was a fresh 4.2 install, where as the server has been updated through each release since 4.0.

they're both running 4.2.  FYI, I have also opened up a ticket: 454703.  Thanks.

Apologies for the late response:

This approach did not work for us (implementing IOpenAccessMetadataProvider with unique module names). I think our "provider" is missing something else, or Sitefinity only cares about that interface for Content-based modules - which ours is NOT.

We have temporarily fixed this by adding separate connection strings to DataConfig.config for each module. Each of these connection strings has a unique "data source=" value, which are aliases that point to the same db as the main "Sitefinity" connection string. This is sloppy (in my opinion), but it works: SF must be caching based (at least in part) on the "data source=" value.

Hope this helps someone else trying to build non-Content-based custom modules. If anyone has a cleaner, more "official" method, we'd love to hear it!

Regards,
John

Hi John,

We are currently investigating the issue and will follow up when we have more result.

All the best,
Radoslav Georgiev
the Telerik team

@John, found your post as we are having the same issue, when setting up the aliases was your database a SQL Server specific database or an attached one?

@Sitefinity - has this been resolved in an official capacity, seems odd that you cant share a connection string (i appreciate there are other things going on here), we are currently on 4.2.1733 but will be upgrading before release, which is 10 days away.

Regards,

Rob

Hi Roberto,

Hi John,

Thanks for the response, i will dig out the database as it is an embedded one and add it plain old SQL and setup the aliases, that will atleast get this moving, its a weird one, we have two modules, and we found out today that this is happening, by complete fluke.  Funny thing is the resources must still be active for a while becuase one of the modules disposes of the context when it exits the page so were not even using the connection when the other one went pop.

Knew i should have stuck to Linq :)

Rob

Any news on this?

We're having the same problem with 2 custom modules we created. Both module work fine when installed individually, but one will not work when both are installed. ModuleName is not the issue.Adding a new connection string does seem to solve the problem...

Although using an alias for the connection string does work on our development computer, I don't think we will be able to do this with the hosting...

Hello,

have the same issues here. Is there already a solution? Other than the different connection strings (alias) work-around?

Kind regards,

bob

Hi Bob,

We havn't found one, well apart from not using OpenAccess and using something like LINQ.

Sorry that's not much help.

Rob