Alex Peshkov wrote:

> On Friday 28 December 2007 19:58, Jim Starkey wrote:
>
>> First, the exec_stmt2 impementation was a crude hack. It underlying
>> problem is that dynamic SQL wasn't available in the engine. Rather than
>> fixing that, he took a shortcut.
>>
>
> Unfortunately, there was one more reasoning (don't want to say now, is it
> enough serious or not). Making yValve handles available for external engine
> lets it use our standard API. I still continue thinking that having pure
> virtual class for interface which may be filled with standard API calls (for
> debugging purporses for example) or internal engine calls is much better
> solution. But if we release external engines with current exec_stmt2
> impementation (working with yValve handles), no later DSQL/JRD merge will
> help us avoid backward compatibility problems, and we will have to keep that
> hack till the end of days. That is what seems for me the worst in exec_stmt2.

Didn't you agreed that using internal engine handles will be possible
after DSQL/JRD/Y-Valve re-architecture?

External engines is a client and should be able to use the client API,
and (unfortunately) it is currently the ISC API.


Adriano