I’m struggling with the array_pop part of things, perhaps I’m not understanding what you are actually trying to achieve. At the point in the code above where you create $ret_vals, surely that will be empty because those variables have no content - you’ve assigned them as the destination for your query results, but you haven’t called fetch().
Can you just display what comes back from the query loop, then describe the structure of the array you want it in? Maybe using an array to retrieve the results with fetch_assoc() would make it easier to combine it into an array.
He is probably using some outdated manual, where such a code madness is described as the only way to get the data from mysqli. While there are simpler ways. A simplest one (as he is not using prepared statements anyway) would be
$sess = $conn->real_escape_string($_SESSION['username']);
$res = $conn->query("SELECT users.username, users.email, users.password, user_info.profile_pic, user_info.bio FROM users INNER JOIN user_info ON users.username LIKE user_info.username WHERE users.username LIKE '$sess'");
Killjoy! You were here the entire 15+ hours this question was active and provided no meaningful input nor as you said “sane code”. You sat by the wayside and watched on. At some point, you even tried derailing my thread. Now I’ve managed to resolve it using clues from one or two people here, you’re stringing your result along. Are you trying to help or just show what a wicked person you are??
The ON specifies the criteria by which the two tables are matched up. It’s meant to tell the DBMS how the tables compare and isn’t meant as a manner to filter out all the results. Basically a first sort.
The LIKE should only be used if you are doing a generic match, so there is typically a % at the front or end of the criteria. In this case, since you’re doing an exact match, the equality sign would be more appropriate.
I changed the string to this and it still parsed. I think the situation doesn’t call for LIKE "SELECT users.username, users.email, users.password, user_info.profile_pic, user_info.bio FROM users INNER JOIN user_info ON users.username=user_info.username WHERE users.username='$sess'"
I am afraid you are wrong here.
I suppose you are talking of collations , and I can assure you that = operator is taking collations into account as well, using not character codes but collation tables for comparison.
And as long as character encoding and collation are the same, no problem.
Well, first of all, such a case just should never be. A column’s charset should mark the actual data encoding. Period. Otherwise it’s an error, and nothing will be working good.
And second, in such a case LIKE won’t be of any help either. as it’s comparing strings exactly the same way as =, save for parsing wildcars.
So I suppose that you are using LIKE due to some confusion.
Taking into account the apparent danger of such a misuse, I strongly advise you to quit that practice and start using LIKE only on purpose - for the wildcard search.
Per the SQL standard, LIKE performs matching on a per-character basis, thus it can produce results different from the = comparison operator:
In particular, trailing spaces are significant, which is not true for CHAR or VARCHAR comparisons performed with the = operator:
Of course, the = operator does not compare strings numerically so it can be used just fine - and I think it should - in theory…
Not true, there are differences, one of which is the trailing spaces. Another difference - in some collations certain accented characters compare differently to other (similar) characters (or character pairs) depending on whether = or LIKE is used.
It is rare that these differences matter in real usage but sometimes they may be significant.
[quote=“colshrapnel, post:34, topic:222213”]
I strongly advise you to quit that practice and start using LIKE only on purpose - for the wildcard search.[/quote]
My logic also tells me to use LIKE only for wildcard search and = for normal comparisons because I assume such is their intended purpose. However, due to the weird rules that exist in mysql I don’t think people make a mistake if they use them differently. In my opinion LIKE should really be the same as = except for the wildcard capability and any comparison dialects should have their own separate keywords (just like the COLLATE keyword). And the trailing spaces thing - it’s a little insanity on mysql part - who invented that and what for? And why trailing and not leading spaces? We need to adapt to the mess of mysql environment.
BTW, this is going off topic, I hope the OP doesn’t mind!