Похоже, вам не хватает запятой между @OC и @OD в строке + 'ЗАКАЗАТЬ @OC @OD'

Вы также заметили, что размер ваших параметров меняется между определением процедуры и определением динамического SQL?

Вы можете протестировать, заменив динамические параметры SQL фактическими и просто распечатав последнюю строку, а затем запустив ее.

Помимо того, что вы знаете о возможных проблемах с использованием NOLOCK (грязное чтение, фантомное чтение, дублированные данные), ваше использование выглядит допустимым.

Попробуй это.

CREATE PROCEDURE spBaseVoterIndex  
    @order_col NVARCHAR(100) ,  
    @order_dir NVARCHAR(20) ,  
    @offset INT,  
    @limit INT 
AS
    SET NOCOUNT ON;  
BEGIN
    DECLARE @sql NVARCHAR(MAX)
    SET @sql = 'SELECT id, name_voter, home_street_address_1, home_address_city FROM dbo.base_voter'  
               +' WITH(NOLOCK)'  
               +' ORDER BY @OC @OD'  
               +' OFFSET @OF ROWS'  
               +' FETCH NEXT @LIM ROWS ONLY'  

    EXECUTE sp_executesql @sql,  
               N'@OC nvarchar(100),@OD nvarchar(20),@OF int,@LIM int',  
               @OC=@order_col, @OD=@order_dir, @OF=@offset, @LIM=@limit  
END

Вам необходимо присвоить параметры переменным для sp_executesql. (Вы уже объявили его, но не присвоили (забыли использовать знак равенства).

CREATE PROCEDURE spBaseVoterIndex  
    @order_col NVARCHAR(191) ,  
    @order_dir NVARCHAR(10) ,  
    @offset INT,  
    @limit INT 
AS
    SET NOCOUNT ON;  
BEGIN
    DECLARE @sql NVARCHAR(MAX)

    SET @sql = 'SELECT id, name_voter, home_street_address_1, home_address_city FROM dbo.base_voter'  
            +' WITH(NOLOCK)'  
            +' ORDER BY @order_col @order_dir'  
            +' OFFSET @offset ROWS'  
            +' FETCH NEXT @limit ROWS ONLY' 

    SET @sql = REPLACE(@sql,'@order_col',@order_col)
    SET @sql = REPLACE(@sql,'@order_dir',@order_dir)
    SET @sql = REPLACE(@sql,'@offset',@offset)
    SET @sql = REPLACE(@sql,'@limit',@limit)

    EXECUTE sp_executesql @sql

END

Кстати, в нединамическом SQL OFFSET и FETCH NEXT принимают переменные INT. Итак, вы можете, например, использовать его (напрямую) следующим образом:

SELECT 
    id
,   name_voter
,   home_street_address_1
,   home_address_city 
FROM 
    dbo.base_voter
ORDER BY id
OFFSET @offset ROWS
FETCH NEXT @limit ROWS ONLY

Но это заставит вас использовать фиксированный порядок (что, кстати, не является реальной проблемой). Если вам нужно использовать порядок по, вы можете использовать метод ROW_NUMBER, примерно так:

SELECT * FROM (
SELECT 
    id
,   name_voter
,   home_street_address_1
,   home_address_city 
,   ROW_NUMBER() OVER(ORDER BY @order_col + @order_dir) RN
FROM 
    base_voter
) D 
WHERE
    RN > @Offset
AND RN <= @Limit + @Offset

это даст вам те же результаты, что и OFFSET и FETCH NEXT

Надеюсь, когда-нибудь это будет полезно.

Это не работает - вы не можете параметризовать ASC таким образом. Вам нужно буквально соединить строки.

Хорошая идея - добавить санацию строк, чтобы остановить SQL-инъекцию.

CREATE PROCEDURE spBaseVoterIndex  
    @order_col NVARCHAR(100) ,  
    @descending INT,  
    @offset INT,  
    @limit INT 
AS
    SET NOCOUNT ON;  
BEGIN

   DECLARE @sql NVARCHAR(MAX)
   DECLARE @OD varchar(4) = 'ASC'

   -- Default is ascending. Pass in 1 to order descending
   IF @descending = 1 THEN SET @OD='DESC'

   -- If the order column is not valid, exit
   -- You need to put a list of valid columns in here
   IF @order_col NOT IN ('column1','column2','column3') RETURN


   -- Finally build and run the SQL
    SET @sql = 'SELECT id, name_voter, home_street_address_1, home_address_city'
               +' FROM dbo.base_voter'  
               +' WITH(NOLOCK)'  
               +' ORDER BY ' + @order_col + ' ' + @OD + ' '
               +' OFFSET ' + CAST(@offset AS VARCHAR(20)) + ' ROWS'  
               +' FETCH NEXT ' + CAST(@limit AS VARCHAR(20)) + ' ROWS ONLY'  

EXEC(@sql)

END

Что касается производительности, здесь есть две части:

1. Убедитесь, что у вас правильные индексы
2. Этот тип динамического SQL-запроса "кухонной раковины" всегда может иметь проблемы с производительностью, независимо от того, что вы не можете предварительно скомпилировать план запроса. Однако он никогда не пострадает от обнюхивания параметров.