2009-03-05 33 views
6

Hầu hết các SP của tôi chỉ có thể được thực thi (và được kiểm tra) với dữ liệu được nhập thủ công. Điều này hoạt động tốt và sử dụng các câu lệnh PRINT đơn giản cho phép tôi "gỡ lỗi".Phương pháp ưa thích của bạn để gỡ lỗi thủ tục lưu sẵn MS SQL là gì?

Tuy nhiên, có những trường hợp có nhiều hơn một quy trình được lưu trữ và việc tìm dữ liệu hợp lệ cho đầu vào rất tẻ nhạt. Việc kích hoạt mọi thứ từ bên trong ứng dụng web của tôi trở nên dễ dàng hơn.

Tôi có một ít kinh nghiệm với profiler nhưng tôi đã không tìm thấy một cách để khám phá những gì đang xảy ra từng dòng trong các thủ tục được lưu trữ của tôi.

Phương pháp của bạn là gì?

Cảm ơn bạn, như mọi khi.

Lưu ý: Tôi giả sử dụng SQL Server 2005 +

Trả lời

8

Profiler rất tiện dụng, chỉ cần thêm SP: StmtStarting events và lọc hoạt động xuống chỉ bằng tiến trình của bạn bằng cách đặt SPID = xxx. Một khi bạn đã thiết lập nó, thật dễ dàng để xem những gì đang xảy ra.

+0

+1 chắc chắn là :) đôi khi bạn phải lấy trình gỡ rối (hy vọng nó được viết như thế nào + các bài kiểm tra có nghĩa là không bao giờ) – eglasius

4

Bạn thực sự có thể đính kèm một debugger đến máy chủ sql của bạn :) - từ vs, do bạn đã cấu hình mà trên máy chủ sql của bạn.

Kiểm tra liên kết này để biết thêm thông tin, lưu ý bạn có thể đặt điểm ngắt :) https://web.archive.org/web/20090303135325/http://dbazine.com/sql/sql-articles/cook1.

Kiểm tra liên kết này cho một tập tổng quát hơn của thông tin: http://msdn.microsoft.com/en-us/library/zefbf0t6.aspx

Cập nhật: Về "Có Tuy nhiên những trường hợp có nhiều hơn một thủ tục lưu trữ có liên quan và tìm kiếm dữ liệu hợp lệ để đầu vào là tẻ nhạt Nó dễ dàng hơn. để kích hoạt mọi thứ từ bên trong ứng dụng web của tôi. "

Tôi khuyên bạn nên thiết lập các bài kiểm tra tích hợp, tập trung vào các phương pháp cụ thể tương tác với các thủ tục đó. Nếu các thủ tục đang được thúc đẩy bởi ứng dụng web, đó là một nơi tuyệt vời để có các kiểm tra hợp lệ + đầu vào bạn có thể chạy bất cứ lúc nào. Nếu có nhiều ứng dụng tương tác với các thủ tục, tôi sẽ xem xét đơn vị kiểm tra các thủ tục thay thế.

1

Tôi thích chỉ sử dụng procs được lưu trữ để truy xuất tập dữ liệu và thực hiện bất kỳ "công việc" phức tạp nào ở phía ứng dụng. Bởi vì bạn là chính xác, cố gắng để "gỡ lỗi" những gì đang xảy ra bên trong ruột của nhiều lớp, con trỏ vòng lặp, temp-bảng bằng cách sử dụng, lồng nhau được lưu trữ proc là rất khó khăn.

Điều đó nói rằng, MS KB 316549 mô tả cách sử dụng studio trực quan để gỡ lỗi các procs được lưu trữ.

Theo bài báo này, có một số hạn chế đối với gỡ lỗi trong thời trang này:

  • Bạn không thể "phá vỡ" thực hiện.
  • Bạn không thể "chỉnh sửa và tiếp tục".
  • Bạn không thể thay đổi thứ tự thực hiện câu lệnh.
  • Mặc dù bạn có thể thay đổi giá trị của biến, thay đổi của bạn có thể không có hiệu lực vì các giá trị biến được lưu trong bộ nhớ cache.
  • Đầu ra từ câu lệnh PRINT SQL không được hiển thị.

Sửa: Rõ ràng, nếu bạn là người làm proc lưu trữ này, thì đừng làm cho nó "nhiều lớp, con trỏ-looping, temp-bảng sử dụng, và lồng".Tuy nhiên, trong vai trò là một DBA, đó là điều mà tôi gặp phải hàng ngày từ các nhà phát triển ứng dụng.

+0

Nhà phát triển cơ sở dữ liệu có thể xem mã ứng dụng theo cách giống như cách bạn mô tả quy trình được lưu trữ. – JohnW

+0

Chắc chắn sẽ khó để giải quyết nếu bạn cho rằng nó được viết khủng khiếp. Tôi muốn nói chính xác điều tương tự cho mã C# - nếu nhà phát triển viết rác bạn sẽ nhận được rác. –

+0

Tôi sẽ không bao giờ xem xét sử dụng "nhiều lớp, con trỏ vòng lặp, temp-bảng sử dụng, nhiều lớp lồng nhau được lưu trữ proc." Có hầu như luôn luôn cách tốt hơn để làm kinh doanh. Tôi nghĩ điểm mà JohnW tạo ra là nếu bạn đã làm một điều như vậy, nó sẽ là xấu theo định nghĩa cho một người cơ sở dữ liệu. – HLGEM

0

Theo như không biết đầu vào hợp lệ là gì, bạn cần kiểm tra nhiều loại đầu vào bao gồm đầu vào đặc biệt không hợp lệ. Bạn nên xác định các trường hợp thử nghiệm của bạn trước khi bạn viết procs của bạn. Sau đó, bạn có một bộ thử nghiệm có thể tái tạo để chạy mỗi khi có ai đó thay đổi quy trình phức tạp.

0

Nhóm của tôi sử dụng SP theo quy tắc làm giao diện của chúng tôi cho cơ sở dữ liệu; chúng tôi làm điều đó theo cách mà người dùng ứng dụng CHỈ có thể thực thi SP (với quy ước đặt tên của chúng tôi).

Một cách thực hành tốt nhất mà chúng tôi sử dụng, hoạt động tốt, là các tập lệnh thử nghiệm nhất định được chứa trong các nhận xét SP và phải được thực hiện trên mỗi vòng quay của SP hoặc phát triển SP mới.

Bạn nên luôn luôn, luôn luôn kiểm tra SP càng kỹ càng tốt mà không cần bất kỳ lớp ứng dụng nào liên quan (thông qua Management Studio chẳng hạn).

0

Hãy chắc chắn rằng bạn bước vào proc lưu trữ chính trong VS2005/2008, khi nó gặp một hàm lồng nhau, nhấn F11 (bước vào) để nhập vào .. .continue gỡ lỗi ... Nó không phải là rất rõ ràng từ trình đơn gỡ lỗi.

1

Tôi không muốn gỡ lỗi, thay vào đó tôi thực hiện thử nghiệm phát triển theo định hướng, điều này gần như loại bỏ nhu cầu gỡ lỗi.

+0

Ok, vì vậy khi kiểm tra của bạn thất bại và bạn không chắc chắn tại sao, TDD làm gì ? –

+0

@Mr Grieves, khi kiểm tra của tôi thất bại, tôi hầu như luôn luôn biết tại sao - các xét nghiệm của tôi thường cho tôi biết có gì sai. –

Các vấn đề liên quan