You can deploy the database programmatically using the MicroFour.StrataFrame.DBEngine assembly.  When we add the ability for you to choose the database name, you can determine the possible databases through whatever logic is necessary and just provide the correct one when you call DatabaseMigrator.DeployMetaData().

Yup, that change would do it.



Ideal would be slightly stronger -

Allow selection of "Correct" databases, and for me to validate them (e.g. If I know a particular table that must exist in the database that I link to, would like to be able to limit the selection to only databases with that table existing. Better if post an event per Database on that server, allowing subscription to that event, and letting a flag be set indicating "Invalid Database". I explicitly shouldn't alter the database that I'm linking into, which fits well in the dynamic sql scenarios, but could cause trouble installing). This might not belong in the Database area, but rather the DataSource Selection part of hooking up the application, not sure, you'd be a better judge of that!

Yes, that enhancement request has already been mentioned.  When you choose to deploy a database, right now the database is "hard-coded" in the profile.  So, you cannot deploy the same package to two different database names within the same instance of SQL Server. 

So, if we allowed you to select the database name when deploying, then that would take care of you're only issue.

In the scenarios that we are currently envisioning, we are picturing multiple databases for our application.



Each containing a full version of the Tables / Schema / Etc.



Our plan is to have a Base package, then an Specific part per (Customer / System) that we need to integrate to.



Many times we need to integrate to multiple systems on a single server, all w/ the same stuff, just a different package.



We produce add-on packages, so have basically no control over the systems that we integrate to, so if I need to integrate to a Jim1 system than I'm hoping to be able to indicate that, in a single run, the Database name to create and the ERP package.



So develop a solution, all within one DB, Solution1



Need to install it twice, against Jim1Instance1 and Jim1Instance2



Would hope to have a Jim1Instance1_CustomSolution1 DB AND a Jim1Instance2_CustomSolution1 database possible (Schema within the CustomSolution the same, but business rules pointing to different Instances, and views also specific to the Instance)



Not sure if this is possible currently, if going to add probably could allow this as an option within the ToolKit on the Database Level (Prompt during deployment or something), and if selected ask for each DB with this option selected during the Deployment wizard