Nếu bạn phải lặp lại (*), sử dụng cấu trúc được thiết kế để làm điều đó - con trỏ . Có nhiều sai lệch, nhưng nếu nó thể hiện rõ ràng nhất ý định của bạn, tôi nói hãy sử dụng nó:
DECLARE @ID int
DECLARE IDs CURSOR LOCAL FOR select ID from SAMPLE where Name = @NameParameter
OPEN IDs
FETCH NEXT FROM IDs into @ID
WHILE @@FETCH_STATUS = 0
BEGIN
exec myproc @ID
FETCH NEXT FROM IDs into @ID
END
CLOSE IDs
DEALLOCATE IDs
(*) Câu trả lời này gần đây đã nhận được một số phiếu tán thành, nhưng tôi cảm thấy mình cũng nên kết hợp cả nhận xét ban đầu của mình ở đây và thêm một số lời khuyên chung:
Trong SQL, bạn nên nói chung tìm kiếm một giải pháp dựa trên bộ. Toàn bộ ngôn ngữ được định hướng xoay quanh các giải pháp dựa trên tập hợp và (đến lượt nó) trình tối ưu hóa được định hướng xung quanh việc làm cho các giải pháp dựa trên tập hợp hoạt động tốt. Ngược lại, các công cụ mà chúng tôi có sẵn để điều chỉnh trình tối ưu hóa cũng được định hướng thiết lập - ví dụ:áp dụng các chỉ mục cho các bảng.
Có một số ít các tình huống mà lặp lại là cách tiếp cận tốt nhất. Đây là một vài điều khác xa và có thể được ví như các quy tắc của Jackson về tối ưu hóa - không làm điều đó - và (chỉ dành cho các chuyên gia) không làm điều đó chưa .
Bạn được phục vụ tốt hơn nhiều khi trước tiên hãy cố gắng hình thành những gì bạn muốn về tập hợp tất cả các hàng sẽ bị ảnh hưởng - thay đổi tổng thể cần đạt được là gì? - và sau đó cố gắng tạo một truy vấn đóng gói mục tiêu đó. Chỉ khi truy vấn được tạo ra bằng cách làm như vậy không hoạt động đầy đủ (hoặc có một số thành phần khác không thể làm bất kỳ điều gì khác ngoài xử lý từng hàng riêng lẻ) thì bạn mới nên xem xét sự lặp lại.