Re: What's the best alternative to this pl/sql ?

Gabriel Gonzalez wrote:

> Otherwise, save yourself some time and create the SQL on the client. Make
> sure you use bind variables/parameters and prepared statements so that at
> least the parsed queries remain in the cache to speed up performance of
> repeat SQL statements. It should give you a speed boost anyway.

Sorry, I don't understand this. It sounds like bollocks to me.

How can you say that shifting the code from PL/SQL to something like C++ or Delphi or Perl or whatever, will boost speed?

What can you do in those languages ito of basic cursor processing that you can not do using PL/SQL? In fact, PL/SQL allows you to do it easier (you do not have rowtype variables in those other languages) and *inside* the database... right there where all the action occurs.

The problem as I see is not PL/SQL, but the original poster's lack of programming experience.

The programming language is simply the tool. It is the programmer's job to wield it correctly.

from :
ield1 = value1 and Field2 = value2
to:
Field1= value1[0] or Field1 = value1[1]

can be done with a :
Field1 IN ( value1, value2, value3 )

or a :
for i = 0 to length( array )
 call process_cursor( value -> array[i] ) end for

If dynamic arrays are to be used, you need to look at the REQUIREMENT first! The solution likely is NOT to use dynamic arrays in the first place as this is not supported by ANSI SQL in WHERE clauses.

I find it strange that a manager tells a programmer how to write his code. That is not the manager's job. Else, he can go ahead and try to write the code himself and just see how far he can get. (a sore point with me when managers who used to program in some obscure language 10 years ago, think they can advise you on how to program in today's OO and event driven environment).

--
Billy