編輯
在解決下面我檢查了本地文件鎖定。在這種情況下,解決方案是要求供應商在加載完整文件並準備好下載後在FTP服務器上發佈一個小標誌文件。在開始下載完整文件之前檢查是否存在標誌文件。
末編輯
我使用腳本任務以下檢查文件鎖:
public void Main()
{
// TODO: Add your code here
string strTracePath = Dts.Variables["uv_TraceFilePath"].Value.ToString();
FileInfo fInfo = new FileInfo(strTracePath);
try
{
Dts.Variables["uv_TraceFileSize"].Value = fInfo.Length;
fInfo.MoveTo(strTracePath + "_old");
FileInfo fInfoOld = new FileInfo(strTracePath + "_old");
fInfoOld.MoveTo(strTracePath);
Dts.Variables["uv_ProcessTraceFile"].Value = true;
}
catch
{
Dts.Variables["uv_ProcessTraceFile"].Value = false;
}
Dts.TaskResult = (int)ScriptResults.Success;
}
的任務嘗試移動文件(到同一文件夾),同時將其重命名。如果這種情況發生,那麼它會將其移回原始名稱。成功時,它將變量設置爲true。失敗時,它將該變量設置爲false。出來這個任務我使用條件優先約束來決定下一步該做什麼。爲了做到這一點,我在腳本的頂部添加了一個Using System.IO;
聲明。
我不認爲這種方法適用於OP場景。他們正試圖檢查通過FTP的鎖定,而不是本地文件系統。也許從FTP發出雙重命名會得到相同的結果... – billinkc
你是對的。我正在檢查本地文件系統。 –
重新讀取看起來OP正在從\\ Local_FTP_Server \ ShareName本地複製到\\ Local_SSIS_Server \ ShareName的問題。因此,如果在外部FTP進程仍在寫入的情況下嘗試本地重命名,它應該將該錯誤置於Catch塊將捕獲的腳本中。因此,我相信我的原始腳本是可行的,但是,完整文件完成FTP過程後,從供應商發送到本地FTP的標誌文件也是一種乾淨(且風險較小)的管理方式。 –