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.

> Vulcan has SQL inside the engine (folks, a SQL engine should actually
> support SQL). So it doesn't need the loop back. The internal SQL
> engine could support external engines as well. It is cleaner, faster,
> and doesn't break the architecture.

Not sure anyone will notice it to be faster. But what about cleaner and OK
from architecture POV - certainly. One question - what do you mean under
capability for internal SQL engine to support external engines?