>>>Besides, we still use a lot of quick'n'dirty xBase code. And - "the million dollar question... why?" , well, comes to an easy answer: it works. Of course, it has its perils, but we know them well, and know how to handle them. So, "a question for another million - why not?"
>>
>>It really depends on the code, so, personally, I'd have to see an example to answer that question.
>>
>>It's true that not everything is best handled by an OOP approach, but most of what I've seen is.
>
>Rules in art exist, with the sole purpose of recognizing the masters of it - they are the ones who break them and set the new ones. And get away with it.
>
>Now, if programming is an art...
>
>Philosophy aside - whenever there's a doubt whether we should play clean and by the book, or just quick'n'dirty, we should play clean. It's just the few cases, which it takes an act of master to recognize, we'd decide to break the rule. That's probably the sign that the rule simply doesn't apply to this case, or is just plain stup... unfinished.
>
>Example? Can't imagine anything convincing enough, but why not - Seek() /Scan While, in cases where we have 1) local tables, 2) large table with expected small recordset to retrieve. It can be more efficient than SQL Select, specially if we just want to recalculate couple of things and don't really need a cursor.

SCAN against SEEK is more than convincing example, however it's actually SCAN which allows to apply OO-approach (SCATTER NAME ...) against SQL-tectnology.