I'm an Oracle guy that also read the docs.
Processing SQL Statements
One of the most common tasks of an OCI program is to accept and process SQL
statements. This section outlines the specific steps involved in processing
SQL.
Once you have allocated the necessary handles and attached to a server, the
basic steps in processing a SQL statement are the following, as illustrated
in Figure 4-1, "Steps In Processing SQL Statements":
Prepare. Define an application request using OCIStmtPrepare().
Bind. For DML statements and queries with input variables, perform one or
more bind calls using OCIBindByPos(), OCIBindByName(), OCIBindObject(),
OCIBindDynamic() or OCIBindArrayOfStruct() to bind the address of each input
variable (or PL/SQL output variable) or array to each placeholder in the
statement.
Execute. Call OCIStmtExecute() to execute the statement. For DDL statements,
no further steps are necessary.
Describe. Describe the select-list items, if necessary, using OCIParamGet()
and OCIAttrGet(). This is an optional step; it is not required if the number
of select-list items and the attributes of each item (such as its length and
datatype) are known at compile time.
Define. For queries, perform one or more define calls to OCIDefineByPos(),
OCIDefineObject(), OCIDefineDynamic(), or OCIDefineArrayOfStruct() to define
an output variable for each select-list item in the SQL statement. Note that
you do not use a define call to define the output variables in an anonymous
PL/SQL block. You have done this when you have bound the data.
Fetch. For queries, call OCIStmtFetch() to fetch the results of the query.
-----Original Message-----
From: Ali Zaidi [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 26, 2001 12:26 PM
To: [EMAIL PROTECTED]
Subject: Re: RE: Shorthand for $dbh->prepare and $sth->execute?
Being an Oracle guy i can tell for sure the steps taken by
Oracle
Prepare: In this step Oracle parses your query and prepares the
execution plan.
Execute: In this step Oracle gets the data returned by your
query into its memory area
Fetch: This is when the data is returned to the user process.
---- On Tue, 26 Jun 2001, Michael Peppler
([EMAIL PROTECTED]) wrote:
> Orlando Andico writes:
> > On Tue, 26 Jun 2001, Marcotullio, Angelo wrote:
> > ..
> > > In Oracle, the $sth->execute() builds the cursor and
waits for the
> program
> > > to start fetching records. The hints don't change this
behavior,
> just the
> > > access plan.
> > ..
> >
> > Hrmmm... that's not what I've seen. I wrote some code
which used
> > Time::HiRes to measure the time taken at each step..
something like
> this:
> >
> > $t0 = [gettimeofday];
> > $sth = $dbh->prepare ("SELECT * FROM
TEN_MILLION_ROW_TABLE");
> > print [gettimeofday] - $t0;
> >
> > $t0 = [gettimeofday];
> > $sth->execute;
> > # and so on..
> >
> > and definitely, the execute part took longest.. if what
you're saying
> is
> > true, execute would return immediately and let me fetch
records at
> will.
> > That does NOT happen. execute takes forever, THEN i can
fetch
> records.
>
> That's interesting - shouldn't such a select return *very*
quickly? It
> doesn't have to build a complex query plan, it just needs to
follow
> the page or row chain and return the rows in any order that
it wants
> to...
>
> Michael
> --
> Michael Peppler - Data Migrations Inc. - [EMAIL PROTECTED]
> http://www.mbay.net/~mpeppler - [EMAIL PROTECTED]
> International Sybase User Group - http://www.isug.com
> *Looking for new project to tackle starting 8/1/01*
>
>
________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag
