X-file with db function returning a rowtype to forms. Positional binding?

Question

How to explain this ...
First things first:
Forms [32 bits] Versión 11.1.2.1.0 (Producción)
Oracle Database 11g Release 11.2.0.3.0 - 64bit Production
Now the db testcase:
I've got two schemas, quite similar, SCHEMA_A and SCHEMA_B
Imagine the same table: mytable (colx varchar2, coly varchar2, colz varchar2) in both schemas,
BUT in SCHEMA_B the order of the cols is not the same. In schema B it is
mytable (colx, colz, coly).
(Yeah, I know, I know, but leave it for the sake of the x-file)
Let's suppose the table has only one row, and that I have a db function in both schemas such as this:
function get_myrow return mytable%rowtype is
l_row mytable%rowtype;
begin
select * into l_row from mytable;
return l_row;
end;
Here, the forms testcase:
I make a form, where I show the value in an item
For example:
:item := get_myrow().coly
And now, the x-file:
If I compile the form in the builder, connected as SCHEMA_A, when I run it in SCHEMA_B, the item shows colz value!!
It is as if forms is doing some kind of positional binding in the fmx. Instead of asking for coly column to the record type variable, it shows "the second value" of the record type.
Now, I will have to find this disordered tables and reorder them (dbms_redefinition? hints are welcome).
Any thougts? Bug as feature?

Answer 1

About the "select * is problematic" , I agree 99% of the times. But this time, as I'm storing the values in the rowtype variable, is the way to ensure that the estructure and the values fit.
You said:
What happens when your table changes (such as a new column) but your function hasn't been updated?  Your Function will produce an error because it can't handle the additional column.
And it's just the opposite. My function will recompile itself, as the rowtype is perfectly capable of storing the values in the new rowtype.
In fact, it's the MLBrown function the one that would produce an error if I change columns in the table, and that's the best case scenario, as the function could be lucky and work storing the values in the wrong places, leaving the bug hidden.
Anyway, I understand this "select *" issue is arguable, so forget about the select * , I'll take it out of this thread with a more simple testcase:
create table mytable (
colx varchar2(10),
coly varchar2(10),
colz varchar2(10));
Consider this "select free" version of the function:
function get_myrow return mytable%rowtype is
  l_row mytable%rowtype;
begin
l_row.colx := 'a';
l_row.coly := 'b';
l_row.colz := 'c';
  return l_row;
end;
Forget also about schema_a and schema_b, I can reproduce it with just one schema!!!
Now I build a form with just a button. When- button-pressed:
message (get_myrow.coly);
I compile and run it, and I get a b value. ok.
Now I drop the table and recreate but like this:
create table mytable (
colx varchar2(10),
colz varchar2(10),
coly varchar2(10));
Now run the form (without compiling) and see how the message shown is c !!!
The result is different, depending on how whas the rowtype structure when I compiled the fmb.
Are you indeed telling that is acceptable an escenary where I ask for get_myrow().coly value and I get colz value instead?
How's that possible? Because somebody shortcutted in the fmx compiling process, and converted my call for named coly value to a call to "the second column of the record variable".
I'm not asking for a numbered position , I'm asking for coly value, not for "the second column of the rowtype variable the day I compiled the form". Had I want a possitional binding, I'd use a frikkin varray.