MySQL query oddity between 2 OS's

Please allow me to preface this post with an apology. I'm not sure where the below issue is derived from, (the difference in operating systems, a MySQL problem, a C problem, etc...), so if this post is in the wrong topic, again, my apologies.

...continuing on...

System Setup 1:
Microsoft Windows XP Professional, SP3, 32 bit.
MySQL 5.1.47

System Setup 2:
Microsoft Windows Server 2008 Web Edition, SP3, 32 bit.
MySQL 5.1.47


Everything on System Setup 2 is identical to System Setup 1 except for the operating system.


On the System Setup 1, the following C code has been working flawlessly. In other words, "bot", "top", "ls", and "rm" all populate with the correct data.

Code:

MySQL my;
char szQueryText[2500];
MYSQL_RES *My_result = NULL;

int bot, top, ls, rm;

snprintf(szQueryText, sizeof(szQueryText), "SELECT roomRangeFrom, roomRangeTo, lifespan, resetMode FROM zData WHERE zone= 10");
My_result = MySQL__query(szQueryText);

if (my.Query(szQueryText) > 0)
{
	my.NextRow();

	bot = atoi(my.GetData("roomRangeFrom"));
	top = atoi(my.GetData("roomRangeTo"));
	ls = atoi(my.GetData("lifespan"));
	rm = atoi(my.GetData("resetMode"));
}

However, on System Setup 2, ONLY "bot" populates with the correct data.

Let's assume that the database holds the following values for each of the above mentioned variables:

bot: 190
top: 250
ls: 8
rm: 17


On System Setup 1, the code would produce:

bot: 190
top: 250
ls: 8
rm: 17

However, on System Setup 2, the code would produce:

bot: 190
top: 190
ls: 190
rm: 190



Conclusion: I'm completely baffled as to what's going on here. Is it an operating system issue? A MySQL issue? Something else? Any insight to this hair-pulling circumstance would be greatly appreciated.

Thank you.

> my.NextRow();
> bot = atoi(my.GetData("roomRangeFrom"));
Well you could add some error checking to the code, instead of blindly assuming success.

If it comes with a meaningful error result, it might help you figure out what is going on.

"Blindly assuming success" ?

I'm not blindly assuming anything. For the past 5 years this code has been working on the XP machine. Now that I'm migrating to the server, that's when I'm having this issue.

There aren't any errors. The code simply refuses to pull all the data when run from the Server machine.

I'll keep hacking away at it.

Duration of success on one machine doesn't mean squat when you move to another.

The clock is reset on finding hidden bugs when you move to another environment - guess what, you found some bugs.

For a start, simply passing the return result of getdata() direct to atoi() without first checking for NULL is asking for trouble.

Originally Posted by Salem

For a start, simply passing the return result of getdata() direct to atoi() without first checking for NULL is asking for trouble.

"checking for NULL" is accomplished through the "my" object. Of course, from the code that I've posted, you wouldn't have known that.

Rest assured, the code is sound. The code that I've posted is not the issue.

I'm still debugging and looking into any 'outside' circumstances.

Originally Posted by xwielder

"checking for NULL" is accomplished through the "my" object. Of course, from the code that I've posted, you wouldn't have known that.

Rest assured, the code is sound. The code that I've posted is not the issue.

I'm still debugging and looking into any 'outside' circumstances.

Unless your "my." function aborts execution or jumps, then you'll need to check for NULL again. What does mysql_field_count() say? See MySQL :: MySQL 5.0 Reference Manual :: 20.8.3.22 mysql_field_count()

Is the DB corrupt? Did you move it? What does the MySQL admin tool say when you query the table?

Post the code from 'GetData'. There's a good chance that the bug lies therein...

Originally Posted by xwielder

The code that I've posted is not the issue.

Can you then post the code that is the issue? ... Nope, you don't know where the issue is, hence the reason for posting here.

I see this rookie mistake often. You are looking at the problem in such a way that you do not see the bug. What you need is for someone else to look at the problem in a different way to yourself - A fresh pair of eyes, so to speak. However you force the rest of us to look at the problem in the exact same way you did. Therefore none of us are going to see the bug either.

Conclusion: When posting, ignore all assuptions you have made when attempting your own diagnosis. Give us the information and time necessary to make our own conclusions, too bad if you're 100% sure, that the bug is not in one particular part, just help others to do their thing and solve it their way by posting whatever is asked for, wherever possible. We're pretty smart too, so don't feel that we wont come to some of the exact same conclusions if those conclusions are indeed correct. This will make it go a lot faster!

Issue Resolved.

I neglected to add the "libmysql.dll" into the "C:\Windows\System32" directory. Once added, everything was perfect again.