home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / database / 8957 < prev    next >
Encoding:
Text File  |  1993-01-09  |  2.9 KB  |  65 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!spool.mu.edu!agate!rsoft!mindlink!a269
  3. From: Mischa_Sandberg@mindlink.bc.ca (Mischa Sandberg)
  4. Subject: SYBASE: Returning results over a network from a 'C' executab
  5. Organization: MIND LINK! - British Columbia, Canada
  6. Date: Sat, 9 Jan 1993 07:26:13 GMT
  7. Message-ID: <19411@mindlink.bc.ca>
  8. Sender: news@deep.rsoft.bc.ca (Usenet)
  9. Lines: 54
  10.  
  11. > lundell@gumby.mgi.com writes:
  12. >
  13. >  We are using Sybase as our database server running on an RS6000. The
  14. > clients are
  15. >  PCs running Microsoft Windows. We are able to call stored procedures from
  16. > the
  17. > clients and receive the result sets just fine.
  18. > However, I would like to be able to call a 'C' program directly (via an
  19. > RPC?)
  20. > from the client and have it return the result set identical to the stored
  21. > procedure. Is this feasible?
  22. Sure, you can do this, given a TCP/IP interface library and a fair bit
  23. of code. You'll learn all about the intricacies of registering RPC's,
  24. TLI for sockets (AIX is SVR4) and a bunch of other things. Your energy
  25. and enterprise are impressive.
  26. >
  27. > So my guess is that the 'C' program would use say use 'DBLib' to build a
  28. > result set from Sybase.
  29. Yup. And that leads to the question: could you express exactly why
  30. you want to do this? So far, it sounds like you want to do considerable
  31. work to accomplish no more than the existing interface ("identical",
  32. you say) with increased load on the network -- since your RS6000
  33. program will be talking TCP/IP internally to the dataserver, anyway.
  34.  
  35. The only thing I can figure (and correct me if I'm wrong) is:
  36. - you want to add some control code in this gateway server, to
  37.         limit user load, or something.
  38. - you want to work through a single thread (dblogin), perhaps so
  39.         that multiple clients can share tempdb tables (serially)
  40. - you want to do something more complicated than what Transact is
  41.         good for (no surprise), perhaps like symbolic processing
  42.         of table/field names.
  43.  - you figure you can do something more efficiently than a transact
  44.         procedure.
  45.  
  46.  If one of the latter is your goal, I would strongly suggest that you
  47.  knock the network side out of it, using the model gateway source
  48.  provided with the Open Server stuff; then let the dataserver in
  49.  effect handle your "exec myCustomerServer...myNiftyProcedure" calls.
  50.  If you really want to send back choking amounts of data to the clients,
  51.  read about the tabular data stream (TDS).
  52. >
  53. > Has anyone ever attempted something similar to this??
  54. Yes, the latter, but no, not the former. And it was to (more or less)
  55. answer the repeated question, "how can I pass a table name as a parameter
  56. to a procedure?".
  57.  
  58. --
  59. Mischa Sandberg ... Mischa_Sandberg@mindlink.bc.ca
  60.                  or uunet!van-bc!rsoft!mindlink!Mischa_Sandberg
  61. *-*-*-*-*-*-*-*-*-*-*
  62. Engineers think equations are an approximation of reality.
  63. Physicists think reality is an approximation of the equations.
  64. Mathematicians never make the connection.
  65.