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?
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?
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.
Alistair
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.
Alistair
ASKER
@boag2000
This is the result im after
@agillanders
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
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
This is the result im after
@agillanders
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.OEMSubNumberSo 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
ASKER
@agillanders
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
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
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
:) 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)
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)
ASKER
Portletpaul coups you please contact me via email? I have some thing to run by you please. Bignadad@gmail.com
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.
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.
Alistair
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.
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.
Alistair
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.
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.
Can you also post a graphical example of the *exact* output you need here.