I am using a separate database for the role based security files and when I deploy for the first time it automatically creates the physical database files in a default folder. We have customers that implement policies for the physical location of database files. Is there any way to specify the folder location if the database does not exist? I basically use your standard deployment routines, which I have wrapped for customer use, so does your standard deployment routine currently support this?.

Tim

Yes, when you create the database using SMO, if you specify the filename, you cannot specify it without also specifying the folder in which to create it.  So, we use the server's properties to determine the default path setup by SQL Server and the user-specified path for the data.  If the user path is specified, then it gets used, otherwise, the default path gets used.

I can't seem to find where to set the folder name to create the physical .dat file and transaction log file. Is there some place to do this in the mddeployprocess or do I have to modify the source code to do this.

Thanks

TIm

There is not a place within the DatabaseMigrator to allow you to specify the exact path for the file when it is created.  The code looks like this:

If _SQLServer.Settings.DefaultFile.Length > 0 Then
    lcReturn = _SQLServer.Settings.DefaultFile
Else
    lcReturn = _SQLServer.Information.MasterDBPath
End If

The _SQLServer is a Microsoft.SqlServer.Management.Smo.Server object.  The Settings.DefaultFile is the default location for the data set by the install of SQL Server.  The Information.MasterDbPath is the path that you can specify within the server properties in SQL Server Management Studio.  So, it always places the .mdf files within the default database location.  If you need to change that, you'll need to change the source code.  In the DatabaseMigrator class, it's either going to be the GetDataFilePath() method or the CreateSmoDataFile() method.

Hi,

Shall we enhance this method so that can be overridable?



Please reply so that we could know what should be done next.



Thank you

If you want to change the deployment path of the physical database files, the easiest thing is to change the default deployment path of SQL server. This is what I would recommend if at all possible.

However, if you still need to deploy the files to somewhere other than SQL Server's default path then, yes, you'll need to change the DDT source code as Ben described to enable that functionality.

Sorry, it is not possible for us, as we have to follow our customer IT policy.







Change DDT source is the LAST step I would consider, as I don't want to worry any break if any strataframe upgrade. Therefore, I am looking for long term solution. I would like to request SF provide some way (such as make the method overriable) for us to override this behavour. Some more, ALL of our customers (900 customers) have this kind of requirement, it should be standard policy.



Beside, I also would like SF to make SF code more extendable in the sense, SF user could extend / override SF framework more by themselves. As SF framework really provide very robust RAD experience, however, when come to the time to extend/override default SF behavour, it is always restricted as most of the methods are marked private.



Please advice. Thank you