Any update on how to get the connection string in the SERVER side?

I need to know the current connection string used by the EntityManager without checking on the EdmKeys cause I used DataSourceKeyResolver to compose it dynamically..

I'm about to run a native sql server commands on the server side..

Thanks,

Von

You wrote: "I see by debugging that the Connection String is deep down in the class heirarchy of EntityManager"

 

No it is not. You cannot get to the connection string from the EntityManager.

 

I'll give you a big prize if you can find such a string from the EntityManager ... by reflection, debugging, or any other means ... because that would be a huge security hole. The connection string is not accessible from any client DevForce code.

 

You will find the DataSourceKey. That is just a name ... a name for requesting access to a server-side data source with that key. The key does not itself contain any information that would be useful in accessing the database directly.

 

Fortunately, I see that you are actually talking about writing server-side method (a "Remote Server Method") that makes use of ADO. That is ok.

 

As I said ... tomorrow I'll show you how you can get the string in DevForce 2010 from server-side code.

 

Please note that the string would only be accessible to server-side code. You wouldn't want your client application looking at the database connection string ... that's a security violation.

 

Side-note: when you run 2-tier, your "client-side" and "server-side" are executing in the same process so of course you can access the string there. I'm talking about accessibility in n-tier deployments as would be required, for example, in a Silverlight application.

 

Are you ready to learn how to get that string?

 

You'll have to wait for tomorrow :-)   I've run out of time this evening. But, trust me, you can get that string on the server.

 

Upon reflection, I'm not sure if I answered your question ... or if you thought there was something more we could or should do. If I hear from you, I'll know :-)

I would very much like to avoid doing things like this. The sad fact is just that the LINQ to Entiyt Framwork is not powerfull enoug to perform many of my complex queries. Secondly although some of them I can do via LINQ it has revealed to be 10-100 times slower than going via RPC using old style DataReaders at the server side.

Anothe thing is also that quite often we need to perform quite many queryes on the server side before geting the end result valid for the UI. In that case it is more easy to do it all in one round trip to the server than doing all the LINQ-queries client side causing many round trips to the server. Maybe I'm wrong here, but then please tell me about a usable alternative.

 

In fact, in our DevForce 2010 release, AdoHelper will "disappear".

 

You DO want to ensure that you're getting the same connection string that DevForce is using; that's a reason to go through the IdeaBladeConfig mechanism to retrieve it.

 

Once you have the connection string, do what you what seem most appropriate: raw ADO, direct to Entity Framework, whatever.

 

The key (pun intended) is to ensure that the connection string is accessible only on the server AND that your database interactions are consistent with application business logic. You don't want to bypass important business rules or actions  that are inscribed in your code (e.g., auditing client queries).

 

You want to preserve both Security and Data Integrity.

 

But, as you observe, the client won't have access to your server side connection string.

Hi Ward,
I think you are overseeing on4 important thing here.  The code in the original message is an RPC method on the server, not on the client. So I'm retrieveing the connection string server side, not client side. So there should be no risk involved, is it??!!

So the code is Server only and this method is accessed from the client by a InvokeServerMethodAsync(). The database connecton string is cracked server side only and never returned to the client. So I don't se there is any security issue here.

Regards

  TJ

 

We're also supporting n-tier scenarios which means that the connection strings shouldn't be knowable on the client. Your approach will fail misearably if run on the client in an n-tier deployment (e.g., Silverlight) ... as will mine and as should everyone's. If you could find the connection string from the client, that would be a really bad security violation!

 

Assuming you are running 2-tier or are performing your operation on the server, we know that you may have to get to the database directly. And so you can.

 

Take a look at the NumericIdGenerator code sample which uses raw ADO to talk to a table of counters for generating entity ids. After install on my Windows 7 machine it is located here