First of many questions I am sure.



I am adding the security tables required to use ASP.NET 2.0's membership API to a database using aspnet_regsql.exe.



I then used the import function (SQL Server) in DDT to import these tables along with my database, it gets the tables but not the views or stored procs (of which there are about 45). So of course when I deploy it blows off all that good stuff I need for my app.



So here is the rub, I want to use DDT for my web applications (website) database. My thought is that I will manually add the views and stored procs to the metadata and then be able to use the DDT exclusively from that point on. I can just use SQL Management Studio's "CREATE TO" functions to get the stored procs and view definitions.



Do you guys see any issue with this? It will be a decent amount of work up front, but then I am centralized and able to use both ASP.NET role/membership based security and Strataframe. That is my thinking.

Keith Chisarik

If you create the relationships and indexes through SCRIPT then you will be directly defying how the DDT is designed and you will start to see deployment issues.  Importing the relationships and indexes is part of the enhancement requests that I mentioned in a previous post.

If you manually create the relationships and indexes, then you will see proper behavior from that point forward.  Since we use SMO and logically detect and update relationships, indexes, etc., the DDT relies on the meta-data in order to know whether these items are part of the schema and how to deal with them.

So yes, I agree that your problems are stemming from the indexes and relationships not being imported.