× 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.



Thanks guys. My intent, for now, to have these functions within a single
service program, and have a single program calling them.
Again, that's my 'for now' intent. Tomorrow could lead me down something
different, so I will keep your emails, just in case.

As I had said, my beta's work great. I'm starting to build up more
intense queries and they are running perfectly,
and the extractions are giving me everything I need.

dav


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

www.dancik.com



"Kevin Wright" <Kevin.Wright@xxxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
08/17/2010 02:19 AM
Please respond to
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>


To
"RPG programming on the IBM i / System i" <rpg400-l@xxxxxxxxxxxx>
cc

Subject
RE: Anyone using SQLConnect, SQLPrepare, etc...






Correction:

2. We have encountered issues with retaining connection / prepared
statements interacting with a few IBM commands, namely CPYTOIMPFF &
CPYFRMIMPF which themselves use CLI under the covers.

We use the CLI from C.

Regards,

Kevin Wright

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Scott Klement
Sent: Tuesday, 17 August 2010 3:38 PM
To: RPG programming on the IBM i / System i
Subject: Re: Anyone using SQLConnect, SQLPrepare, etc...


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.