Need to condense numbers in Access Table based on the latest number

Pictured below is my table. I had to use a multi step query to extend out all my sub numbers. Now I need to remove all the rows that lead up to the last row.

For Example 1637276M1 through 1637276M6 should be deleted and 1637276M7 should be kept with all the sub number to the right of it.

How could i delete those rows?

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Jeffrey CoachmanMIS LiasonCommented:
I'm confused...

Can you also post a graphical example of the *exact* output you need here.
Probably easiest would be to copy the correct data into a temporary table by sorting in reverse order and using SELECT (TOP 1) in a sub-query to isolate just the record you want for each core part number.

However I think there is a deeper issue here because the table design is badly non-normalized and there appears to be no need for it. Repeating fields (all the OEMSubNumber fields) are VERY bad practice and can make life very difficult  down the road. I think a better design might be a master table along the lines of:

PartNumber, SubCode, SubNumber, OEMPartNumber, OEMDescription, IsActive, Parent

eg: 1637276, M, 1, 1637276M1, USE PN 1637276M2, False, 0
to 1637276, M, 7, 1637276M7, USE PN 1637276M8, True, 1637276M6

Then you could generate your current view on the fly with a Crosstab query plus filtering can be done based on aggregate functions since you want to keep Max(OEMSubNumber)

Ths will give you a normalized design and should still give the output you need. I use a similar design in a generic version control system where each change is logged and I can then produce a detailed version history very easily. Essentially it's a 1-directional linked list. Or if you need to be able to browse both ways make it a bidirectional linked list. That depends on your specific application.

bignadadAuthor Commented:
This is the result im after
what to keep
I have heard many people mention how denormalized my table is ever since i started and no one has offered to explain how to go about normalizing it.
With your example i see what your talking about. however the [PartNumber, SubCode, SubNumber] would be touch to achieve. im working with part numbers from many different vendors and they all are different in schemes.

I do like the idea of the isactive and parent though. question is how the hell do i get it to that point from where im at now.

When i started with this table it had everything in 3 columns. OEMPartNumber, OEMDescription, OEMSubNumber.

Problem with that is i am using this as a cross reference to retrieve all possible oem numbers and match it to the OEMItem that is in my AMI table. Once i get that matched it can display my AMI Part Number.

So to get all these sub numbers in line with the main number i have been doing a multiple step query and it worked will for John Deere table, but with this table the sub numbers are in a cascading order and that is causing me issues.

This is the Step7 query im using to get my sub numbers to match to the main OEM Part number
SELECT DuplicateStep6.OEMPartNumber, DuplicateStep6.OEMDescription, DuplicateStep6.OEMSubNumber, DuplicateStep6.OEMSubNumber2, DuplicateStep6.OEMSubNumber3, DuplicateStep6.OEMSubNumber4, DuplicateStep6.OEMSubNumber5, DuplicateStep6.OEMSubNumber6, Agco.OEMPartNumber AS OEMSubNumber7
FROM DuplicateStep6 LEFT JOIN Agco ON DuplicateStep6.OEMSubNumber6 = Agco.OEMSubNumber

Open in new window

So if i went back to my original table and tried to get in the format you suggest how would i do that? could you explain if i started a new question?
this is the way the table looks in my original table before i started my step query

original table
Network Scalability - Handle Complex Environments

Monitor your entire network from a single platform. Free 30 Day Trial Now!

bignadadAuthor Commented:
It also might be worth noting that i don't care the part is obsolete/discontinued.

All i care about is finding every possible OEM Number that subs to one another and comparing those to my OEMItem in my AMI Table. That is what retrieves my AMI Item number
On normalization there are libraries filled with stuff on this (see Wiki as a start). However an excellent start is to achieve what is called 3rd Normal Form (3NF). The more advanced NF's become ever more finicky and are generally not a big issue unless you are designing a major database likely to have multiple different and varying clients.

Again, the language gets complicated. I like the tongue-in-cheek summary. Essentially you have:

1NF: No repeating fields!
2NF: 1NF + All data fields should depend upon the whole of the key fields.
3NF: 2NF + All data fields should depend on nothing other than the key fields.

2NF assumes multiple field keys (which with natural keys is inevitable) - it is trivially correct for single field keys.

This can be summarized in the mantra:
"No repeating fields and all fields shall depend upon the key, the whole key, and nothing but the key. So help me Codd."

E F Codd is credited as the inventor of the relational model and normalization.

As for implementation a little bit depends on what the fields mean. It looks very like the SubNumber is actually a pointer to the replacement? Or is that just an accident of the data you're using? Is it true that each PartNumber can only have 0 or 1 SubNumber's or is that again an accident of the example data?

Basically to normalize properly it is impolrtant to understand the real relationships within the data and that is not clear to me here. You have a list in the form string, string, string but the 3rd string appears to be a foreign key from other records in the table...and as such the constraints need to be explored to correctly define a path forward.

For example: in the abstract do you have a list, a linked-list, a tree or a graph? How do you tell?
1. List = no relationship between records
2. Linked list = each record points to its predecessor and/or successor.
3. Tree = each record can have 0-1 parent, but 0-n children.
4. Graph = each record can have 0-n connections to other records (optionally directional)

Trees also get called hierarchies, graphs get called networks (e.g. the Web).

Implementation gets more complex as you move up that list - but it is very important to recognize what you really have because fixing it later is a nightmare. To paraphrase Einstein - a model should be as simple as possible, and no simpler!:-)


Experts Exchange Solution brought to you by ConnectWise

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
:) Hi.

How did this end-up in Access? (Other questions of a similar nature have this in SQL Server)
and these images display OEMSubNumber7 - oh dear....

May I make this observation? This table structure is causing you endless trouble and what really needs to happen is that it should be normalized (i.e. this is the table structure that is transposed to multiple rows to facilitate searching)
bignadadAuthor Commented:
Portletpaul coups you please contact me via email?  I have some thing to run by you please.
Umm. Access, SQL Server, Oracle, MySQL etc. etc. are all relational databases. So the question belongs in the forum for the engine being used. A SQL Server solution to this would not run in Access and vice versa. Especially as, with a normalized table design, it's probably going need Crosstab queries which are implemented very differently in the two engines.

The normalization is easy. The final solution depends on how the data is being sourced and what type of data structure fits the data. Based on some guesswork on the rquirements and assuming a list structure as the basis I suggest a modified linked list (see diagram).

But to get this right needs a little more information. Especially with respect to the end result needed. We haven't even discussed hiw AMI Part Number yet.

Example normalized link list structure
Adding the root part number will allow much more flexible querying since a group of related part numbers will share that without needing to walk the list. All that really remains is to fugure out how best to populate this table from his data source p he is already doing some preprocessing - this just varies that slightly to end with a normalized structure.

Bignadad, sorry but I believe this is contrary to the site policy - additionally you gain here by a variety of views from a diverse group of widely experienced experts.

My doubt about your table structure is that by having multiple columns for substitute part-numbers you by necessity then have to include each of those columns in a variety of queries - which in turn affects overall performance and complexity of the solution.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.