|
Chan
|
|
|
Group: Forum Members
Posts: 533,
Visits: 2K
|
Trent L. Taylor (01/22/2009)
Yeah, that is not a bad idea on the dummy database. When you pick the database to execute in the Pre/Post script, it will execute on the renamed database. So if the remote database name was Chan and they entered Chan_New, then it would execute that script on Chan_New. All of this is giving me an idea for an enhancement which would be the introduction of profile variables that you could place within your sproc code and then those variables would be replaced at the time of deployment with the value you give it. This is actually a really good idea and would be a good application for this very thing. The bad part is that it isn't there yet  since the idea just came to me. But I will add this to the list and this is something that will most likely make it into the DDT. Good idea, Chan. Hi, Just would like to add-on, this enhancement should not only add to pre/post profile script. Instead, it would be great if this logic can be apply to stored proc/view/trigger/udf and etc as well. Thank you
|
|
|
|
|
Trent Taylor
|
|
|
Group: StrataFrame Developers
Posts: 6.6K,
Visits: 6.9K
|
Well, at this point there is not anything like that from directly within the DDT. That is why this thread was filled with some good ideas to use DDT variables (which don't presently exist) so that you can manipulate this at the time of deployment and add your own logic. There are a lot of good ideas here. However, at the moment, you could still create a CLR sproc that is deployed using the standard DDT logic and then executed as a post deployment script. You could then use that CLR sproc to update any other elements that need updating.
|
|
|
|
|
Chan
|
|
|
Group: Forum Members
Posts: 533,
Visits: 2K
|
Hi,
Hmmm... the reason to use .NET code in my case is not to execute something at SQL Server. Instead, during DDT deployment process. In order words, I would like to have custom logic during deployment database.
Any ideas?
Thank you
|
|
|
|
|
Trent Taylor
|
|
|
Group: StrataFrame Developers
Posts: 6.6K,
Visits: 6.9K
|
Well, if you want to implement .NET, code, then I suggest creating a CLR stored procedure. This is what the CLR stored procedures are designed for and can make doing certain things much easier versus doing it all in T-SQL code.
|
|
|
|
|
Chan
|
|
|
Group: Forum Members
Posts: 533,
Visits: 2K
|
Hi,
I would like to add-on is that, I found that profile script only support T-SQL, is it? Any possible to place .NET code?
Thank you
|
|
|
|
|
Trent Taylor
|
|
|
Group: StrataFrame Developers
Posts: 6.6K,
Visits: 6.9K
|
Yeah, that is not a bad idea on the dummy database. When you pick the database to execute in the Pre/Post script, it will execute on the renamed database. So if the remote database name was Chan and they entered Chan_New, then it would execute that script on Chan_New. All of this is giving me an idea for an enhancement which would be the introduction of profile variables that you could place within your sproc code and then those variables would be replaced at the time of deployment with the value you give it. This is actually a really good idea and would be a good application for this very thing. The bad part is that it isn't there yet since the idea just came to me. But I will add this to the list and this is something that will most likely make it into the DDT. Good idea, Chan.
|
|
|
|
|
Chan
|
|
|
Group: Forum Members
Posts: 533,
Visits: 2K
|
Hi,
Is it possible to access DatabaseMigrator property within pre/post script? Or, any "hook" I can plug my custom logic in?
I was thinking to
1. Create a dummy database, without any table. It is just to let user to specify my "remote database" name.
2. In Pre/Post script/any hook, access the remote database name value specified by user from DatabaseMigrator class and replace my view/sp script by my own code.
Is it doable?
Thank you
|
|
|
|
|
Trent Taylor
|
|
|
Group: StrataFrame Developers
Posts: 6.6K,
Visits: 6.9K
|
That could be more difficult. I would probably create a view that is always going to e the same name and then within that view call a UDF or something along those lines to return the proper database name. There is no replacement logic wihtin a script in the DDT at the moment. This might be a good idea for an enhancement in the future, but at present, there is not any logic to go and replace internal text within the DDT sprocs, etc.
|
|
|
|
|
Chan
|
|
|
Group: Forum Members
Posts: 533,
Visits: 2K
|
Hi, After I re-read this thread for many times, I found that it is not what I want. I have database (DB1) that used by my application. I need to join/left join data with remote database as well (DB_Remote). Therefore, I have created view/stored proc as below in DB1: SELECT * FROM DB1.Table1 JOIN DB_Remote.Table1 I am using DDT to deploy DB1 database. Problem, the remote database name could be vary. It might not always called DB_Remote. How could I let DDT to ask for its database and replace the db name in my view/stored proc script? Thank you
|
|
|
|
|
Trent Taylor
|
|
|
Group: StrataFrame Developers
Posts: 6.6K,
Visits: 6.9K
|
Well, if this remote DB is not managed by another DDT package, and you are only managing a fews views/sprocs on that remote database, then yes. You have several options, you can use the post deployment script to just create the views and sprocs or create another DDT package. I would probably just use the post deployment script if the remote DB wasn't deployed with a DDT project and I just needed to insert a few views ans sprocs. But if there were a lot of views and sprocs, and I had control of the remote database, then I would probably go ahead and create another DDT package.
|
|
|
|