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

huh ... JVPs´logic again...

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

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

Read again.... you´ll get a clue.. You said: stick a fork in it. it is done. My argument was FALSE. It is not done.....

>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.

It works... no doubt. So, iterating through collections in a ADO recordset as apposed to usings foxs database engine does not apply to this rule ?? get real....

>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.

Workarrounds: Just look at the example I´ve asked you to create in SQL and look at rods solution. Just build a test table and compare the performance and you´ll see that in this case it is just the other way arround.


John, your problem is that you are not beeing objective. you don´t make up a list of differences of the two approaches and do not identify the cases in which one particular feature has benifit over the other approach. You´re searching for arguments that only support your standpoint and ignore the other ones.

I do not have the same standpoint as MikeH. I do recognize the value of server databases. I do know the differences, advantages and disadvantages in specific cases. The conclusion is that there are cases where a local database engine makes sense, and others where a server database makes sense. You´ve got to weigh the advantages and disadvantages to make a decision.

You seem to totally miss this point. In all our conversations I´ve given numerous examples of the differences to defend upon your attack to the ´old fashoined´dbf style approach. You´ve proven not to have the proper background to claim to be the expert on this field. The only conclusion I can draw of you DEBATING is that you make vague claims that are full of holes and do not have any scientifical prove nor they´ve proven their validity in real life. Your view on this issue is seriously flawed. You don´t even have the smallest clue about what you´re talking about.

Walter,