multiple records, only want one

[Fred]

I have a query that returns multiple identical records, however it should
only return one. Indeed there is only one record for the OrderActionType code
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.Contract Code,
L.OrderLegCode AS OrderLeg, M.MarketActionN ame AS
Action, Orders.OrderVol ume AS Volume, Orders.OrderPri ce AS Price,
T.OrderTypeName AS OrderType, S.StatusName AS Status,
Orders.FilledVo lume AS Filled, Orders.Original OrderDateTime,
Orders.PlaceOrd erDateTime,
Orders.MonitorF lag
FROM Orders INNER JOIN
OrderAction OA ON Orders.OrderID = OA.OrderID INNER
JOIN
Attempt A ON Orders.AttemptI D = A.AttemptID INNER JOIN
Event E ON A.EventID = E.EventID INNER JOIN
MarketAction M ON Orders.MarketAc tionCode =
M.MarketActionC ode INNER JOIN
OrderLegs L ON Orders.OrderLeg Code = L.OrderLegCode
INNER JOIN
OrderType T ON Orders.OrderTyp eCode = T.OrderTypeCode
INNER JOIN
OrderState S ON Orders.Status = S.Status AND
Orders.OrderID =
(SELECT OrderID
FROM ORDERACTION
WHERE ORDERACTIONID =
(SELECT
MAX(ORDERACTION ID)
FROM
ORDERACTION
WHERE
OrderActionType Code = 'P'))
Query 2

SELECT OrderID, TicketID
FROM Orders
WHERE (OrderID =
(SELECT OrderID
FROM ORDERACTION
WHERE ORDERACTIONID =
(SELECT
MAX(ORDERACTION ID)
FROM
ORDERACTION
WHERE
OrderActionType Code = 'P')))

[Erland Sommarskog]

[posted and mailed, please reply in news]

Fred (Fr**@hotmail.c om) writes:

I have a query that returns multiple identical records, however it
should only return one. Indeed there is only one record for the
OrderActionType code 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, es****@sommarsk og.se

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

[--CELKO--]

>> 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 OrderActionType code 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 "OrderActionTyp ecode" is almost identical to a
sarcastically bad example I use in a lecture. Please explain all the
logical differences among "OrderActionTyp ecode", "OrderActionTyp e",
"OrderActionCod e" and mere "OrderActio n"? Could we also have a column
called "OrderActionTyp eCodeValue" 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.

[Fred]

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
'OrderactionTyp eCode'. 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--" <jc*******@eart hlink.net> wrote in message
news:18******** *************** ***@posting.goo gle.com...

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 OrderActionType code 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 "OrderActionTyp ecode" is almost identical to a
sarcastically bad example I use in a lecture. Please explain all the
logical differences among "OrderActionTyp ecode", "OrderActionTyp e",
"OrderActionCod e" and mere "OrderActio n"? Could we also have a column
called "OrderActionTyp eCodeValue" 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.