Re: [PHP4BETA] Stored Procedures (via ODBC)

hi, we try to call an ADABAS-D stored procedure like this: $res=odbc_exec($db,"proc knowone.test.writereturn(?)"); (also tried the following one: $res=odbc_prepare($db,"proc knowone.test.writereturn(?)"); $res=odbc_execute($res,$x); ) the procedure is executed. after that we can read: $rows = odbc_num_rows($res); echo $rows; .. returns 1. That is: $res is a valid resultset and there is a result. but: odbc_result(), odbc_fetch_row() and odbc_fetch_into() ...throw the error message: Warning: No tuples available at this result index in ... any idea? regards, gaylord aulke agi. stuttgart,germany Leo Baschy wrote: > I first thought the question was for the return value, and I just noticed you only asked for > the result. Well, that should be an easier one to answer. Go step by step. Where does it break? > What kind of variables are you reading, char, varchar, longvarchar? What database are you using? > (Different words used by different database systems.) Are you using the correct ODBC call syntax > {CALL whatever...}? > Without diminishing its benefits, there are some nasty limitations in PHP's ODBC > interface as it is today. I live with some of them, and I think I actually have cleaned up some of > them for my own use, but that needs to be reviewed to not break for other users before rolling it > in. (Windows/Linux, etc.) > Example: If you first have a longvarchar and then a varchar and then another longvarchar in > one row in the same fetch_into() that messes up the current PHP's ODBC as it violates something > that is in ODBC documentation. I have fixed that for myself, but as I said those fixes worked for > me in PHP3 privately, I just rolled them into PHP4, and I suggest rolling them into the official > version only after some review. > There might be some discussion whether to change or add anything at this stage. Personally > I think if things crash and don't work at all for new users that's a good reason to fix > it. > It was a pretty bad experience to get ODBC to work for me, because of such small stuff. I > just had bet the farm on it, and I had even worse time with JDBC earlier, so I had to dig into the > dirt. I really got to appreciate the open source concept, that I was able to get to the dirt. > Is the PHP and its ODBC interface good? Yes, I love it so much that I actually have spent > plenty of time looking at it and then fixing it until it worked for me. > > - Leo Baschy <nirvana@got.net> > > At 04:20 AM 3/17/00 -0800, I wrote: > I have stored procedure call via ODBC with output parameters (includes result) actually > running, via a couple of new functions I implemented. > Have used it for a while in PHP3 for a site, but PHP3 is history as far as I'm > concerned. > Just finished my port of it into PHP4 I think on Monday, have been using it since then, > wanted to wait a little to see how it works (needed one fix) for me before I have a couple of people > here look at it. I think I'm ready for that, or maybe I should use it a couple more days. > If everything goes well through review it might be available to the public in a week or > two, I guess. If anyone compiles themselves and really wants it right now, just send me a message. > > - Leo Baschy <nirvana@got.net> > > At 12:56 PM 3/17/00 +0100, you wrote: > >Hi, > > > >did anyone manage to call a stored procedure via ODBC and read the > >result the stored procedure produces into php variables? > > > >i can call the procedure and odbc_num_rows() reports that there is > >one row in the result set but i cannot read the data. (fetch_row throws > >an error) any ideas? > > > >gaylord aulke > >agi, stuttgart, germany