Trả lại số lỗi SSIS hiện tại

Question

Trong gói SSIS có thuộc tính MaximumErrorCount. Lượng sử dụng của thuộc tính này ngụ ý rằng trong quá trình thực thi gói, số lượng lỗi được tính theo gói.

Tại các điểm khác nhau trong quá trình thực thi bộ gói đặc biệt phức tạp (thường có MaximumErrorCount được đặt ở mức cao hơn tại các điểm khác nhau). Tôi muốn có thể nắm bắt số lỗi hiện tại - nhưng dường như tôi không thể tìm một cơ chế để làm điều này. Lý tưởng nhất nó sẽ là một biến hệ thống (nó không phải là xa như tôi có thể nhìn thấy) vì vậy tôi có thể xây dựng các biểu thức chống lại nó theo ý muốn, nhưng tệ hơn tôi dường như không thể tìm thấy một phương tiện để nắm bắt nó trong kịch bản một trong hai, hoặc là (kỹ năng VB.net của tôi rất kém, vì vậy tôi có thể đã bỏ lỡ nó, nhưng tôi đã googled và tìm kiếm trong Object Browser mà không thành công).

Bất kỳ SSIS Guru nào biết cách tôi có thể nắm bắt số lỗi hiện tại tại các điểm đã cho trong khi thực thi gói?

(Tôi đã thử nhúng một biến đơn giản vào bộ xử lý sự kiện OnError cấp gói, nhưng trong những trường hợp hiếm hoi, điều này dường như không đồng bộ với số lỗi thực tế "tính" của động cơ. , nếu có bộ đếm tích hợp, điều đó sẽ được ưu tiên hơn và thanh lịch hơn)

Cảm ơn bạn trước.

Answer 1

Thông thường, bạn sẽ sử dụng các ràng buộc để chỉ đạo luồng xử lý lỗi. tức là nếu một tác vụ cụ thể không thành công, hãy điều khiển luồng kiểm soát bằng một ràng buộc thất bại. Nếu bạn muốn tạo dung sai dựa trên số lỗi, bạn sẽ cần phải nắm bắt từng lỗi trong một biến sau mỗi tác vụ (một lần nữa, sử dụng các ràng buộc và một tác vụ kịch bản).

Tôi không nghĩ rằng có một bộ đếm được tiếp xúc giữ số lượng lỗi hiện tại cho một nhiệm vụ hoặc vùng chứa, nhưng một bộ đếm như vậy sẽ được phạm vi cho từng đối tượng và chính gói đó. Điều này nghe có vẻ như nó sẽ là đau đớn để làm việc với ngay cả khi bạn có thể nhận được ở đó.

Đề nghị của tôi sẽ là những thứ sử dụng ra khỏi hộp là tốt nhất bạn có thể:

• Sử dụng hạn chế chỉ đạo thành công và hành vi thất bại
• Không sử dụng xử lý sự kiện, bởi vì họ giống như một GOTO vô hình và bạn không bao giờ biết họ đang ở đâu
• tiếp tục làm việc để mã thành công hơn là chịu được lỗi. Nó là đáng sợ để nâng cao số lượng lỗi tối đa và không bao giờ biết bất cứ điều gì đã đi sai. Ý tôi là, trừ khi bạn không quan tâm đến dữ liệu của mình. Tôi không phải là facetious trong nhận xét đó - điều này có thể là hành vi hoàn toàn chấp nhận được trong việc di chuyển dữ liệu đến một môi trường thử nghiệm.
• Sử dụng biến ít. Có thể có một vài điểm quan trọng trong một số gói cần chú ý, vì vậy đừng thêm một mê cung của các biến sẽ trở nên khó khăn hơn để khắc phục sự cố và duy trì. Nếu bạn có thể hạ thấp số lỗi tối đa xuống 1 theo thời gian, có thể bạn sẽ chỉ thay đổi một vài điểm trong các gói (80/20?). Nếu bạn thực sự phải viết lại toàn bộ điều đó, thì ... thì thật là crap để bắt đầu với sự riddance tốt, đúng không?