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.
>
>Regards,
>
>Martin
>

In many ways, it's a matter of style choice (especially for static queries). However, Pro*C doesn't fully support dynamic queries (those that are built on the fly at runtime). Even using Method 4 dynamic SQL, one needs to allocate cursors at compile time.

With the OCI calls, one can allocate and use cursors whenever necessary.

For 95% of the applcations that aren't fully dynamic in nature, this reason may seem insufficient. For those 5% that require fully dynamic operations, it's a life saver.

Other non-essential reasons to use OCI calls:

1. It's a real pain to debug post-pre-compiled code since what's going through the debugger isn't what you wrote.
2. If you're writing your own network drivers, it's useful to have a well defined API to use as templates for your stubbs and RPCs.
3. I've heard (but haven't established for myself) that one gets better peformance from the OCI calls.
4. The calls are similar (in function) to the emerging Sql Access Group Call Level Interface. Although not exact, the paradigms are close.
5. [Insert your favorite reason here]

Having said this, I used the embedded SQL most of the time and reserved the OCI stuff for when it was necessary.

--