Print Page | Close Window

Multiple Datasource Keys

Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce Classic
Forum Discription: For .NET 2.0
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=1084
Printed Date: 28-Apr-2025 at 6:05am


Topic: Multiple Datasource Keys
Posted By: *Calsy
Subject: Multiple Datasource Keys
Date Posted: 04-Feb-2009 at 10:00pm
Hi, I am looking at setting up a 2nd database connection (key) in our application. The situation will be that the application will connect to its main database over a standard SQL connection or over IIS and the second connection (key) will be hard coded so that it always connects to a database served on our web server (This is so we can send out information straight to the application). Can we have two database keys both running on different remoting (IIS) setups. I have created a 2nd key in the ORM and I have looked at the Ibconfig and there is only 1 remoting tag to be set.
 
Thanks in Advance


Replies:
Posted By: *Calsy
Date Posted: 08-Feb-2009 at 2:33pm
Hi Guys, Little help?

Posted By: kimj
Date Posted: 09-Feb-2009 at 10:38am
There is only one remoting tag in the config file, so yes, this does mean the client application can talk to only one BOS.  We've discussed opening this up for multiple app servers, but this feature hasn't bubbled to the top. 
 
You can, however, set the PersistenceServiceOption argument when you create a PersistenceManager.  This defaults to using whatever is specified in the config, but you can override it to specify that the particular PM use only local or only remote data sources.  This is primarily useful when you will usually be using a BOS but also need to use a local database.
 
In your case, if you can always access the main database from the client with a direct 2-tier connection to the database, then maybe the PersistenceServiceOption will work for you.  You can contact us directly if you'd like to discuss your options further.

Posted By: *Calsy
Date Posted: 09-Feb-2009 at 5:26pm
Hi Kim, That wont work in our circumstance because we still want the option for the main connection to be over a 2-tier or n-tier setup. We cannot limit it in that way. I think the only way I can see that we can do it is to actually connect directly to the database over the internet with an ip address for the server name. Was hoping we wouldn't have to do this.

Thanks

Posted By: kimj
Date Posted: 09-Feb-2009 at 5:37pm
I understand.   I don't think I can promise anything in the near term.  You may want to talk with your account rep or Ward if this is a really important issue for you.

Posted By: *Calsy
Date Posted: 09-Feb-2009 at 7:56pm
Can you see any issues with having customers connecting directly to our server which is hosted on a public web server. I can only think of the issue that customers might have their SQL ports blocked by their firewall.

Posted By: kimj
Date Posted: 09-Feb-2009 at 11:22pm
You mean the SQL Server would be outside a firewall and publicly available?  I think I'd want a good DBA.  SQL Server also supports SSL, which is something I'd look into with this.
 
Another option might be to write a (somewhat) simple web service as a front end to the database.  A BOS can communicate with any number of web services, and you'd avoid the security issues of directly exposing the database.  This is actually an option several other customers use.   For read-only access this might entail very little coding, since you could also use DevForce to generate the web service.   For update access it's a little more difficult, but still doable.   We have several web service instructional units available - on "publishing" and "consuming" - and a sample available by request showing how entity updates can be accomplished.


Print Page | Close Window