BIML Ole db源上的參數化查詢

Question

我正在用BIML構建多個SSIS包，我必須在日期間隔內從OLE DB源檢索數據。下面是爲需要生成軟件包的XML：

<Dataflow Name="DFT Insert into <#=TableName#>"> 
    <Transformations> 
     <OleDbSource Name="Retreive from Source (<#=TableName#>)" ConnectionName="AS400"> 
      <DirectInput> 
       SELECT s.* 
       FROM <#=TableSchema#>.<#=TableName#> s 
       WHERE s.date &gt; ? AND s.date &lt;= ? 
      </DirectInput> 
      <Parameters> 
       <Parameter Name="0" VariableName="User.StartDate"/> 
       <Parameter Name="1" VariableName="User.MiddleDate"/> 
      </Parameters> 
     </OleDbSource> 

     <OleDbDestination Name="Insert into Destination (<#=TableName#>)" ConnectionName="DB2Mirror" KeepNulls="true" CheckConstraints="false"> 
      <ExternalTableOutput Table="[<#=TableSchema#>].[<#=TableName#>]" /> 
     </OleDbDestination> 
    </Transformations> 
</Dataflow> 

這種結構將正常工作，因爲我已經嘗試過，但用的ID（INT），而不是日期（字符串）。試圖生成包時我收到的錯誤是：

Could not execute Query on Connection AS400 
OleDbCommand.Prepare method requires all variable length parameters to have an explicitly set non-zero Size. 

我知道我可以創建一個SSIS變量和查詢作爲表達拼接的日期，但我想堅持與<DirectInput>代替<VariableInput>

信息

日期時間（對不起，我忘了提及這是日期時間，但我不認爲它改變了）可變格式是正確的：YYYY-MM- dd hh：mm：ss。我很確定格式沒有問題，因爲我試圖創建一個變量作爲表達式，連接日期如下：<Variable Name="Query" DataType="String" EvaluateAsExpression="true">&quot;SELECT * FROM table WHERE col &gt; '&quot; + @[User::StartDate] + &quot;'&quot;</Variable>並且它可以工作。有一件事我忘了提，它可能是重要的是，源數據庫管理系統是一個DB2

Answer 1

如下表定義

CREATE TABLE dbo.so_42623962 
(
    RowSk int NOT NULL 
, [Date] date 
); 

這是我最小的，可行的BIML使用參數與OLE DB源

<Biml xmlns="http://schemas.varigence.com/biml.xsd"> 
<Connections> 
    <OleDbConnection Name="tempdb" ConnectionString="Data Source=localhost\dev2016;Initial Catalog=tempdb;Provider=SQLNCLI11.0;Integrated Security=SSPI;"/> 
</Connections> 
<Packages> 
    <Package Name="so_42623962" > 
     <Variables> 
      <Variable Name="StartDate" DataType="String">2017-01-01</Variable> 
      <Variable Name="MiddleDate" DataType="String">2017-01-01</Variable> 
     </Variables> 
     <Tasks> 
      <Dataflow Name="DFT Demo"> 
       <Transformations> 
        <OleDbSource Name="SRC Query" ConnectionName="tempdb"> 
         <DirectInput><![CDATA[SELECT * 
         FROM dbo.so_42623962 AS X 
         WHERE X.[Date] > ? AND X.[Date] <= ? ;]]></DirectInput> 
         <Parameters> 
          <Parameter Name="0" VariableName="User.StartDate" /> 
          <Parameter Name="1" VariableName="User.MiddleDate" /> 
         </Parameters> 
        </OleDbSource> 
        <DerivedColumns Name="DER Placeholder" /> 
       </Transformations> 
      </Dataflow> 
     </Tasks> 
    </Package> 
</Packages> 
</Biml> 

這將構建一個包就好了。如果我拿出CDATA，這需要把逃避大於/小於字符，它仍然有效

 <Dataflow Name="DFT Escaped"> 
      <Transformations> 
       <OleDbSource Name="SRC Query" ConnectionName="tempdb"> 
        <DirectInput>SELECT * 
        FROM dbo.so_42623962 AS X 
        WHERE X.[Date] &gt; ? AND X.[Date] &lt;= ?;</DirectInput> 
        <Parameters> 
         <Parameter Name="0" VariableName="User.StartDate" /> 
         <Parameter Name="1" VariableName="User.MiddleDate" /> 
        </Parameters> 
       </OleDbSource> 
       <DerivedColumns Name="DER Placeholder" /> 
      </Transformations> 
     </Dataflow> 

如果我不裹Date柱與支架，它仍然工作

 <Dataflow Name="DFT Escapedx2"> 
      <Transformations> 
       <OleDbSource Name="SRC Query" ConnectionName="tempdb"> 
        <DirectInput>SELECT * 
        FROM dbo.so_42623962 AS X 
        WHERE X.Date &gt; ? AND X.Date &lt;= ?;</DirectInput> 
        <Parameters> 
         <Parameter Name="0" VariableName="User.StartDate" /> 
         <Parameter Name="1" VariableName="User.MiddleDate" /> 
        </Parameters> 
       </OleDbSource> 
       <DerivedColumns Name="DER Placeholder" /> 
      </Transformations> 
     </Dataflow> 

那麼我的工作演示與你的之間還剩下什麼？更容易處理的是你的日期的價值（開始/中間日期）。我用yyyy-mm-dd aka ccyy-mm-dd往往會更加普遍地被我使用的系統所理解，但是您可以嘗試yyyymmdd的ISO標準。

更難處理的事情將是你的連接管理器被命名爲AS400。事實上，那響起了一個鐘聲，因爲我不得不在另一個問題上處理一個「奇怪」的日期，他們使用了Julian dates，但我看到AS400使用CYMD格式，這種格式同樣「奇怪」，你必須寫一個自己的表達式派生列將yyyy-mm-dd日期轉換爲CYMD。不應該很難，但考慮到可能的日期格式的豐富性，我不會冒險猜測。