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?
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.
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 forMicrofour's Role-based Security tool.
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!
