CREATE SQL VIEW exampl AS SELECT temp.* from temp where &pfilter

В VFP 9 - Syntax Error

Нельзя ли вернуть прежнюю функциональность для такой кострукции

forum.foxclub.ru



[i][small][color=Gray]Отредактировано (29.06.04 08:03)

Цитата:

CREATE SQL VIEW exampl AS SELECT temp.* from temp where &pfilter
В VFP 9 - Syntax Error

Нельзя ли вернуть прежнюю функциональность для такой кострукции

Здравствуйте, Alex!

В VFP9 должно работать &?pfilter:

Aleksey Tsingauz
Visual FoxPro Dev Team

Т.е. в релизе будет работать? Ибо в Public Beta не работает Равно как и в VFP8 оно не работает, приходится извращаться - создавать вьюхи из VFP7 или лазить в потроха dbc дабы вернуть такую приятную штучку представлениям

Здравствуйте, Igor!

Цитата:

Т.е. в релизе будет работать? Ибо в Public Beta не работает

Код, который я запостил, работает в Public Beta без проблем. Желательно, чтобы зависящие от этой функциональности убедились, что их сценарии работают если View создается в такой же манере.

Aleksey Tsingauz
Visual FoxPro Dev Team

Все дело в предварительном определении:
pfilter=".T."
перед созданием CREATE SQL VIEW ...

причем USE ... NODATA, тоже требует задания значения pfilter

В 8-ке, работает такой код:




[i][small][color=Gray]Отредактировано (01.07.04 15:15)

А-а-а ступил... Я то на своих prg-ках создающих View пробовал - а они все
старые - ещё со времён VFP7 и там переменной не требовалось для CREATE. Вот
я и не увидел что починили... Звиняйте Надо пораньше спать ложиться

Цитата:

В 8-ке, работает такой код:

 * pfilter=".T."  
   CREATE SQL VIEW exampl AS SELECT temp.* from testMacro temp where &pfilter

В девятке этот код работать не будет (BY DESIGN). Как нужно использовать макро подстановку в CREATE SQL VIEW я уже показал.

Aleksey Tsingauz
Visual FoxPro Dev Team

спасибо за разъяснение вопроса

Цитата:

причем USE ... NODATA, тоже требует задания значения pfilter

А вот это есть крайне плохо. Видимо придётся отказаться от такой приятственной особенности и таки перейти на CA Кстати в одном из вопросов по фоксу (ну да там вопросник старый - ещё по VFP 6.0) на BrainBench.com фигурирует данная фишка

Цитата:

Цитата:

причем USE ... NODATA, тоже требует задания значения pfilter

А вот это есть крайне плохо.

А что, так сильно ломает проинициализировать переменную?

Для курсора положенного в DE формы с пропетью NoDataOnLoad? PUBLIC переменые
т.е. плодить?Конечно ломает! А отказываться полностью от DE... Ну оно
конечно же можно, но вот нужно ли... Для разработчиков вешь вполне удобная
IMHO, голым USE-ом пользоваться не есть хорошо, а делать класс который
повторял бы полностью функциональность DE и Cursor - тоже не очень
хочется...

Цитата:

Для курсора положенного в DE формы с пропетью NoDataOnLoad? PUBLIC переменые
т.е. плодить?Конечно ломает! А отказываться полностью от DE...

Игорь, к чему такие крайности? Сначала полностью отказываемся от View, теперь полностью отказываемся от DataEnvironment. Просто конец света какой-то.

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

Раньше, когда View открывалось с NODATA, все начиная с WHERE просто отбрасывалось и заменялось на WHERE .F. Это имело ряд недостатков начиная с того, что синтаксис не проверялся и кончая тем, что типы полей могли быть определены неаккуратно и попытка REQUERY генерировала ошибку. Отчасти с целью решения этих прблем и отчасти в связи с добавлением новых воможностей в SQL, стало просто необходимо компилировать SELECT команду так как есть, без всяких там трюков с вырезанием "ненужных" частей. A если переменная не определена, SELECT команда с макро-подстановкой не компилируется, отсюда и ошибка.

Соответственно встает вопрос: "Что лучше?" Старый SQL + старые проблемы с NODATA + макро-подстановка в старом виде или новые возможности в SQL + решение проблем с NODATA, но незначительное неудобство с макро-подстановкой. Для меня выбор однозначен. Что такое необходимость проинициализировать переменную по сравнению с гибкостью и мощью макро-подстановки? Или в сравнении с новыми возможностями в SQL? Да это просто мелочь, мизерный "налог" на право использования недокументированной функциональности (между прочим subject to change any time without any notification). Как говорится, любишь кататься, люби и саночки возить. Жалко что поведение изменилось? Конечно жалко, но иногда чем-то приходится жертвовать. Вы, конечно, можете быть не согласны, но мне кажется, что нам удалось свести жертвы к минимуму.

Aleksey Tsingauz
Visual FoxPro Dev Team

Я просто не видел удовлетворительного решения своей проблемы. С глобальной
переменной работать не есть хорошо к счастью даже объявленная как LOCAL
переменная перед вызовом формы удовлетворяет движок...)

Цитата:

это не было специально запрограммированной/запроектированной
функциональностью

Я и не сомневался. Равно как и возможновть
создания хуков (SCREEN в частности)- которые как это ни парадоксально были
описаны в хелпе VFP8 (хотя в VFP8 имеется более "правильный" и главное
штатный механизм перехвата) но с выходом SP1 перестали работать...

Т.е. новое поведение направлено в частности и на борьбу с Error 1494? По
правде говоря она меня очень мало беспокоила (ну в смысле я всегда явно
задавал размеры полей если это могло быть неоднозначно - пробелами там или +
0000.00 дополнял до нужных параметров). А теперь стало быть это уже не столь
актуально (в плане ошибки конечно, не в плане возможного "урезания"
результатных полей, урезание то никуда не делось... Ну в смысле структура по
прежнему по "первой" записи определяется. В запросах вообще, где нет явного
задания размерности полей)

Цитата:

Что такое необходимость проинициализировать переменную

Ну
если бы можно было её как-то так (точнее "где-то там в форме") определить,
чтоб не делать "вовне"... В том же DE.BeforeOpenTables или DE.OpenTables
например... Ну да бог с ним, работает с LOCAL из метода запускающего форму
(хотя это конечно тоже может быть изменено но с PRIVATE то она точно
никуда не денется...) и то сойдёт.

Цитата:

Цитата:

это не было специально запрограммированной/запроектированной
функциональностью

Я и не сомневался. Равно как и возможновть
создания хуков (SCREEN в частности)- которые как это ни парадоксально были
описаны в хелпе VFP8

С хуком вообще недоразумение вышло. Кто-то из пользователей прислал тот код с предложением включить его в документацию как "крутой" пример. Ну вот и включили себе на шею.

Цитата:

Т.е. новое поведение направлено в частности и на борьбу с Error 1494?

Да, в частности на борьбу с этой ошибкой когда View определено с использованием UNION. Плюс на поддержку подзапросов в SELECT списке и во FROM.
Проблема определения размера полей по первой записи остается, но может быть решена с помощью функции CAST.

Цитата:

Ну
если бы можно было её как-то так (точнее "где-то там в форме") определить,
чтоб не делать "вовне"... В том же DE.BeforeOpenTables или DE.OpenTables
например...

Всегда есть возможность открыть View вручную в BeforeOpenTables или в OpenTables, тогда можно обойтись локальной переменной.

Aleksey Tsingauz
Visual FoxPro Dev Team