Нужно, чтобы запрос (упрощенный )
выдавал только 2 значения 'usd' и 'rur'. даже, если в таблице есть значения 'u','us' и 'ru'
Пока не получается
set exact on как то не влияет, вроде
помогите, пожалуйста



Исправлено 1 раз(а). Последнее : Артём, 28.06.19 23:47

По быстрому, если ALLTRIM приделал, то можно
WHERE ALLTRIM(coin1)+" " in ('usd ','rur ')
А потом подумать

of63
По быстрому, если ALLTRIM приделал, то можно
WHERE ALLTRIM(coin1)+" " in ('usd ','rur ')
А потом подумать

Спасибо, так вполне устраивает. Ура!

SET ANSI ON

Igor Korolyov
SET ANSI ON

Спасибо! Теперь я знаю все!

ru.wikipedia.org

Igor Korolyov
SET ANSI ON

Вот это просто плохое в VFP. Но уже поздно говорить. Должно было на уровне языка иметь 2 вида сравнения - точное или типа почти, типа слева
Считайте, что я этого не говорил,это мои эмоции. Но сам я это решил, причем хреново решил, в своем Framework'e.
Глобально не решил



Исправлено 2 раз(а). Последнее : Ydin, 30.06.19 19:12

Ydin
Вот это просто плохое в VFP.

+100500

Нормальное это, а не плохое. Маленький нюанс в использовании сленга SQL-FOX (ведь это не настоящий SQL-диалект, типа оракла, так, местный синтаксис, естественно фоксоязычноподдерживаемый (хоть фоксовые функции можно применять). Практически это произвольные фоксовые выражения, вызываемые в синтаксисе популярного синтаксиса SQL. Устарел, конечно,синтаксис, нет новомодных фигней, но пока для дебильных отчетов хватает. Недебильных отчетов родное государство пока не спрашивает, уже хорошо.

Не понял. В фоксе именно и есть 2 типа сравнения. И для "просто сравнений" они решаются при помощи указания либо одиночного либо двойного символа равно (в SQL запросах), однако для "неявных" сравнений, как в случае с IN уже приходится использовать SET.
И да, "точное/неточное" в SQL запросах (управляемое SET ANSI) и "точное/неточное" в обычном процедурном коде (управляемое SET EXACT) - это две большие разницы.
А вообще в "больших" СУБД есть здоровенная такая заморочка со сравнением строк - последовательности сортировки (collation), нормализация юникода, игнорирование регистра, игнорирование "акцентированных" символов - там сам чёрт ногу сломит, порой И это даже не приближаясь к вопросам полнотекстового поиска

2 ИК.
Я про свой Framework. Там вся бизнес логика вынесена за то, что в Exe-файле
А там можно менять SET ANSI в любом месте и это на весь сеанс.
В реальной жизни когда в проекте неск. программистов и каждый может поменять SET ANSI, это стремно.
Поэтому мне не нравится этот Set ANSI.
Да хоть и один пишет! Вот кнопка - вызов чего то. Отладили, оттестировали.
Через год вставляют новую кнопку, где то в коде меняя Set ANSI. Отладили эту кнопку.
Теперь, если с этой кнопкой работали в этом сеансе, то потом первая кнопка может не работать. Но ошибку не выдает. И только юзер потом замечает.
И то не сразу. Пару отчетов неверных выдал.
Пишет нам, а мы не ловим эту ошибку...
Она дорого обходится. Говорим, плавающая ошибка.
Нас спасает то, что у нас мало кто знает эту команду.
В принципе, надо запомнить старое значение, чтобы потом восстановить.
Кто это делает?



Исправлено 1 раз(а). Последнее : Ydin, 01.07.19 18:01

Ydin
В принципе, надо запомнить старое значение, чтобы потом восстановить.
Кто это делает?

Любой адекватный программист

Да, к сожалению эта настройка (как и многие другие) по сути есть private переменная (область её определения - datasession) со всеми вытекающими последствиями. И для превращения подобных set в локальные сущности без запомнил-поработал-вернул не обойтись. Ну или полностью рули своими скоупами (т.е. в данном случае датасессиями) - считая что никто не влезет внутрь и не передёрнет никаких настроек. Организационно пытаясь побороть системную проблему.

То есть не любой

Ydin
То есть не любой

Ну а зачем беспокоится за ид... неадекватного то

Они мне говорят, что ошибка у меня в моем Фреймворке. Я долго ищу, потом им говорю, что не у меня.
И сразу забыли все



Исправлено 1 раз(а). Последнее : Ydin, 01.07.19 21:08

Если фреймворк достаточно открыт и позволяет произвольный код вносить да так что это повлияет на основную функциональность, то это таки твоя проблема - либо обеспечить такую изоляцию системной части, что подобными глупостями её не поломать, либо документировать все подобные "нюансы" (гораздо быстрее "не тот" SET COLLATE всё сломает чем SET ANSI).
Честно говоря я не уверен что для кода фреймворка будет иметь значение эта установка. А прикладной код - так за него должен не автор фреймворка отвечать, а тот кто этот код писал. Ну и да, я упомянул про способы минимизации ущерба - приватные датасессии сводят "поломку" к единственной датасессии (единственной форме).

Да, все именно так