dbTalk Databases Forums  

the importance of Pro/C

comp.databases.oracle.tools comp.databases.oracle.tools


Discuss the importance of Pro/C in the comp.databases.oracle.tools forum.



Reply
 
Thread Tools Display Modes
  #21  
Old   
sybrandb@hccnet.nl
 
Posts: n/a

Default Re: the importance of Pro/C - 09-06-2008 , 08:50 AM






Comments embedded


On Fri, 05 Sep 2008 22:53:06 -0500, Michael Austin
<maustin (AT) firstdbasource (DOT) com> wrote:

Quote:
but, if you, as a dba support those databases the application developers
access, it is not a bad idea to be able to understand and read the code
for yourself.

Pro*C is a so-called Host Language Interface, or a preprocessor.
There is little special knowledge required to understand Pro*C.

Apart from that: Pro*C is little used. Oracle products internally use
OCI.
Most third party developers either use a Microsux interface (ODBC,
OLE, Ado, .NET) or -God forbid- jdbc, without paying any attention to
how their code interacts with the database. This means they usually
don't use PrepareStatement
Quote:
True DBAs are really Systems, Storage, Network, Application, Data and
Business Administrators/analyst. If you have ever worked for any
company of any size, if there is ANYTHING wrong in the environment, the
DBA always gets the first call.

This is caused by the two I's on the side of the developer: Ignorance
and Incompetency. One usually blames the part one knows nothing about.


Quote:
I believe that if you are a DBA you should be able to know enough of the
other disciplines to be able to troubleshoot any systemic problem and
that includes the programmer.

I don't think so. Most analysis can be executed by reading raw trace
files.
Whatever front-end the developer is using doesn't matter.
What doe matter is
- not using bind variables
- not using array fetches
- committing inside a loop

All of which can be determined from a raw trace file.
Quote:
Michael.
My 2 eurocents

--
Sybrand Bakker
Senior Oracle DBA


Reply With Quote
  #22  
Old   
sybrandb@hccnet.nl
 
Posts: n/a

Default Re: the importance of Pro/C - 09-06-2008 , 08:50 AM






Comments embedded


On Fri, 05 Sep 2008 22:53:06 -0500, Michael Austin
<maustin (AT) firstdbasource (DOT) com> wrote:

Quote:
but, if you, as a dba support those databases the application developers
access, it is not a bad idea to be able to understand and read the code
for yourself.

Pro*C is a so-called Host Language Interface, or a preprocessor.
There is little special knowledge required to understand Pro*C.

Apart from that: Pro*C is little used. Oracle products internally use
OCI.
Most third party developers either use a Microsux interface (ODBC,
OLE, Ado, .NET) or -God forbid- jdbc, without paying any attention to
how their code interacts with the database. This means they usually
don't use PrepareStatement
Quote:
True DBAs are really Systems, Storage, Network, Application, Data and
Business Administrators/analyst. If you have ever worked for any
company of any size, if there is ANYTHING wrong in the environment, the
DBA always gets the first call.

This is caused by the two I's on the side of the developer: Ignorance
and Incompetency. One usually blames the part one knows nothing about.


Quote:
I believe that if you are a DBA you should be able to know enough of the
other disciplines to be able to troubleshoot any systemic problem and
that includes the programmer.

I don't think so. Most analysis can be executed by reading raw trace
files.
Whatever front-end the developer is using doesn't matter.
What doe matter is
- not using bind variables
- not using array fetches
- committing inside a loop

All of which can be determined from a raw trace file.
Quote:
Michael.
My 2 eurocents

--
Sybrand Bakker
Senior Oracle DBA


Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.