btherl

Try adding this line: $cat_id = $_GET['cat_id']; # <-- Add this $get_vars = "cat_id=".$cat_id; make_next_previous_with_number( $from, $SQL, $this_file_name, $get_vars ,$display_nr); No guarantees but if it works, it'll be a simple solution and you won't need to get into the code in detail.

Ok, what I can tell from that code is that $vars does not have the expected value. $vars is an argument to make_next_previous_with_number(), so the problem lies somewhere else, in the code that calls this function. So you will need to track $vars back through the code to find where it is being set, and why it doesn't have the value you expect.

Holder, are you using the same function, make_next_previous_with_number()?

What output do you get? Are there any errors reported? Make sure you check for errors after every call that could fail.

I notice you're not using sercfg in the last code you posted, is there a reason for that? You could try leaving all the pipes open. Plink might be unhappy to have stdin closed. But I think the most important thing is to make sure you are using non-blocking I/O. This function might work: http://php.net/manual/en/function.stream-set-blocking.php

It sounds like your code already has a way to identify which checkbox is which, but it isn't working properly. You really need to post that part of the code.

Hi Giuliano, What about using proc_open() instead? There is an example in the php documentation for how to use it: http://php.net/manual/en/function.proc-open.php The problem with exec() is it will wait for plink to terminate before returning the output. And plink never terminates. But proc_open() will let you run plink at the same time as php is running. In your test above you still get the output in the log file because plink is running and writing to the log, even though php is suspended waiting for plink to finish.

Maybe you can call putty first to get the port into the correct state. Perhaps with plink.exe. Or you could put your entire connection through plink.exe using proc_open(). Maybe it'll work

Well, yes and no. It does not specifically mean "unknown". It means "unknown" or "inapplicable" information - i.e. it does not exist. If I do a DB query on the parents table and JOIN it to the children table, a user with no children will have null values. If I do a COUNT() using GROUP BY for those children I get 0. If the result of the count was unknown I would get a null count. It can mean either or - which is why Codd had proposed using two different NULLs to differentiate the two. Codd's rules: Thankyou, that's quite interesting.. I tried it and it works just like you said. I never count columns, only count(*), so I hadn't noticed.

Detecting encoding is tricky business, and mb_detect_encoding() probably won't help. The problem is that EVERY document is valid in the ISO 8859 and windows code pages, they just end up with different characters. Not all documents are valid UTF8 though, so you can sometimes rule UTF8 out. Trying to decode the document as UTF8 is a good start, because if that fails you know it's not UTF8, it's something else. Another good start is to check if there is nothing other than plain english characters - if that's all there is you don't need to do anything. If you can, do what ChristianF is suggesting and make sure you know the encoding and don't need to detect it. Also if you know what languages you are dealing with it helps. Eg if you are just dealing with chinese or japanese, there are specific encodings they usually use and you can distinguish them more easily. And many languages have a standard code page that everyone uses.

I'll continue splitting hairs . In SQL null was intended to represent "unknown" specifically. It's different from what it means in a programming language. That's why it has these semantics: x > null : false (x might be smaller..) x < null : false (x might be larger..) x = null : false (x might not be equal) x != null : false (x might be equal) It's the last one that is surprising - if null meant "no value", you would expect everything to be not equal to null. But because it means "unknown", and we don't know if x is not equal to an unknown value, the comparison is false. It's different in a programming language, where null means "no value" and x != null is true because x has a value and null doesn't. In php you have to do x !== null to get these semantics, which is an unfortunate design choice IMHO. Strict comparison should be the default. Of course in practice most people use null for "no value" in sql anyway.. and we've all learnt to work around sql's assumption that null means unknown, like using the "is distinct from" operator - it's just like "!=" except it treats null as not equal to any known value.

Comparing against null with its traditional meaning from SQL is asking "Is this variable unknown?". It's a sensible question to ask, and routine when doing left joins. Being unknown is information, and sometimes we need to know the difference between "unknown" and "known", or "unknown" and "doesn't exist". If we carry the same meaning over to php, it still makes sense to compare against null when asking if a variable has an unknown value. It's true that it's often used to mean "undefined", like perl's "undef", but that's because of how PHP treats undefined variables. Programmers are just following PHP when they do that.

Ok that's fairly clear. What exactly is your question though?

"approve" and "accept" only apply when saying a post is accurate. "thanks" only applies when a post is helpful to you. For that reason I like "kudos" and "like" better, as they can have either meaning. It just means "this is a good post". If a novice uses it it means "this is helpful", and if an expert uses it it means "this is accurate". I am Btherl for president, and I approve this post.

Some people are passionate about nulls I've got a simple rule - use === whenever possible, because it keeps things simple. It's the right operator for nulls and string comparisons. == is suitable for comparing numbers only, when you want php to do the necessary conversions between strings, floats and integers.