Prev: DB2 connection: Setting codepage
Next: [PHP-DB] result set in php pagination
From: WebPat on 22 Jan 2010 09:10
I am surprised by the order of the data returned from my stored
procedure, and that it appears associated with the incorrect variables.
Apparently the data is returned entirely positionally, without
consideration for the variable names. So, the names of the OUT
parameters in the procedure appear to be invisible outside of the
procedure. Although I pass in variables with the same names as the
Parameters, they are filled positionally - in the "wrong" variables -
because in this case I had two variables reversed positionally.
When I retrieve them using fetch_assoc, the wrong data appears in the
result.

This contrasts with a passed in query such as "Select * From Table",
which would have the data in the column names. My fetch_assoc would work
properly with this same code, just changing to a simple query.

In other database I have worked with, the output of a stored procedure
can be referenced by that procedures parameter names. The approach here
has its advantages, but 1) it is not documented that way, and 2) it
creates a dependency in the client code that is sensitive to the ordered
position of the procedure parameters, rather than the name - which as
noted, differs from the handling of simple queries. Oddly, this creates
a situation where queries are preferred over stored procedures for
stability - the opposite of normal design strategy.



From: Chris on 24 Jan 2010 17:26
WebPat wrote:
> I am surprised by the order of the data returned from my stored
> procedure, and that it appears associated with the incorrect variables.
> Apparently the data is returned entirely positionally, without
> consideration for the variable names. So, the names of the OUT
> parameters in the procedure appear to be invisible outside of the
> procedure. Although I pass in variables with the same names as the
> Parameters, they are filled positionally - in the "wrong" variables -
> because in this case I had two variables reversed positionally.
> When I retrieve them using fetch_assoc, the wrong data appears in the
> result.

I'd probably find a more targeted mailing list (a specialized one for
your database - whatever it is) and see if they can offer any suggestions.

--
Postgresql & php tutorials
http://www.designmagick.com/

From: WebPat on 25 Jan 2010 14:01
Chris wrote:
> WebPat wrote:
>> I am surprised by the order of the data returned from my stored
>> procedure, and that it appears associated with the incorrect variables.
>> Apparently the data is returned entirely positionally, without
>> consideration for the variable names. So, the names of the OUT
>> parameters in the procedure appear to be invisible outside of the
>> procedure. Although I pass in variables with the same names as the
>> Parameters, they are filled positionally - in the "wrong" variables -
>> because in this case I had two variables reversed positionally.
>> When I retrieve them using fetch_assoc, the wrong data appears in the
>> result.
>
> I'd probably find a more targeted mailing list (a specialized one for
> your database - whatever it is) and see if they can offer any suggestions.
>

My database is Mysql. The data seems to display properly there. I'm
accessing the database with procedures that are part of PHP and that is
where I believe the problem is. That's why I asked it on this "Newsgroup".

I got it to work by putting my parameters in the proper order. I know
this is how function and procedure calls normally work, but the
documentation of fetch_assoc() leads in another direction. It looks like
the "Associations" are created within my php and not carried from the
database for stored procedures. I wonder if PHP does this for all
databases? I think this differs from "Select * From Table". Certainly
could use another sentence in the documentation.
From: Chris on 26 Jan 2010 17:05
WebPat wrote:
> Chris wrote:
>> WebPat wrote:
>>> I am surprised by the order of the data returned from my stored
>>> procedure, and that it appears associated with the incorrect variables.
>>> Apparently the data is returned entirely positionally, without
>>> consideration for the variable names. So, the names of the OUT
>>> parameters in the procedure appear to be invisible outside of the
>>> procedure. Although I pass in variables with the same names as the
>>> Parameters, they are filled positionally - in the "wrong" variables -
>>> because in this case I had two variables reversed positionally.
>>> When I retrieve them using fetch_assoc, the wrong data appears in the
>>> result.
>>
>> I'd probably find a more targeted mailing list (a specialized one for
>> your database - whatever it is) and see if they can offer any
>> suggestions.
>>
>
> My database is Mysql. The data seems to display properly there. I'm
> accessing the database with procedures that are part of PHP and that is
> where I believe the problem is. That's why I asked it on this "Newsgroup".
>
> I got it to work by putting my parameters in the proper order. I know
> this is how function and procedure calls normally work, but the
> documentation of fetch_assoc() leads in another direction. It looks like
> the "Associations" are created within my php and not carried from the
> database for stored procedures. I wonder if PHP does this for all
> databases? I think this differs from "Select * From Table". Certainly
> could use another sentence in the documentation.

You can submit documentation patches and/or submit a note for that
situation on that page in the manual.

--
Postgresql & php tutorials
http://www.designmagick.com/

 | 
Pages: 1
Prev: DB2 connection: Setting codepage
Next: [PHP-DB] result set in php pagination