>>I don't want to eliminate it at all. But as I have said in other threads, I think we need an SQLExecute function that works for native data, so we can construct the SQL string and pass it to the function. This is how many other languages support SQL.
>
>I've mixed feelings about that one. First off all it could mean a performance penalty compared to embedded SQL commands (thus without &) because the statement has to be compiled first.
>
>Another is that if you're saying that we should execute SQL commands for local data with a SQLexec function

No, I said we should have the ability to.

> , why should we limit this mechanism to embedded SQL commands ? What to think about e.g. BROWSE, REPORT, REPLACE commands ? Should we also prepare them in strings and execute them ?

I don't see how that follows.