I don't do SqlServer, but in other databases such as oracle, Varchar can be bytes or chars, where chars are unicode (2 bytes per char). Char causes Microsoft Access all sorts of headaches. I don't know if you can, or if you need to declare your varchar as byte, but if you can it is worth a shot.
Also, posting pseudo code doesn't help you as we can't find the subtle mistakes that us programmers make all the time, so I suggest you reduce the problem to two single SELECT statements and post the actual code. Obviously substitute for the username + password in your connect. Also remove any columns from the queries that aren't needed to show the problem.
Reducing the problem to it's simplest form not only makes it easier for us to understand it, it often helps you find the real issue (like a date column that, believe it or not, M$ can't handle certain values of).
Also, your use of 'global' looks a bit suspect - it shouldn't be used on the declaration, but on the usage. If you are starting out, you may want to consider classes and other structured techniques for passing data around in an application.
Further, assembling sql statements using string concat is a real bad idea because of SQL Injection. e.g. "select from x where key = ' " . $recid . ' " (I've added some spaces to emphasise the quotes) To illustrate the problem, Imagine this SQL statement:
Code: Select all
$sql = "select user_id from very_secure_table where very_secret_password = '" . $user_input ."'";
Code: Select all
$user_input = "x' or '1' = '1";
$sql = "select user_id from very_secure_table where very_secret_password = '" . $user_input ."'";
Code: Select all
// Sql statement using bind parameters:
$sql = "select user_id from very_secure_table where very_secret_password = :bv_user_input";
// bind user input to parameters:
some_function_like_bind(':bv_user_input', $user_input); // Add the parameter value
// execute:
Hope that helps,
-A