Duplicates In DGV

[Shaggy Hiker]

This is a hopeless question, but I figured I'd see whether or not anybody has some insight.

I have a DGV that uses the DefaultView of a datatable as it's source. The datatable is filled on program startup, and it is a simple query of a couple fields from one table with an unimpressive WHERE clause that just gets the most recent years. No joins, just a couple columns from one table. The data is also ordered on two columns.

The program runs on three computers. On two of them, it works as expected. On the third, most every name (the display value from the datatable) shows up multiple times. They are ordered properly, they just appear up to three times.

Note that on the three computers (one dev system and two deployments), the query is exactly the same.

I'm at a loss as to how one of the three can show different results, also, how that one can have duplicates when the other two do not. There are no such duplicates in the underlying data.

As I wrote this, I realized that there is one way that it might be possible, if Date.Now on the target system was wildly wrong. That's all that the WHERE clause holds, as it only takes records where the date is greater than Date.Now for reasons I won't get into. The system date on the problem system would have to be off by several days, though. That seems improbable, but it's something worth looking at.

Are there any other ways that a query can return duplicates, or that the DefaultView of a datatable can return duplicates? It would have to be something that could behave differently from one system to the next, as duplicates do not actually exist in the underlying data.

[dday9]

If you're using SQL Server as your data source, I would recommend running the SQL profiling tool to see what is actually being executed on the machine that is returning "wrong" data.

Your suspicion that the date in the where clause is off would become obvious at that point -or- it could be something entirely different but just as obvious.

[kebo]

Another thing to try is running the query in a client (ssms, heidi.sql, etc.) on each machine. That might point to, or eliminate a server/sql command issue.
kevin

[Shaggy Hiker]

The SQL being executed is the same in all cases. It's just a static SQL string run against the same DB. Is there any reason why that would ever produce different results on different computers? That doesn't make sense to me.

"SELECT field1, field2 FROM table1 WHERE SomeDateField > '" date.now.toString & "'"

That shouldn't be different from one computer to the next in any case, unless the date.now is not returning the same thing on all systems. I'll need to check a few things on the misbehaving system, but that will have to wait until tomorrow...or Monday, perhaps.

[si_the_geek]

That would definitely give different results for a large percentage of computers in the world.

Within SQL statements, database systems interpret using US formatting (mm/dd/yyyy), but lots of countries use other formatting (eg: for the UK, dd/mm/yyyy). Due to that, different regional settings on computers can give very different results.

Either use parameters (thus avoiding formatting issues entirely), or use the ISO format (yyyy-mm-dd) which will be interpreted safely.

[Shaggy Hiker]

Yeah, okay, that could be an issue in some cases, but shouldn't be an issue here. Both computers are in the same office in the US. On the other hand, I did change somebodies regional settings to mess with them, one time. That seems unlikely to be the case here, though.

Of course, since I've pulled that prank myself, I guess I had better check that.

[BlackRiver1987]

Log the response from the DB before you assign it to the DGV.
Also, how about you show us some code? How do you construct the query? How do you send it to the DB?