Jeesh, I completely forgot about that option.





I certainly understand swearing at developers who turn this option on...

The old SQL Server on which I placed the app data is one of the original RDBMSs in our company.  It started at v7 (maybe even 6.5!) and one of the requirements by the software that we bought it for was case-sensitivity.  It is often a headache to work around.  That is why I got a second SQL Server to do the other heavy lifting.  The main app data will have to reside on the old one, unfortunately.

Actually, the defaults were changed on your server to be case sensitive...this is generally a bad idea.  There are certain developers out there that swear by case-sensitive SQL Servers, but it can complicate things, as you have learned.  When you install SQL Server, by default, it will assume Case-Insensitive.  You can change this through the SQL Server Management Studio, but this is what is happening to you...good eye

SQL server doesn't care about casing. So...



Use master



and



Use master



both work.

Yup...you found it.  The SecurityDataSourceKey tells the RBS BOs which data source to use.

LOL...glad you found your problem

Solved. 

It had to be in the data source string.  So, after reviewing it, I realized that the instance name was not represented properly. 

Wrong: Data Source=SERVER/INSTANCE

Right: Data Source=SERVER\\INSTANCE

Hey, what's a back slash between friends?

Bill

Well, I thought it was simple.  Another error has popped up.  The server is telling me that it is refusing connections.

An error has occurred while establishing a connection to the server.  When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

This doesn't make much sense.  It is a 2K server and name pipes are the active protocol and there is no limit set on connections.  Also, how could I deploy the database, but not be able to access it?

Interesting!
Bill

Naturally, the SecurityDataSourceKey.  I added my DataLayer.DataSource definition for the database, then set the SecurityBasics.SecurityDataSourceKey to the new key.  Simple.

I went ahead and stuck the security package on another server.  The same case constraints apparently do not exist, because the package deployed without incident.  Now, I have my app data on one server and the security data on another.  What do I do to get the app to recognize where the data resides for security?