Here is why you cannot defend a point to save your life...


I said:

>>
For one thing - it is not native Fox. It is an FLL.... However, given that you would have to partition your tables, you would have other difficulties.
>>
>>Stick a fork in it...its done...
>

Then you conclude:

>False,


Then you say:

>
>I could come with an algorithm just doing this.


Right off the bat - how does this statement support your assertion that I was false????



>
In fact it is not even that difficult to implement. Just put a validation rule on the table which reads the words checks the existance of that word in a second table and with a little trick you can create and index on a word pointing to all records containing that word.
>

I suppose this would work - but I have not checked it out. Even if it does work - it pretty much obviates Mike's point about flexibility. I don't consider flexibility to be a relevant trait of a tool when I have to roll a lot of these things on my own.



>
Now don't come with the argument that you can't use a second table for it, because you have to use a simular thing in SQL server too. It is only hidden for the users.
>

You don't get Walter...the more work arounds and extra work you have to do -only goes to defeat Mike's point. Perhaps you could indeed argue that Fox is so flexible that you can indeed roll this stuff on your own. That may be true. But should flexibility come at the expense of efficiency? And of course, it is a theory in the air. This proposed solution may or may not work. Full text searching is an interesting beast and I am not sure what you propose would work.

< JVP >