Synapsevampire,
I wasn't trying to be mean, and I'm sorry if it sounded that way.
I've been going thru a slew of these threads to better understand how to make use of CR features. I've seen a lot of your posts, and it's very clear you know CR very well.
My thanks for all the great advice you've given - it's helped me several times already!
I'm new to CR, but I've got 20+ years doing data modeling. I'm considered an international expert in that field. Glad to supply credentials if asked, otherwise I won't bore you.
First of all, I offered part of a solution:
Ask the questions I listed. 
A full solution would have to await the answers to those questions.
As for how I knew where to look, here's an explanation:
The first post showed that the user expected 1 record but was getting 3 records.
The definition of what he was supposed to get was:
item id / qty on hand / description.
I'm new to CR, but I'm operating under the impression that it doesn't just invent data rows out of thin air - the SQL has to return the rows or the programmer has to code them into existence.
When someone gets more rows than they expect, there are several very likely reasons from a database point of view. All of these are common mistakes, by the way:
1) There really are more rows in the database than they suspected because the data is invalid.
This happens a lot! Usually because the data modeler didn't set up the database constraints correctly and the programmers misunderstood the data modeler's intent.
2) Although there really only is one record in the database, a programmer made an incorrect join and therefore extra records were created in the output dataset by the query.
This wasn't likely given the data that was displayed in the first posting. First of all, the quantities didn't match. This meant that there were probably at least 2 records in the database, one with a qty of 1 and another with a qty of 2. However, there were two records with a qty of 1 and only one record with a qty of 2. If it were just a simple join mistake, there would normally be the same number of "extra" records for each original source record. While it's possible to get 3 records in the output from two starting records, it's also much less likely.
3) The data is correct, but the programmer has misunderstood the definition of the data table.
In this case, there would be three legitimate rows in the database and the programmer's desire to remove two of them is the mistake. In an inventory system, it's common to have a many-to-many cross-reference between item and storage_location, each of which needs it's own qty on hand value.
My questions to ask were:
"How many item 158-10 records show up in the database?"
Followed up with:
"If three, why are there three records? Have you misunderstood the data definitions?"
These are the first things to check because it's a) easy and quick to do so and b) other programmers frequently create bad data, misunderstand the data they are querying, or incorrectly join the data.
The answers given to these questions will quickly pinpoint which (if any) of them is the source of the problem.
In this case, when he went back and checked the data he was querying, he discovered that there were indeed 3 records in the database and that there were supposed to be 3 records in the database. That's mistake #3, misunderstanding the definition of the data being queried.
Hope that helps explain my reasoning.
My intent was to illustrate how easy it is to answer the question someone asks instead of the question they
should have asked.
Fundamentally, the original poster asked:
How do I get rid of these extra rows?"
They should have asked:
"Why do I have these extra rows?"
David Wendelken