Re: Why use OCI when there's Pro*C ?

In article <C30G2J.Avv_at_jbecpor.demon.co.uk>, smj_at_jbecpor.demon.co.uk (Martin Jarvis) writes:
|> Why do people use C and OCI when they could use Pro*C ?
|> What can you do with OCI that you cant do in Pro*C ?
|>
|> These are questions I have asked many times but can find no answer.

I find that Pro*C does not map nicely onto the OO paradigm. For example cursors are declared statically in Pro*C. It does not seem possible to write Pro*C code which creates a cursor and returns a pointer to it or another which destroys a cursor given a pointer to it. This is possible in OCI.

We are writing a data server which currently uses oracle at the back-end. Because a data server can simultaneously have many clients, using Pro*C would enforce a fixed number of possible cursors and thus a fixed possible number of possible server clients.

This is not a limitation that we wish to impose.

I hear that Oracle V7 is multi-threaded. I don't know if/when Oracle will support multi-threaded clients but when it does - I'm sure that static cursors won't be the go.

I don't know what is going to happen with Ingres as it doesn't even have an OCI interface. How many other RDBMS vendors do?

The Pro*C interface leaves me wondering "Why on earth did they do it like that?".

-- 
  +-----------------------------------------------+--------------------------+
  | Dave Campbell (dave_at_csis.dit.csiro.au)        |          |\     ____|\   |
  | Phone: + 61 6 275 0944   Fax: + 61 6 257 1052 | |\___   /\ \   / /    \  |
  | CSIRO Division of Information Technology      | | _  \ /  \ \_/ /  ____> |
  | Centre for Spatial Information Systems        | | |>  > __ \   / \ \___  |
  | GPO BOX 664          _--_|\                   | |__  /_/  \ \_/   \___/  |
  | CANBERRA ACT 2601   /      \                  |    \/      \/            |
  | AUSTRALIA           \_.--._/ <- Canberra      |  Get right, or get left! |
  |                           v                   |  Heb 2:3                 |
  +-----------------------------------------------+--------------------------+