Basic query - cfoutput is incorrect. Please help.

mysql-connector-java-5.0.6-bin.jar is the drive on the server (the one that works).

It looks like I have mysql-connector-java-5.0.4-bin.jar on my computer.

Do I need to update?

I only know enough about administering ColdFusion to get by and maybe not even that much. I haven't updated the JDBC driver and I don't know what they're using on the server, but I will check. ColdFusion MX7 on both my computer and the server.

If updating the JDBC driver is something I need to do, can you point me in the right direction?

Thanks

What if you swap the order of the sets in the update query. What happens then?

<cfquery name="update_team" datasource="migca">
UPDATE academic_teams
SET division = 2,
p1fname = 'Testing'
WHERE academic_team_id = 2
</cfquery>

What MySQL JDBC driver are you using? the one that came with ColdFusion or did you update it? What version of ColdFusion are you running on your desktop? What version is running on the server? What MySQL JDBC driver are they using on the server?

Ok. Maybe this will help someone solve this...

I just uploaded the page in question and it works perfectly on my web hosts server... just not on my computer.

Any thoughts?

Thanks again for your help with this.

The results are still the same after a restart and when writing the page with just the query and the cfdump.

Okay, here is a new simple page that does both the UPLOAD and the QUERY. Below the code, I will pase some of the debugging info. Please note that p1fname WAS NOT 'Testing' before I ran the UPDATE.

<cfquery name="update_team" datasource="migca">
UPDATE academic_teams
SET p1fname = 'Testing',
division = 2
WHERE academic_team_id = 2
</cfquery>

<cfquery name="get_nomination" datasource="migca">
SELECT p1fname, division
FROM academic_teams
WHERE academic_team_id = 2
</cfquery>

<cfdump var="#get_nomination#">

The result of the cfdump is one row with division = 1 and p1fname = Testing.

Here is some debugging info:

SQL Queries

update_team (Datasource=migca, Time=15ms, Records=0) in C:\CFusionMX7\wwwroot\CFIDE\migca\forms_online\temp_dump.cfm @ 01:06:21.021

UPDATE academic_teams
SET p1fname = 'Testing',
division = 2
WHERE academic_team_id = 2

get_nomination (Datasource=migca, Time=0ms, Records=1) in C:\CFusionMX7\wwwroot\CFIDE\migca\forms_online\temp_dump.cfm @ 01:06:21.021

SELECT p1fname, division
FROM academic_teams
WHERE academic_team_id = 2

Thanks for looking at this and for all of your suggestions.

Just to take all the session/transaction possibilities out of the picture, do this:

Restart your computer.

Write a page that simply does:
<cfquery.. name="testquery">
select division from academic_teams where academic_team_id = 2
</cfquery>
<cfdump var="#testquery#">

Now run that query directly in your database. Do you still get different results?

As long as you're looking at the same database, there is no reason why you should be getting different results.

Yes, I get back 3.

In the page where the original problem occurred, I'm updating the table and then querying it for all of the same information that I just updated. All of the other fields are updating correctly and then displaying the query results correctly, so it's easy to veryify that I'm using the right database (besides, it's the only one on my computer that has this table in it). "division" is updating correctly, but not displaying correctly. When I copy the query directly from the browser page's debuggin information and run it in SQLyog, the result is what I expect.

It's not in a <cftransaction>

Thanks Kronin555 and Dan - if you have any other ideas, I'd love to hear them.

And when you run this query:
SELECT division
FROM academic_teams
WHERE academic_team_id= 2

directly in your database, not via coldfusion, you get back 3?

Is this query in coldfusion running in a <cftransaction> that is updating any data?

If you're absolutely sure that you're talking to the same database from ColdFusion and SQLyog, and are getting different results, then you've found something I've never seen before.

I'm totally baffled because the original problem occurs in a query that pulls alot more information and all of it is correctly displayed.