2012-11-17 26 views
4

我使用DBI和FreeTDS(在Ubuntu上)將一些數據插入SQL Azure中的Perl有間歇性問題。這個問題可能會發生,有些行會被忽略,然後我可以再次運行而不會出現問題。Perl/DBI/FreeTDS/SQLAzure一些插入被忽略

腳本:

print "Importing File $file: to Staging Table\n"; 
    open my $info, $file or die "Could not open $file: $!"; 

$dbh->do("EXEC DWTOOLS.InitStage;") or die $DBI::errstr ; #truncates the table 

    my $sth = $dbh->prepare("INSERT INTO DWSTAGE.CDRImport (LINE) VALUES(?);") or die $DBI::errstr ; 
    my $counter = 0; 
    while(my $line = <$info>) { 
      $line =~ s/\r?\n$//; 
      $counter++; 
    print "Loading line $counter: $line\n" ; 
      my $rc = $sth->execute($line) or die $DBI::errstr ; 
      print "Result: $rc\n"; 
    } 
    close $info; 


print "\nChecking Data Warehouse: $counter lines expected\n" ; 
my $checksth = $dbh->prepare("EXEC DWTOOLS.CheckStage ?;") or die $DBI::errstr ; 
    my $checkrc = $checksth->execute($counter) or die $DBI::errstr ; 

my @row; 
while (@row = $checksth->fetchrow_array()) { 
    print "Row: @row\n"; 
} 

給出了輸出:

Importing File filename: to Staging Table 
Loading line 1: data redacted 
Result: 1 
Loading line 2: data redacted 
Result: 1 
etc. etc. with no indication of errors 
Loading line 165: data redacted 
Result: 1 
Loading line 166: data redacted 
Result: 1 

Checking Data Warehouse: 166 lines expected 
Row: 35 166 
Row: 35 166 
Loading to Data Warehouse 

所以,當我看看錶,這表明所有的起始行缺少了某一點的時候纔開始工作 - 可靠 - 直到最後 - 基本上,文件的最後35行被加載,它們從1開始到35,其中第1行實際上是行(166-35 + 1)或其他。 Azure中的表有一個PK,集羣IDENTITY列,並且它從1開始並且沒有間隔,所以它就像第一個這麼多的插入被刪除而沒有任何錯誤指示。這發生在各種文件中,各種大小和文件中的各種位置。

文件被循環處理,每個文件都被打開,處理並關閉,以防這種奇怪的行爲發生。該語句爲每個文件重新編寫一次,但如果這可能導致問題,則SQL Azure連接將在程序生命週期中保留。如果連接失敗,我仍然期望該程序會死掉,但是從執行中返回的錯誤代碼的缺失來判斷,我不確定是否會出現錯誤。

如果我只是繼續並重新運行該程序,所有行都進來了,一切都很好。

我不確定畫什麼結論。現在,我的結論是,FreeTDS是越野車和不可靠的。

+1

你需要$ dbh-> commit()的地方嗎? – xxfelixxx

回答

0

看起來DB在截斷過程完成之前正在執行插入操作。如果這是一個存儲過程,則可以添加一些標記,並在繼續之前檢查它。或者最好還是將整個數據庫調用包裝到一個事務中。

+0

好吧,這已經很長時間了,我放棄了試圖從Linux進入這個數據庫。我想這是可能的,如果連接在某種程度上允許多個同時操作並在第一個存儲過程完成之前返回。它在Windows上沒有這個問題。 –