By Bill Cunnien - 12/20/2007
I am trying to test the deployment of the security tables to my test server from which the application runs. I setup a profile in the DDT, then began the wizard. After selecting Role Based Security Type for the DDT, I was then asked about the source DB. Of course, this is the local SSE2005 database used only by my development environment. That was no problem. When I go to the next window, I am asked about the destination database. The drop down list is not populated. I cannot choose anything. I clicked finished anyway (knowing I would get an error) and I received an error box with the typical object not found error. I clear the error window and now I am stuck on the wizard. I cannot cancel, break, esc or anything. Time to kill the process.What do I need to do to fill that list of potential destinations? Thanks,
Bill
|
By Ivan George Borges - 12/21/2007
Hi Bill.Have you added a Database into your newly created DDT profile? Either choose New Database from the Profile menu, or right-click on the left pane and choose New Database, if this is the case. Hope it helps.
|
By StrataFrame Team - 12/21/2007
Yep, Ivan is correct. You need to have a database in your profile before you can import the security table structures and data.
|
By Bill Cunnien - 12/21/2007
Thanks, Ivan and Ben!I created the database that will store my schema and data for the roles and security. I ran the Deployment Package Wizard. It seems like the DDT has done something, although I am not sure what it is exactly. Now, I would like to actually deploy this database to my SQL Server. How do I do that? When I choose the option "Deploy to Server" from the toolbar (seems like the logical thing to do), I am presented with a wizard. I fill in the SQL Server data to which I want to deploy the package, then click next. The database target names is empty. Is this a bad thing? Should I proceed, anyway? Is there some help doc that talks about these steps? Thanks, again,
Bill
|
By Ivan George Borges - 12/21/2007
The database target names is empty. Hey Bill. That's strange. It should be populated with the Database(s) name(s) created in the project. Sorry if this is a silly question, but are you sure you have a Database created in the profile you are trying to deploy?
|
By Ivan George Borges - 12/21/2007
Sorry Bill, forgot to mention.There is a whole lot of info on the Help file under "Database Deployment Toolkit".
|
By Bill Cunnien - 12/21/2007
I went ahead and clicked next on the empty grid. It didn't do anything, even though it said it created the metadata. Nothing is in my database.I did it again to see what would happen. Now, the grid is filled on the same step in the wizard. Odd. I clicked next, and, wham! I got a lot of good activity until this error shows up: "Could not locate entry in sysdatabases for database 'Master'. No entry found with that name. Make sure that the name is entered correctly." It looks like it created the database, added the tables, but it bombed on the views. Btw, I cannot find anything about this deployment procedure anywhere in the docs. There is a lot of stuff, but I am coming up blank on help regarding the actual deployment to the server. Maybe it has a name that is different than I expect. Thanks,
Bill
|
By Bill Cunnien - 12/21/2007
Here's what I think is happening...the database table is named 'master', not 'Master'. The casing is wrong. This is not something that I am able to fix. What can I do, now?
|
By Bill Cunnien - 12/21/2007
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?
|
By Bill Cunnien - 12/21/2007
Naturally, the SecurityDataSourceKey. I added my DataLayer.DataSource definition for the database, then set the SecurityBasics.SecurityDataSourceKey to the new key. Simple.
|
By Bill Cunnien - 12/21/2007
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
|
By Bill Cunnien - 12/21/2007
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
|
By Trent L. Taylor - 12/21/2007
LOL...glad you found your problem 
|
By Trent L. Taylor - 12/21/2007
Yup...you found it. The SecurityDataSourceKey tells the RBS BOs which data source to use.
|
By Greg McGuffey - 12/21/2007
Here's what I think is happening...the database table is named 'master', not 'Master'. The casing is wrong. This is not something that I am able to fix. What can I do, now?
SQL server doesn't care about casing. So...
Use master
and
Use master
both work.
|
By Trent L. Taylor - 12/21/2007
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
|
By Bill Cunnien - 12/21/2007
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.
|
By Greg McGuffey - 12/21/2007
Actually, the defaults were changed on your server to be case sensitive...
Jeesh, I completely forgot about that option. 
There are certain developers out there that swear by case-sensitive SQL Servers, but it can complicate things, as you have learned.
I certainly understand swearing at developers who turn this option on... 
|