Database Deployment Toolkit
In the DDT, the file location is for the package file that will be created.  When you package up your meta-data, it creates a single compressed file that houses all of the meta-data.  You then take that file when you deploy your application and use it to deploy your structures.  It has all of the meta-data information and deployment data required for deploying the data structures to another server.

Localization
There are two methods of storing your localization messages: XML or SQL Server.  If you are using XML, this is the location that the localization files will be exported.  Even if you decide to use SQL Server, this field requires entry, but will not be used.

If I have a project in C:\Projects\LedgeComp, where would I put the DDT file and where would I put the Localization File. In the case of SQL Server Localization file, can I put this as a table in the same database where I'm going to store the data for the application, and if so, how do I do this?

Thanks,

Flavelle

SqlException
 Invalid object name 'DBEProfile'.

Source     : .Net SqlClient Data Provider

Stack Trace:
   at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
   at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
   at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
   at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
   at System.Data.SqlClient.SqlDataReader.ConsumeMetaData()
   at System.Data.SqlClient.SqlDataReader.get_MetaData()
   at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
   at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)
   at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)
   at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
   at System.Data.SqlClient.SqlCommand.ExecuteScalar()
   at MicroFour.StrataFrame.Data.DbDataSourceItem.ExecuteScalar(DbCommand Command)
   at MicroFour.StrataFrame.Business.BusinessLayer.ExecuteScalar(DbCommand CommandToExecute)
   at MicroFour.StrataFrame.Business.DBEProfileBO.GetTitleCount()
   at MicroFour.StrataFrame.Business.DBEProfileBO.DBEProfileBO_CheckRulesOnCurrentRow(CheckRulesEventArgs e)
   at MicroFour.StrataFrame.Business.BusinessLayer.raise_CheckRulesOnCurrentRow(CheckRulesEventArgs e)
   at MicroFour.StrataFrame.Business.BusinessLayer.OnCheckRulesOnCurrentRow(CheckRulesEventArgs e)
   at MicroFour.StrataFrame.Business.BusinessLayer.CheckRules(Boolean RaiseCheckedEvent)
   at MicroFour.StrataFrame.UI.Windows.Forms.BaseForm.Save(Boolean Transactional, String TransactionKey)
   at MicroFour.StrataFrame.UI.Windows.Forms.BaseForm.Save()
   at MicroFour.StrataFrame.Data.ProfileProperties.cmdSave_Click(Object sender, EventArgs e)
   at System.Windows.Forms.Control.OnClick(EventArgs e)
   at System.Windows.Forms.Button.OnClick(EventArgs e)
   at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ButtonBase.WndProc(Message& m)
   at System.Windows.Forms.Button.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

1. Open Visual Studio
2. Click the StrataFrame -> Database Connection menu item
3. Select the StrataFrame Data Store item and then click Edit
4. This will bring up a wizard, click Next > to go to the second page
5. Make sure the database name says "StrataFrame" then click next
6. CLick Finish
7. Select the StrataFrame Data Store and click Select

Now go back into the DDT and you shoud be good to go.  StrataFrame uses itself for the DDT, BO Mapper, Localization, and Security.  So this is our connection to the StrataFrame database not the connection to you database at runtime.

I've looked at the documentation on "Configuring the Message Store > Using SQL Server" and found it a bit sketchy. It references  a property Localization.MessageSqlDatabase which doesn't seem to exist so I've used Localization.MessageDataSourceKey instead, but without much success.

From previous discussion on this thread I now have the impression that on deployment of my application the data from the strataframe database that is required for the application (Localisation, BO Mappings, Security) needs to be deployed, and DDT will do this. It's not clear to me whether this goes to a single purpose strataframe database, or if it could go into the application's database. We have an existing means of deploying our database that we intend to keep using, so hadn't intended to use DDT.

It seems that during development the localisation data must be kept in the stratframe database if SQL server is going to be used as the source.

Am I on the right track or have I got this dreadfully confused?

Peter

It looks like you found an unmodified section in the help I will be sure to get this fixed.  You are correct in referencing the MessageDataSourceKey if you are going to use a SQL Server connection from which you are going to pull your localization keys.

Using SQL Server is actually not the most optimized source form which to pull your localization keys, but rather using embedded XML files.  However, if you have the need for this to be changed at run-time then SQL Server would be the best avenue.

If you use the embedded XML files then the deployment conversation is a mute point because the localization files are stored within the compiled assembly.  However, if you are going to use SQL Server, then you MUST deploy the localization keys to your end-users somehow.

The DDT makes short work of this and has a wizard to create a deployment data package which will pull all of your keys in from a specified localization project.  If you have the DDT then you can use it just for this single purpose if you choose and use your current means of deploying your structures in tact.  Otherwise you will need to make sure that your current deployment process will create the following tables:

• MessageLanguages
• MessageItems

You DO NOT need MessageProjects.  You will however need to gather up any records that have the foreign key of the projects primary key when creating your deployment packages (this is what the DDT does for you through a wizard).

Once you have all of this done the only thing remaining is the connection to where these tables will reside.  If the MessageLanguages and MessageItems tables reside in your default connection then you can ignore the MessageDataSourceKey since it will be the same.  Just be sure to set the MessageKeyType to SQLServer.  However, if the above specified tables will be in a separate database, then you will have to create another data source (you can refer to the docs on this....they are up to date, I checked ):

And then you will need to specify the MessageDataSourceKey to follow suit: