2015-05-14 2 views
0

Я разрабатываю доказательство концептуального приложения в соответствии с запросом клиента, чтобы он выступал в качестве системы автоматизации, которая выполняет первоначальный скраб входных данных. Одним из шагов этого процесса является просмотр поля описания и определение того, как это сопоставляется с приведенным в списке описания/кода клиента, чтобы получить конкретный код. Однако изначально из-за того, что входные данные не всегда были одинаковыми, я предположил, что я бы включил динамический SQL для передачи имени столбца поля описания ввода. Ниже приведен фрагмент кода, таким образом далеко (многоточие (...) представляют собой код продолжения для неизвестного расстояния в этой точке и на самом деле не в коде.):Динамический SQL, используемый в описании случая в хранимой процедуре

DECLARE @DESC VARCHAR(100) 
SET @DESC = '<sourceDescrptionColumn>' 

DECLARE @SQL NVARCHAR(MAX) 
SET @SQL = ' 
      SELECT 
       <sourceDescrptionColumn> 
       ,CASE WHEN(' + @DESC + ' LIKE ''%club%'') THEN ''00'' 
        WHEN(' + @DESC + ' LIKE ''%ball%'' AND ' + @DESC + ' NOT LIKE ''%basket%'' AND ' + @DESC + ' NOT LIKE ''%base%'') THEN ''01'' 
        WHEN(' + @DESC + ' LIKE ''%glov%'' AND ' + @DESC + ' NOT LIKE ''%bat%'' AND ' + @DESC + ' NOT LIKE ''%golf%'' AND ...) THEN ''02'' 
        ... 
        ESLE ''99'' 
       END AS DESC_CODE 
      FROM <someInputTable>' 

Это будет работать примерно первый 30 или так «WHEN», а затем он начинает терпеть неудачу. Кажется, это проблема с использованием одиночных кавычек, но я не могу найти источник.

Существуют ли ограничения на количество символов AND или WHEN, которые могут использоваться в этом типе использования SQL? Есть ли лучшая альтернатива?

+0

Можете вы рассказать о "fail"? Сообщение об ошибке? Не возвращает правильные результаты? Я предполагаю, что «ESLE» - это просто ошибка копирования и вставки. И что '@ DESC' никогда не будет содержать никаких символов, которые могли бы разойтись. – HABO

+0

Существует ограничение размера партии, указанное здесь (https://msdn.microsoft.com/en-us/ms143432.aspx), но по умолчанию 64K * 4K это не похоже на проблему. Это может быть даже неприменимо, если движок базы данных бормочет сам с динамическим SQL. – HABO

+0

Таким образом, ошибка, которую я получаю, является синтаксической ошибкой, но она меняет углубление на число операторов WHEN в заявлении CASE. Например, когда у меня есть 31 WHENs в заявлении, он скажет что-то вроде строки «неправильный синтаксис рядом с« L », когда у меня есть 32 WHENs в заявлении, он скажет что-то в строках« неправильный синтаксис рядом », LIK ", так далее и т. Д. Насколько я вижу, нет никаких лишних символов, которые могли бы вызвать проблему. – Hukd

ответ

1

Что может случиться, так это то, что ваши данные усекаются, как указывали другие. Теперь, если вы не используете символы Unicode, я бы рекомендовал придерживаться только Varchar. В любом случае, просто установите все свои переменные на max, и это должно исправить ваши ошибки усечения. И причина, по которой вы считаете, что это ваши кавычки, заключается в том, что если усечь котировки, конечно, у вас будут закрытые цитаты!

DECLARE @Desc VARCHAR(MAX) = '<sourceDescrptionColumn>'; 
DECLARE @SQL VARCHAR(MAX); 
+0

В чем преимущество использования 'VARCHAR', когда документация для [' sp_executesql'] (https://msdn.microsoft.com/en-us/library/ms188001.aspx) указывает, что параметр оператора является строкой Unicode? – HABO

+0

Преимущество в том, что он вдвое меньше NVARCHAR. Что касается sp_excutesql с использованием NVARCHAR, он не упоминает об этом в своем вопросе. Насколько нам известно, он может просто использовать EXEC (@sql). – Stephan

+1

Спасибо, Стефан, это, кажется, ответ! – Hukd

Смежные вопросы