D
dbeavon
Guest
So I guess all I was looking for was a way that an ABL programmer can leverage the more recent OE technology on the SQL92 side of things. That would complement our legacy ABL tooling, and leave a lot less query building work for the developer (put more of it in the hands of the DBMS). For example, even basic things in ABL leave a lot to be desired - like theway in which it has always picked indexes (when there are more than a couple). These days most DBMS products can find a better query plan than a developer can - at least in the vast majority of cases, with hints available in the rare cases where the cost-based optimizer gets confused. What I was going for was some kind of pass-thru where we could define a result set based on a SELECT query and then process that result set in ABL after it was generated from SQL92. It would be something along the lines of QUERY-PREPARE but would leverage the more advanced query optimizer in SQL92. /* Send to SQL92 Please! */ v_QueryHandle:QUERY-PREPARE("SELECT FOR EACH Table1, Table2, Table3 WHERE ...") /* ****************************************************************** */ /* Open and start non-indexed filtering */ /* ****************************************************************** */ v_QueryHandle:QUERY-OPEN(). REPEAT ON ERROR UNDO, THROW: /* Loop */ v_QueryHandle:GET-NEXT(). IF v_QueryHandle:QUERY-OFF-END THEN LEAVE. /* DO MY ABL WORK HERE! */ Anyway, I suppose the shelling to "sqlexp" is an option, albeit a very dirty one. It seems like OE should consider the benefits of combining their two totally separate worlds of ABL and SQL92.
Continue reading...
Continue reading...