Hi DV FX,

We did try an implementation with Apollo's module but we have change the site structure to support one language per portal so that we can use default modules. In discussion with Ifinity we also have had some other features added so that we just implemented a custom provider for the Ifinity software. The problem with Apollo module is that the tabid is retrieved and the locale cannot be passed to the core. So technically we have concluded that the Apollo module in conjunction with the Infinity sitemap is not easily done and might be too risky since the core framework does not support it very well. Second problem is that the Apollo retrieves a tab from his own table and every tab page would require a database lookup for the correct translation. This would be a tremendous overhead on database calls. For those reasons we did not continue further development on this module and separated the site into multiple portals. This also helped us in getting better seo menu support since Snapsis menu did not support automatic inclusion of the admin and host tab...so we finally decided to stick to the default dnn setup and use 1 language per portal. In Europe only the Belgiums and the Swiss and Luxembourg are bilingual. But since those people are so little in amount it is not beneficial to maintain separate portals for them. They need to adapt themselfs to a portal with the language that suites them. it is too expensive to sell anything to them if we would do that in their specific language.

It is simply a matter that US people are not used to multi-lingual situation and I guess that from this basis a US founded software base is by standard not well designed for multi-lingual situations...you see that in Dynamics of MS as well. They simply have no clue what multi-lingual situations are about.

The investigation for this matter costed us a couple of weeks, hope it will help you in deciding what to do.

J.

Tony,

Did you ever figure out an answer to your question?  I am in the same spot.  I have the file created but get the same error message that you do.  And I can't figure out how, from the previous messages, how to make this work.

Thanks.

Eileen

We are urgently looking for a reporting module for our web based solution. We have a number of clients that run a shared application on our central web server. Each client has its own database on the server. There is only have one instance of DotNetNuke installed on the server. The connection string and database name for the user that is currently logged in are retrieved from a database table. Does your reporting solution allow one to dynamically change the connection string at runtime? In other words, we develop a common (shared) report using our sample database and then deploy the report to the web server. When the client runs the report, it 'refreshes' the report by connecting to the relevant client's database (done by dynamically passing the right connection string/database name to the reporting module). Possible?

Regards

Jenifer

Support executive