Why? : ORA-06532: Subscript outside of limit

Question

I want to read a number of rows into an array of records.
I keep getting this error (any ideas?):
ERROR at line 1:
ORA-06532: Subscript outside of limit
here is the procedure:
CURSOR get_all_locations (type IN VARCHAR2) IS
SELECT
FROM group
WHERE type = type;
PROCEDURE fetchAllServerLocations IS
i BINARY_INTEGER := 0;
erec egroup%ROWTYPE;
BEGIN
dbms_output.enable;
dbms_output.put_line('BEGIN: fetchAllServerLocations()');
FOR erec IN get_all_locations('s')
LOOP
-- dbms_output.put_line('i=[' || i || ']');
dbms_output.put_line('server location: [' || erec.group_id || erec.name || ']');
allServerLocations(i) := erec;
i := i + 1;
END LOOP;
dbms_output.put_line('END: fetchAllServerLocations()');
END fetchAllServerLocations;
---

Answer 1

You have a (poor) solution in search of a problem.
PL/SQL will never be faster than plain SQL to access data within Oracle DB.You do not know what the problem is and you do not know the solution.
The only thing you know is a syntax error that I am having with a very small piece of code that is trying to do a very specific thing.
You have tried to reach too far and are blinded by trying to solve a big problem when there is really a small problem to solve.
<ranton>
I (we) have a well thought out solution and algorithm that will solve our problem. I am attempting to implement the solution that has already been analyzed over several weeks now by someone that has 10+ years of knowledge of what data we need to move around and where. The problem is unknown to you. The solution is unknown to you, yet you are making statements about both.
I cannot write procedures, functions and have them called in the order that I need with plain SQL. Also after the implementation is complete in PL/SQL it will be fast enough for what we need to do. The requirement I have is not to have the one time script run as blazingly fast as it possibly can at all costs to providing an implementation. If I were to spend ten weeks writing this in assembly, it would be much faster than SQL but "faster" is not always better nor what is wanted here.
This plane:
http://en.wikipedia.org/wiki/Concorde
is faster than this plane
http://en.wikipedia.org/wiki/Concorde
and is far superior in many, many ways, but there is a reason you have never flown one and a reason all airports everywhere do not have them coming and going every minute AND a big reason they were grounded to never fly again. I am not sure why I have to have this same discussion every now and then when someone comes to me and says "this would be faster".
Right now in another area I am having an unbelievable battle: Do we write our own messaging system that would be much faster than JMS, AMQP or anything we could simply pull off the shelf - I mean it will be faster but only cost $200K in its first year of writing and maintenance.
Please go home with comments like this and if you are not going to help contribute to the solution do not log on cheez.
"Fast" is not a requirement nor is it a concern with this problem and solution. It is completely beside the point.
</rantoff>