I have a query that returns multiple identical records, however it should
only return one. Indeed there is only one record for the OrderActionTypecode
of 'P' yet there are two orderactions so it returnd both.

Oddly the second query returns only the desired single record but wihtout
all the additional fields I need. Does the Inner join somehow mess with the
query?

Thanks

Query 1
SELECT Orders.OrderID, Orders.TicketID, A.AttemptID, E.EventID,
E.AssetCode AS Asset, Orders.FK_Prod_Alias AS Alias, Orders.ContractCode,
L.OrderLegCode AS OrderLeg, M.MarketActionName AS
Action, Orders.OrderVolume AS Volume, Orders.OrderPrice AS Price,
T.OrderTypeName AS OrderType, S.StatusName AS Status,
Orders.FilledVolume AS Filled, Orders.OriginalOrderDateTime,
Orders.PlaceOrderDateTime,
Orders.MonitorFlag
FROM Orders INNER JOIN
OrderAction OA ON Orders.OrderID = OA.OrderID INNER
JOIN
Attempt A ON Orders.AttemptID = A.AttemptID INNER JOIN
Event E ON A.EventID = E.EventID INNER JOIN
MarketAction M ON Orders.MarketActionCode =
M.MarketActionCode INNER JOIN
OrderLegs L ON Orders.OrderLegCode = L.OrderLegCode
INNER JOIN
OrderType T ON Orders.OrderTypeCode = T.OrderTypeCode
INNER JOIN
OrderState S ON Orders.Status = S.Status AND
Orders.OrderID =
(SELECT OrderID
FROM ORDERACTION
WHERE ORDERACTIONID =
(SELECT
MAX(ORDERACTIONID)
FROM
ORDERACTION
WHERE
OrderActionTypeCode = 'P'))


Query 2

SELECT OrderID, TicketID
FROM Orders
WHERE (OrderID =
(SELECT OrderID
FROM ORDERACTION
WHERE ORDERACTIONID =
(SELECT
MAX(ORDERACTIONID)
FROM
ORDERACTION
WHERE
OrderActionTypeCode = 'P')))

[posted and mailed, please reply in news]

Fred (Fred@hotmail.com) writes:
> I have a query that returns multiple identical records, however it
> should only return one. Indeed there is only one record for the
> OrderActionTypecode of 'P' yet there are two orderactions so it returnd
> both.
>
> Oddly the second query returns only the desired single record but
> wihtout all the additional fields I need. Does the Inner join somehow
> mess with the query?

Without information about your tables, it is difficult to give a
precise answer. A lazy solution is of course to add a DISTINCT, and
take the cost of the extra sorting pass required.

However, looking at your query, I am not really sure that I understand
the purpose of this JOIN:

JOIN OrderAction OA ON Orders.OrderID = OA.OrderID

What happens if you take it out?

--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

>> I have a query that returns multiple identical records [sic],
however it should only return one. Indeed there is only one record
[sic] for the OrderActionTypecode of 'P' yet there are two order
actions so it returned both.

Oddly the second query returns only the desired single record [sic]
but without all the additional fields [sic] I need. Does the INNER
JOIN somehow mess with the query? <<

The kludge is to use SELECT DISTINCT. The right answer is that your
DDL and schema design are probably all screwed. First of all, please
post DDL, so that people do NOT have to guess what the keys,
constraints, Declarative Referential Integrity, datatypes, etc. in
your schema are. Sample data is also a good idea, along with clear
specifications. What you are asking is impossible to answer right
now.

What you did post is awful. Let's get back to the basics of an RDBMS.
Rows are NOT records; fields are NOT columns; tables are NOT files.
You also need to read ISO-11179 and any book on data modeling.

The data element name "OrderActionTypecode" is almost identical to a
sarcastically bad example I use in a lecture. Please explain all the
logical differences among "OrderActionTypecode", "OrderActionType",
"OrderActionCode" and mere "OrderAction"? Could we also have a column
called "OrderActionTypeCodeValue" while we are at it? This much
improper attribute naming borders on parody; it just needs the table
name, datatype and usage (PK, FK) affixed to it to be a completely
wrong example.

I also see that you like to change the data element names in the
queries, so that the data dictionary is of little or no use to the
people maintaining the application or to the end users. It is a bad
attempt to make up for improper data element names, but it just makes
the code worse.

I also find after all these decades, that using the infixed join
syntax when you have a lot of tables actually hurts readability. You
might consider puting it all back into FROM.. WHERE.. syntax so you
can find the predicates easier.

Thank you for that most helpful reply.

Firstly, I will take your suggestion for posting additional information as
the appropriate thing to do in the future.

As for the verbose nature of the data element names. I did not design these
names, queries etc and have no experience with sql..... hence my visit to
this newsgroup.

I am merely trying to create a query that would let me view some information
over the web. In all honesty I could not care a less about the length of
'OrderactionTypeCode'. Yes it could have been merely defined as Type, but so
what... is it the end of the world as a result? (and yes, I am the one that
will need to maintain this database in the future)

Why am I not surprised that you are a university lecturer. I am sure that
you are a valuable contributor to this newsgroup so I will leave it at that.




"--CELKO--" <jcelko212@earthlink.net> wrote in message
news:18c7b3c2.0406131040.74f6219d@posting.google.c om...
> >> I have a query that returns multiple identical records [sic],
> however it should only return one. Indeed there is only one record
> [sic] for the OrderActionTypecode of 'P' yet there are two order
> actions so it returned both.
>
> Oddly the second query returns only the desired single record [sic]
> but without all the additional fields [sic] I need. Does the INNER
> JOIN somehow mess with the query? <<
>
> The kludge is to use SELECT DISTINCT. The right answer is that your
> DDL and schema design are probably all screwed. First of all, please
> post DDL, so that people do NOT have to guess what the keys,
> constraints, Declarative Referential Integrity, datatypes, etc. in
> your schema are. Sample data is also a good idea, along with clear
> specifications. What you are asking is impossible to answer right
> now.
>
> What you did post is awful. Let's get back to the basics of an RDBMS.
> Rows are NOT records; fields are NOT columns; tables are NOT files.
> You also need to read ISO-11179 and any book on data modeling.
>
> The data element name "OrderActionTypecode" is almost identical to a
> sarcastically bad example I use in a lecture. Please explain all the
> logical differences among "OrderActionTypecode", "OrderActionType",
> "OrderActionCode" and mere "OrderAction"? Could we also have a column
> called "OrderActionTypeCodeValue" while we are at it? This much
> improper attribute naming borders on parody; it just needs the table
> name, datatype and usage (PK, FK) affixed to it to be a completely
> wrong example.
>
> I also see that you like to change the data element names in the
> queries, so that the data dictionary is of little or no use to the
> people maintaining the application or to the end users. It is a bad
> attempt to make up for improper data element names, but it just makes
> the code worse.
>
> I also find after all these decades, that using the infixed join
> syntax when you have a lot of tables actually hurts readability. You
> might consider puting it all back into FROM.. WHERE.. syntax so you
> can find the predicates easier.