1. I've imported my database into a DDT profile.  I'm assuming that from this point on any changes I make to the database schema in my development environment should also be made in the DDT profile.  Is it best to try and keep the 2 insync manually or would it be better to make the changes to the DDT profile, create an installation package and deploy it to my development environment?

2. It appears the DDT can't create Logins at the database server level or Users at the database level or am I missing something.  It appears the only security it handles is for Microfour's Role-based Security tool.  

Actually, you would make all schema changes in DDT, then deploy to your dev environment. Later, you'd deploy to your testing/staging and eventually production...all from DDT. Thus, the work flow is:



a. update schema in DDT

b. deploy to dev db(s) (use the deploy tool strip item, as it creates a new package and deploys that package quickly).

c. Update BOs with BO Mapper, doing partial builds

d. Use updated schema in app via updated BOs.

e. Repeat until ready to release to testing/staging

f. Use DDT to deploy to testing/staging db (using that handy deploy button again)

g. When ready, deploy to production. At this point you can again use the handy deploy button or you can create an installer so the deployment is not tied to the DDT, but a stand alone app or part of some larger installer....this can be as complicated as you need. Trent/Ben have posted on this a bit, just search the forum.







Not sure about the logins/users at the db level. I seem to recall that you are correct and it does not handle this. However, I'm sensing a bit of confusion about how SQL Server logins/users are related to the SF RBS tool. First, they aren't related to each other! Apples and oranges. The login/users are what you'd use to setup the data sources in the SetDataSources in appmain.vb or program.cs file and this controls the connection to the database by the app. Typically, you will need one login/user for an app and that is easy enough to set up manually for a db.



The RBS is used to authenticate users into the app (it is NOT used to authenticate the app with the db...that must be done prior to RBS features being called, which is done using the SQL Server login/user). The RBS data is stored in tables somewhere (option is yours, can be in a separate db or in a app db). The data contains information about users, permissions, roles, restrictions etc.



The DDT can easily (very easily) manage those RBS security tables. I.e. you can simply import the security tables in the db of your choice and deploy them very easily.



Hope that makes sense!

Great to see you back out here, Greg.  I hope that you had a great vacation!

Just to add to Greg's comments in this point.  It sounds like you are trying to create users for SQL Server.  Is this correct?  If so, the DDT doesn't have a section to create and deploy users to a server...though this may be an idea for a future enhancement.  The reason is that security is generally handled at the server level itself and is not generally something that is used for deployment purposes.  Though this is not a bad idea for a future enhancement.  If you have this need you can always create a stored procedure and then execute it to create your initial users.  The reason that this functionality was never added is because security is generally setup at the time SQL Server is installed versus the database.

Thanks for your responses guys.  They REALLY help!!!! Now I have several more questions.

1.  When I imported my schema into a DDT project, one of the tables ended up with 2 primary keys.  This table had a primary key defined as an auto-increment field (ID) and a unique index that was a combination of multiple fields.  When I deployed to the server an error was displayed when trying to create the primary key (ID) saying the primary key already existed.  I checked the DDT project and sure enough both the PK and the unique index were marked as a primary key.  The DDT doesn't allow changing of the index type so I had to delete the unique index that the DDT thought was a primary key and readd it as a unique index.  Any idea why that would happen?  I have several other tables with the same scenario but they imported ok.

2.  I created a database installer based on the supplied sample.  Everything seems to work fine except, when you click on the Select SQL Server dropdown it does not display the "Searching..." window and the dropdown does not get filled with a list of available servers.  I key in the server name and everything works fine but why won't the dropdown get populated?

3.  I imported a schema into a DDT project but I want to deploy it to a different database on the same server.  I'm assuming all I need to do is change the "Database Name on Server" when the Database Target Names dialog is displayed.  I know it will create the database with the right name but will all the underlying files (e.g. .mdf, .log, etc.) get created with the new database name?

Thanks!!

When I tried #3 above the deployment failed.  The database could not be created because it was trying to create an .mdf file that already existed.  The "source" database in the DDT project was called OpRate but I'm trying to deploy to a new database "OpRateTest" on the same database server.  Instead of trying to create OpRateTest.mdf, DDT tried to create OpRate.mdf which already exists for another database on that server.  Is there a workaround so I can deploy a "test" database to the same server?

[quote]Trent L. Taylor (03/05/2008)

---

Great to see you back out here, Greg. I hope that you had a great vacation![\quote]



Yep, it was great. Good to be back too!

If you ever plain on deploying to a database that is named other than what you originally named it, you need to update the PRIMARY file group (under the File Groups heading under the database) to use the special token to allow the file name to change:



$DbName$



This will put the name you enter into the dialog for the db name on the server as the .mdf/.ldf file name. I.e. you might do something like:



$DbName$_Data



Which would result in a data file named:



MySolution_Data.mdf



If you entered "MySolution" as the name of the db on the server.



Hope that is clear.

Greg is right...if you look at your file groups, your files names are static.  One common issue is that a database may be detached from the server, but the mdf file is left on disk, so when SQL Server tries to create the file group you will receive an error (which you experienced).  The other time that you get this is just like Greg mentioned, if you are  trying to deploy the same database to a different name on the same server.  This is when you will want to use the $DbName$ tag as part of the file name.  This is what we do with our medical software which allows us to have a virtually unlimited number of deployments of the same profile to the same server, we just provide a prefix that allows us to determine the instance of that database. 

The Browse service has to be running in order to "see" a SQL Server instance.  If you type in the name directly, and the server is there, then it will work.  The other thing that I have seen get in the way before is a firewall.  But I would imagine that you are dealing with the first scenario.