Hi!

Just for your note:

My beleive is that most of the complexity in queries could be eliminated by proper database model and making special organization of data. Anyway, what you think about VFP is not always correct. I thought for 3 years that "REPLACE ALL" command is very reliable, however, once it failed on a long table without a single reason.

I do not want to say that VFP is not reliable at all or that you should not trust particular functionality in VFP. I want to say that VFP is VERY complex system. As a result, certain things are not predictable. For such things MS just DO NOT RECOMMEND to do something. Even when you see that 1000 times something works, at 1001 time at 1001 computer it might fail. Just because no guarantee - MS did not made complete tests and logic analizing for that prticulat functionality.

Its up to you - use ot not to use such things. Anyway, recommendation is not to use subqueries in the UDF function called from the SELECT or other SQL statement. Specially, this works quite slowly compare to the use of another approaches, as I already described based on your sample. I beleive in 90% UDFs could be eliminayed from the query and this usually speed up a query greatly (unless you select little number of records in the query).


>Vlad, I have 100 or more complex sql with self made functions, 50% of them use
>sql . Many of these are much more complex, than sample, I used in question
>and all these works. And all these works, tested on big bases and so on.
>I pretty sure , that VFP SQL is more weak, than SQL in Oracle, but it is still powerfull enough to make such queries. The clue was in something else.
>For example, if I thrown function nsgn from query ( this function has not any query, this is just sign for sum) the query does not fail. It is strange, that it does not fail, if cursor is used instead of array in function.
>It it rather difficalt to find other instrument ( not sql) for 'bookkeeper' tasks like
>'main book', 'company balans' and so on. I have code written on Cliper for this and it 20-25 more big, than SQL ways of solutions. Unforturnatly I started DB programming after Cliper and mad hands are not trained on old fashion of db programming.