У меня был рабочий запрос FREETEXTTABLE, который искал @searchString. Теперь мне нужно СОЕДИНЕНИЕ, что с другим простым запросом, который пытается разобрать @searchString в INT, и если это удастся, отфильтруйте таблицу, ища строку с PK, равную parse @searchString.Заказ FREETEXTTABLE результат UNIONed со стандартным SELECT по рангу
Раньше я мог легко ПРИСОЕДИНЯТЬСЯ к результату FREETEXTTABLE в таблицу, которую он искал, упорядочить по Рангу, но только ВЫБРАТЬ столбцы исходной таблицы, которую искали.
Теперь, когда я комбинирую уникальные результаты между текстовым поисковым запросом и запросом, ищущим строку со строкой поиска в качестве ключа, у меня больше нет доступа к Рангу из текстового поискового запроса.
Как я могу поддерживать упорядочение по рангу полного текстового поиска, но поместить результат запроса в поисках строки с первичным ключом (если он имеет результат) ДО результатов полнотекстового поиска?
Я могу видеть действительность вашего answer-- вытягивать присоединиться от FREETEXTTABLE вызова и использования это * после * UNION. К сожалению, я не могу заставить его разбирать SQL. Это дает мне проблемы с использованием «Ранга» и «Ключа». Кроме того, если @searchString не является допустимым целым числом, будет ли CAST выдавать исключение? Первоначально у меня был блок TRY CATCH, чтобы установить значение, основанное на успешности конвертирования. Если литье прекращается изящно, я могу просто пропустить это. – Brandon
вы можете обернуть эту вторую часть соединения с помощью оператора case - я обновлю пример, чтобы это отразить. Что касается не разбора запроса - я не уверен, что может вызвать проблемы ... –
У меня были те же проблемы синтаксического анализа, что и тестовый запрос. Похоже, для этого нужны колонки KEY & RANK, которые нужно убрать. –