Hi __Владимир__!

Ты серьёзно полагаешь, что столь "вольное" обращение с таблицей, с которой
будет работать SELECT в UDF не приведёт к весьма печальным последствиям? Ну
что-ж, блажен кто верует...
Или может стоит процитировать соответствующий раздел хелпа...

User-Defined Functions in SQL SELECT Statements
You can specify expressions containing user-defined functions for
Select_Item in SQL SELECT statements. However, note the following
recommendations and restrictions when using user-defined functions in SQL
SELECT statements:

Use API and user-defined functions written in C or assembly language instead
of performing high-volume manipulations with user-defined functions. The
speed at which user-defined functions are executed can limit the speed of
operations performed with SQL SELECT.

Assume nothing about the Visual FoxPro input/output (I/O) or table
environment when using user-defined functions in SQL SELECT. In general, you
do not know which work area is selected, the name of the current table, or
even the names of the fields being processed. The value of these variables
depends on the precise location in the optimization process where the
user-defined function is called.

Do not change the Visual FoxPro I/O or table environment in user-defined
functions called in SQL SELECT. In general, the results can be
unpredictable.

Use the argument list that is passed to the function when it is called as
the only reliable way to pass values to user-defined functions in SQL
SELECT.

Understand that "forbidden" manipulations might provide results in one
version of Visual FoxPro but might not work in later versions.

Outside of these restrictions, user-defined functions are acceptable in SQL
SELECT statements. However, remember that using SQL SELECT in general might
slow performance.

Уж сам посмотри какие из указанных тут пунктов ты нарушаешь...

P.S. Кстати в Oracle давным давно есть специального рода конструкция в
запросах, для "разузлования" иерархических структур - как "вверх по
иерархии" так и в обратном порядке. Я не в курсе реализована ли такая
функциональность в каких либо иных СУБД...
Но уж если делать на UDF - то писать эту UDF надо ОСОБЕННО тщательно - и без
рекурсии, и позаботившись об "изоляции" тех курсоров с которыми работает
собственно SELECT от "рабочего" курсора в UDF.
Если же важна высокая производительность, то наверное стоит подумать о
некоторой денормализации структуры, введении разного рода хитрых
оптимизационных полей - ну например поля, в котором хранится в
"закодированном" виде весь иерархический путь - от корня до данного
объекта - и соответствующие процедуры для "пересчёта" этого поля...

Posted via ActualForum NNTP Server 1.3

Hi __Владимир__!

Да нет, UDF такого рода будут работать много где (хотя почти всегда это
будет являться наименее оптимальным вариантом из всех возможных) - главное
при их написании соблюдать известную аккуратность и учитывать требования
используемого языка.

Posted via ActualForum NNTP Server 1.3

Hi Владимир!

> UDF - далеко не единственный способ. И вообще, Select-SQL не всегда самый
> быстрый способ получения выборки

А вот когда внутри UDF используется SELECT (даже если она идёт в массив), а
потом эта самая UDF используется в другом SELECT - то это вообще жутко
медленно :)
Ибо огромные затраты на собственно "вызов UDF" (А для SELECT таких вызовов
будет столько, сколько записей попадает в отбор!) И очень велики затраты на
разбор и выполнение SELECT-а (а таковых действий как раз и будет столько,
сколько раз вызывается UDF).

Впрочем тут вопрос скорости не стоит, так что можно действительно
использовать UDF - НО его нужно написать ОЧЕНЬ корректно - так чтобы не
нарушать принципов описанных в хелпе. В частности "поиск" производить не по
тому же самому курсору из которого идёт отбор, а открыть через USE ... AGAIN
ещё один курсор для данной таблицы - и уже в нём искать... Я бы наверное
заодно избавился от рекурсии в пользу цикла (чтобы снизить затраты на
многократный вызов UDF) - пусть это и приведёт к чуть более массивному коду.

Posted via ActualForum NNTP Server 1.3