|
Inline At 10:31 AM 4/10/02 -0500, you wrote: > > From: John Taylor > > > > The CLI is not a communications protocol; it's just a database API. > >I was looking at the CLI, and I saw a 10-character server name, which seemed >to me to be no more than enough to point to some table with the appropriate >communications information. Evidently this is the RDBDIRE table. One of >the entry types for the RDBDIRE allows you to specify an ARDPGM to handle >the requests. I suspect this would ne the first step down the slippery >slope to roll-your-own client/server communications. > > > > You don't really need a generic driver. You see, ODBC and CLI are > > virtually > > equivalent in terms of syntax, and semantics. The SQL CLI is a standard > > created by the X/Open Standards Group. ODBC is MS's implementation of that > > standard. Of course, they've "embraced and extended" it, but they remain > > very similar. > > > > The big trick is how to get the two machines communicating. > >So what this means is that, in addition to having a CLI-capable SQL engine, >you must also support a standard communication API, right? How do I know >which comms APIs a given SQL engine supports? Or is that yet another piece >that I have to download and install? > >And in the case of, say, an ODBC request from Windows to Oracle running on a >Linux machine: How do I tell the ODBC wrapper on Windows the location of the >database on the Linux machine? How do I tell the ODBC wrapper what comms >protocol is being used? Or is there a default comms protocol that ODBC >uses? > >Wow, every time I peel a layer off this onion, I cry harder <grin>... I think this'd be sockets in the TCP/IP realm. Quite standard. > > Personally, I don't see why anyone would bother. The conventional argument > > is that they wish to read/update a remote database directly > > through RPG, but > > I wonder if they aren't thinking in terms of doing a simple > > READ/CHAIN et al > > against Oracle. Because that's not the way it works. > >No doubt - CLI is way different than native I/O. CLI is just a way to handle SQL between possibly disparate machines. > > Call me crazy, but I'd much rather just use JDBC. > >How does JDBC simplify this mess? Because the JDBC type 3 driver sends the >request from machine to machine in a platform-independent way, thus allowing >the CLI request from the source machine to be directly executed on the >target machine? Bingo. As I mentioned in another post, conversion to each database's SQL syntax has to be done somewhere. CLI/ODBC do it on the client, JDBC on the server, I think, anyway. >Joe > >_______________________________________________ >This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list >To post a message email: MIDRANGE-L@midrange.com >To subscribe, unsubscribe, or change list options, >visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l >or email: MIDRANGE-L-request@midrange.com >Before posting, please take a moment to review the archives >at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
