Database name (local/remote)


Author
Message
Chan
Chan
Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)
Group: Forum Members
Posts: 533, Visits: 2K
Hi,

I have questions as below:



1. How could I allow user to decide database name during DDT deployment?

2. I have some view that join tables from local and remote database. The remote database name could be vary among customer even though it is has the same structure. How could I tell DDT at runtime so that it will "change" my view defination to map to the remote database?



Please advice.



Thank you
Trent Taylor
Trent Taylor
StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)
Group: StrataFrame Developers
Posts: 6.6K, Visits: 6.9K
1. How could I allow user to decide database name during DDT deployment?

Well, there are a number of ways to do this.  In our medical application, we have a custom installer (see the Database Installer Sample for an idea about this) where we deploy our structures.  During our installation, we check to see if this is a new install or another instance.  If this is a new instance, we ask them for an instance name where we then tack on the instance name to the database (i.e. MyNewInstance_MyDatabaseName).  You have 100% control of the database name if using the DatabaseMigrator class.

The second option would be to use the standard MDDeployMain dialog (also shown in the database installer sample) where there is a screen that let's the user enter any name they would like.  But in either case, you can change the name to be whatever you like.  The DatabaseMigrator class accepts an array with all of the names that will be deployed to...so it then just becomes a matter of you asking the end-user for the name at some point prior to the DDR deployment.

2. I have some view that join tables from local and remote database. The remote database name could be vary among customer even though it is has the same structure. How could I tell DDT at runtime so that it will "change" my view defination to map to the remote database?

One thing you may consider here is using the Pre/Post Deployment Scripts.  You can implement any logic you need within this scripts.  This might be a good example of where you would want to do this.  Let the DDT deploy as it would normally, then in a post deployment script, you could execute some script that updates the view to whichever remote database you need.  That would be one way of doing this.

Keith Chisarik
Keith Chisarik
StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)
Group: StrataFrame Users
Posts: 939, Visits: 40K
1) If using ASP.NET (I think you do from past posts) when you go to do #1, you will find that the database migrator class looks for a control/object that supports INVOKE as the third parameter, since web controls dont you will have to create your own as a workaround. I have a web application that allows users to do just this, name and create their own databases. I just add a _XXX identifier to them so I know which ones to update when it comes time.

Public Class DBMigratorInvokeObject

Implements System.ComponentModel.ISynchronizeInvoke

Public Function BeginInvoke(ByVal method As System.Delegate, ByVal args() As Object) As System.IAsyncResult Implements System.ComponentModel.ISynchronizeInvoke.BeginInvoke

Throw New NotSupportedException()

End Function

Public Function EndInvoke(ByVal result As System.IAsyncResult) As Object Implements System.ComponentModel.ISynchronizeInvoke.EndInvoke

Throw New NotSupportedException()

End Function

Public Function Invoke(ByVal method As System.Delegate, ByVal args() As Object) As Object Implements System.ComponentModel.ISynchronizeInvoke.Invoke

Return method.DynamicInvoke(args)

End Function

Public ReadOnly Property InvokeRequired() As Boolean Implements System.ComponentModel.ISynchronizeInvoke.InvokeRequired

Get

Return True

End Get

End Property

End Class



Keith Chisarik
Chan
Chan
Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)
Group: Forum Members
Posts: 533, Visits: 2K
Hi,

Do you meant any view/stored procedure that access remote database got to be maintain seperately? Then, in DDT pre/post script ask migrator class to execute it?



Thank you
Trent Taylor
Trent Taylor
StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)
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.
Chan
Chan
Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)
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
Trent Taylor
StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)
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
Chan
Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)
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
Trent Taylor
StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)StrataFrame Developer (8.7K reputation)
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 Sad 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
Chan
Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)Advanced StrataFrame User (609 reputation)
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
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search