2014-09-18 2 views
0

Я использую программное обеспечение, известное как FME Desktop. В этом программном обеспечении мы можем выдавать команды SQL через элемент, называемый трансформатором. Я использую трансформатор, называемый SQLExecutor, который использует очень простой запрос для сравнения. Ниже приведено объяснение того, что я пытаюсь сделать с этим SQL-запросом, и тот факт, что он не работает при попытке сравнить 2 текстовых поля.SQL - Сравнить 2 текстовых поля

Я считаю, что моя проблема - это ограничение SQL при использовании в SQLExecutor. Предположим, у меня есть слой данных, называемый TEST.LEASE, и я хочу сравнить его со слоем EDIT.LEASE на основе одного уникального поля идентификатора. Оба эти уровня находятся в одной базе данных. Мы используем SQL Server для хранения данных. В обоих слоях, называемых GIS_ID, есть поле TEXT. Это уникальное поле идентификатора. Итак, что происходит, мы получаем обновления на нашем уровне LEASE, и они начинают загружаться в TEST.LEASE. Когда мы выполнили наш QA/QC данных, и мы удовлетворены тем, что они готовы быть загружены в EDIT.LEASE, затем мы запускаем работу FME, которая служит нашим инструментом продвижения. Что делает этот инструмент для продвижения, так это то, что он проверяет различные поля в TEST.LEASE, чтобы убедиться, что они могут быть загружены (эта часть работает без проблем).

Перед тем, как продвинуться на EDIT.LEASE, нам нужно знать, будет ли это совершенно новая запись, и в этом случае мы сделаем INSERT с FME. Если случайно GIS_ID уже существует, нам нужно сделать UPDATE для этих записей. Инструмент, который у нас есть, отлично подходит для определения, является ли это INSERT или UPDATE, за исключением одной, казалось бы, маленькой вещи ... ТОЛЬКО РАБОТАЕТ, ЕСЛИ ТЕКСТОВОЕ ПОЛЕ СОДЕРЖИТ НОМЕР, КОТОРЫЙ НЕ ИМЕЕТ ПИСЬМО В ЭТОМ.

FYI: Кто-то из нашей компании решил сделать поле GIS_ID текстовым полем. По-моему, это должно было быть целым полем, потому что сравнение было бы очень просто. Но я не могу изменить это сейчас, это уже было принято людьми, которые зарабатывают больше денег, чем я, потому что это будет текстовое поле.

Как указано ... GIS_ID - это текстовое поле (в обоих слоях и оба одинакового размера, в обоих слоях нет разницы). Как вы, возможно, знаете, SQL все равно, является ли это поле TEXT или поле INTEGER, когда все, что содержится в этом поле, является числом. Он все равно сравнивает 202 - 202, чтобы увидеть, равны ли они друг другу. Например, у меня есть запись как в TEST.LEASE, так и в EDIT.LEASE, где оба поля GIS_ID равны 09198760. Когда я запускаю запрос ниже, он работает отлично.

select OBJECTID 
from TEST.LEASE_UPDATE_INSERT_WRITER 
where GIS_ID = @Value(GIS_ID) 

Он работает отлично, как я уже упоминал, по данным, если в обоих текстовых полях GIS_ID есть только цифры. Но если только одна запись содержит фактическую альфу, запрос SQL будет выходить из строя.

Так что если GIS_ID имеет 09198760a01, когда запрос достигает значения «a» в GIS_ID, возвращается ошибка SQL. Я не ищу способ продолжить работу и игнорировать эти записи, потому что мне нужно ВСЕ ЗАПИСИ загружаться. Мне нужно знать, сможет ли кто-нибудь узнать, как добавить или переписать запрос выше, чтобы он загружал как «текстовые поля с номером», так и «цифры, содержащие поля букв».

Надеюсь, что объяснение будет понятным. Пожалуйста, дайте мне знать, если это не так. Спасибо за любую помощь вы могли бы быть в состоянии обеспечить для меня

С уважением, Tex

ответ

0

Джефф прав и как общий ответ для обычных пользователей SQL и даже людей, использующих SQL в коде приложения, если вы сравнивая текст, как указано выше, тогда вам нужно использовать одиночные «кавычки».

Где Avalue = «MyValue»

В противном случае SQL Server считает, что это ИНТ, следовательно, почему это работает, когда значение он проходит в только числа. Не всегда легко понять, в чем проблема, когда вы передаете параметры.

Где Avalue = @myvalue

Так что вам нужно обратить внимание на то. Просто хотел упомянуть об этом, поэтому, возможно, это помогает кому-то еще с подобной проблемой. Я понял это, когда мы получали ошибки из поля, которое объединило поле id, т. Е. Оно работало, когда значение = 2, но не 2,3 и т. Д. Обтекание параметра в одинарных кавычках легко фиксировало, что, поскольку мы действительно были связаны только с value = '2' в нашем случае.

Надеюсь, что это имеет смысл.

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