× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi, Scott

I saw the reference to ODBC and assumed it was there because IBM say that CLI uses some of the same routines as ODBC - that it is based on the same standards. That could cause some confusion, it seems.

This link is an FAQ about CLI on i - http://www-03.ibm.com/systems/i/software/db2/clifaq.html#header_2 and contains the following as the first question and answer -

Is CLI the same as ODBC?

For the most part, the SQL CLI is syntactically and semantically equivalent to ODBC. This is not to say that everything in the latest level of ODBC is supported, but an application that uses the most common routines will likely run against the CLI with few changes.

The SQL Call Level Interface is a standard created by the X/Open standards group, and our CLI was built in V3R6 according to that standard. ODBC is the Microsoft implementation of the X/Open CLI standard, and has veered off from the X/Open standard in a few areas. So, even though the CLI has been updated in several releases since V3R6, it will likely never match ODBC exactly, since that is technically not the standard that our CLI is built to comply with.

Vern

On 8/17/2010 12:37 AM, Scott Klement wrote:
I'm not totally sure what you're asking -- especially when you reference
ODBC (planning to connect to another system?) -- but I've used the SQL
CLI procedures quite a few times, and they seem to work well.

The only problem I keep running into is that only one program can be
using CLI at a time within a job. That can be a royal PITA if you are
coding modularly, where one procedure may be fetch from one SQL
statement, and then in a loop calling another modular routine that also
happens to use CLI. A little bit of caution is required to eliminate
that possibility.

But aside from that, they work great. Performance is about the same as
dynamic SQL called via the embedded SQL precompiler. It's not as fast
as static statements, though.



dmosley@xxxxxxxxxx wrote:
Hey guys,

I'm just curious to know is anyone is using the c procedures (in RPG) for
ODBC connections and the other SQL procedures.
I've got a great usage for these procedures, and have my beta running....
However, I'm new to these procedures
and am curious of any drawbacks, performance lags, etc, that may change my
mind. Or, (which I'm hoping), that this
is savior of truly dynamic SQL and I'm a fool for not using this in the
past. (haha)

Either way, I'd like to hear back from anyone with experience with these
procedures.

I add the "(in RPG)" statement in my first sentence so to make sure I stay
correct in the forums guidelines.
I did create a c-program to do what I wanted, but was able to duplicate
the whole process in RPG. (yeah).

Thanks in advance to any replies.
David


David L. Mosley, Jr.
Technical Solutions Architect
Dancik International, Ltd.
2000 CentreGreen Way, Suite 250
Cary, NC 27513

www.dancik.com

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.