Data Migrated by Package A
BIT Package A is a sample package to illustrate the migration of data in a Speech Server 2004 R2 reports database to a Speech Server tuning database.
BIT Package A migrates data that is used for the main Speech Server reports. For more information, see Speech Server Reports for Use with SQL Server Reporting Services. To examine or extend the mapping logic between the Speech Server 2004 schema and the Speech Server schema, open PackageA.dtsx and view or edit the Microsoft SQL Server Integration Services (SSIS) code that selects the source data and populates the target database.
Checks are placed in the migration code to ensure that if migrations are run multiple times with the same source and target databases, only the new data ??? in other words, data added to the database since the previous migration ??? is migrated each time BIT Package A runs.
|For some deployments, there can be a difference between the Call Volume and related totals in the Speech Server 2004 reports and Session Volume and related totals in the Speech Server reports. This difference occurs because a valid call in the Speech Server 2004 database is determined by the following query: Calls.[Answered At] IS NOT NULL AND Calls.[Disconnected At] IS NOT NULL Certain logging configurations in Speech Server 2004 deployments can result in valid calls that do not have values for Answered At or Disconnected At. The representation of bargein is different between the original Speech Server 2004 data and the migrated Speech Server data. The bargein data for turns that are migrated in BIT Package A generate different totals in the reports.|
|The fromDate and toDate parameters use the Calls.[AnsweredAt] time stamp to bound the period of data considered for migration. For this reason, calls in the source database with an AnsweredAt value of null is not migrated. Therefore, if a database contains calls for which the AnsweredAt time is not available (for example, if an earlier log file is missing during an initial import or has been purged), call row counts might not match between the source and target databases. To avoid this problem, ensure that logs for the period immediately preceding the fromDate have been imported into the source database (for example, by always migrating a period at least one hour later than the earliest call in the source database).|