mySQL View returns no recordset

I'm building new php pages for a new client where I've never built on their host before. They're running PHP v5.6, and if I build a typical mySQLi recordset, the recordset displays on the page just fine. However, if I build a view on the DB, and then try to create a recordset against the view, then the PHP page is blank. I can click the TEST button in the recordset builder dialog, and it returns the records as expected. They're just not showing on the actual page. There's nothing unusual about the page, I'm simply asking for one column to display from the recordset to confirm the data. I've built mySQLi recordsets from views on MANY other hosts without this issue. The view itself is nothing more than a join of two simple tables with a shared key UID. Any thoughts on what I might need to confirm with this particular host's DB that might account for this??? Any suggestions are welcome really.

It could be permissions on the view? You should be able to use var_dump() to dump the recordset formed from the view on the page and that will include any errors that might be occurring.

<?php
var_dump($RSName);
?>

PM

Try running the query in phpMyAdmin and see if it returns results. With no errors and the columns showing, it really should work. I don't think it would be permissions if you see the column names.

PM

That is very odd. If you give me FTP access I can debug further.

PM

I've updated your version of rsobj.php on the server. It appears to have fixed this problem. You can download it from the live site to replace your local version.

Confirmed it's working now. What did you have to do? Is there something on the server side I should have done to prevent this??

There is a bug in views where parameterized SQL statements don't work, which is what we used by default in our recordsets to prevent SQL injection. But when you don't have a parameter you are passing in, it isn't really necessary, so the latest version doesn't use a parameterized SQL statement when no parameters are set.

It is a bug we have worked around in the latest version of the rsobj.php file that I've uploaded to the server. Save that file so you can use it if you run into this problem in the future.