SQL Syntax for selecting a group of 'last' records

Ok.
I have a table, tblPieces that has a PieceID and many other detail about each chunk of iron (eventually 10K or so chunks)
I have tblFlowLineReadings, that has PieceID, and JobID in it as foreign keys, along with data about a particular reading
(eventually millions of readings)
I have a form that let's the users choose a subset of PieceIDs to put on a report.
Those choices get knocked into a table, tempOnReport.

Now, for each PieceID in tempOnReport, I want to retrieve the latest row in tblFlowLineReadings for that piece.
Getting ALL the rows in tblFlowLineReadings would be simple enoughSelect * from tblFlowLineReadings where PieceID in (Select PieceID from tempOnReport)

But getting ONLY the latest row for each PieceID, that's a bit tricky...AND
Eventually I'll need to make this same result set come out for an ASP.Net page, so anything Access specific, or SQL Server naughty, won't cut the mustard.

The definition of 'latest' can be the largest JobID in tblFlowLineReadings for each PieceID in tempOnReport.

Tech changes fast. You can learn faster. That’s why we’re bringing professional training courses to Experts Exchange. With a subscription, you can access all the Cloud Class® courses to expand your education, prep for certifications, and get top-notch instructions.

Ah,
It was the max and group by that I needed to recall -- because DMax() is not going to fly and is a performance pig.
But, the max, group by, and two IN clauses should do it. And it makes sense to me looking at it in the query designer: a criteria for PieceID and a criteria for JobID

SELECT *
FROM tblFlowLineReadings
WHERE JobID IN
(SELECT MAX(JobID) as LastJob
FROM tblFlowLineReadings
GROUP BY tblFlowLineReadings.PieceID)
And PieceID IN
(SELECT PieceID
FROM tempOnReport)

but, I take it that JOINs are more efficient than INs, or at this point (SQL Server 2008 R2) the query optimizer will sort the two things out to be the same in the end?

I'll have to leave it for this evening, but I keep getting a Cartesian result (35 rows at present in tempOnReport -- query returns 1225 rows 35*35)
ID: 40561027 gives the right result, but how do I twist that around into JOINS and not get a Cartesian result?

Assumes you have index on FLR.PieceID and possibly R.PieceID also
Foreign keys and primary keys :) Good assumption!

I am far more often on the other side of the browser, too
My New Year's Resolution was to actually ask some questions.

At the moment, this is all being built, so there's either a paucity of data (tblFlowlineReadings only has 35 rows in it and one JobID) or a surfeit (jobID has 85K) and the data is in SQL Server.

When I try this in AccessSELECT FLR.*, *
FROM [Select Max(jobID) as maxJob from tblFlowLineReadings Group by PieceID]. AS M
INNER JOIN ([Select PieceId from tempOnReport]. AS R
INNER JOIN [Select * from tblFlowLineReadings]. AS FLR
ON R.PieceId = FLR.PieceID)
ON M.maxJob = FLR.JobID;
I get a Cartesian result, so clearly I am doing something wrong -- but I can't see it.

Here's a modified data set spit out in an .mdb
There are two tables and two queries.
The one query, with the IN clause, represents the desired result.
The query with 2 JOINS gives the unwanted Cartesian resultINtoJOIN.mdb

Access loves parentheses alright.
And it loves [ ]
And it loves ;
when you are aliasing
:(
To the point where it would just hose-bag the saved query every time I used it.
So, I wound up saving SELECT PieceID,Max(jobID) AS maxJob FROM tblFlowLineReadings GROUP BY PieceID
as qryMaxJob and throwing qryMaxJob into the query editor mix as a table and then not aliasing anything after that.
Then it did what I wanted and remained stable.

I had forgotten how bitchy the Query Editor is when you start with table aliases :(
The one flaw in an otherwise superlative bit of UI.

SSMS will be a lot more civilized when it comes time (in the next day or two) to create the sproc for the ASP.Net page.
It's an interesting project.
I've got an Access front-end, and SQL Server backend and an ASP.Net 'picture window' for the clients to purely view the data. Knocking it all into shape on the fly will definitely tax the grey matter.
I'll definitely have to remember to put the SQL query syntax as the primary zone.
I built my first UDF on Monday, but the suggestions I received was to use a cursor.
Hence the 'SQL Server naughty'

*sheepishy*
No Biggie.
I've got a very good memory for the printed word.
And if you've played in the MS Access TA in any substantive way -- and you have -- I'll have seen your name and poked at your bio.

Thanks to all for the help.
You all pointed me in the right direction with the Max(), and I got that bit sorted.
You helped me convert the INs to JOINs and I got syntax worked out that will play in both Access and SQL Server.