|
It's nice to hear that I have the fundamentals down anyway! As for ODBC; yes I understand that we can turn the functions into stored procedures. That's the great thing about the 400 - the same *PGM can be CALLed from a command line or turned into a stored procedure via CREATE PROCEDURE. Why didn't we go that route from the get-go? Mostly a desire to keep things at a simple enough level to sell to my management and to the management of the outside vendor. I certainly won't rule out going that route as another means of access. Why not XML? Aside from the sheer terror of having to deal with yet another new thing on a short schedule? <grin> I haven't done enough XML work to be able to PROMISE delivery of the completed API on time. My fault for not keeping up, I suppose. With several suggestions to go that way, I can see that I had better start on an XML version. Fortunately, that won't prove terribly difficult, because I have a single function to wrap and unwrap the data. I need to visit XMLRPC.COM. Thanks for the link Don! MQ series is an expense we didn't want to impose on our end-users (we're a software house.) We wanted low/no end-user license fees. I deeply appreciate the comments, and will definitely be looking to expand my repertoire. I'm actually looking forward to the vendor requesting changes. I think I might be in front of the curve for once! Woo Hoo! Buck
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.