Gregory Rogers20 said:Thank you so much, I will certainly give that a shot.

Well,
@Kyle Johnson2/">@
@Kyle Johnson2, I truly gave this my absolute all, so please don't say I didn't put in the effort!
Naturally, as is often the case with these technical endeavors, I have run headlong into a few more hurdles.
1) Regarding the area highlighted in red in the image—only Group A is functioning quite right; however, for groups B, C, and D, it keeps spitting out "NN" under the "HDCP" column. It is clear something needs adjusting, though I am at a complete loss as to what specifically is causing the glitch.
2) Looking at the section marked in orange—it simply isn't working correctly when multiple players share the exact same HDCP in the database. Currently, the group list only displays one of them. What I really need is for the system to show every single player; for instance, if there are three different people in the database with an identical HDCP of (8,5), then all three should appear in that group, each with their own unique name, even if they share that same HDCP value. 🙂
3) As I mentioned previously, the database shouldn't be "fixed" or static because we are talking about athlete registration—think of it like someone signing up online via a website. Because people register whenever they want, the entries become a bit of a jumble; they aren't sorted by any specific number or name, but rather just added chronologically as they come in. That is why I emphasized that I want the formula to scan the entire database instead of treating it as a series of segmented groups...
In other words, why is the formula only searching positions 1-13 for Group A, or 14-26 for Group B, when the formula
really ought to be scouring the entire database, spanning from
positions 1 through 52.
4) Furthermore, the group ranges (the HDCP values, where the MIN and MAX are listed) are also fixed and unchanging. This creates a real headache; for example, if I have a Group A ranging from 1.5 to 12.4, but nobody in the database actually holds a 1.5 or a 12.4 HDCP, or if Group B tries to look for an HDCP that actually falls within Group A's range, the formula just wipes everything out and leaves everyone with empty fields. It’s quite illogical! The computer has no way of knowing which athlete will sign up next, what their specific HDCP might be, or which group they will ultimately land in.
Please, please don't be annoyed with me, but I have truly built this as far as my current abilities allow.
I am sharing my work here, and I sincerely hope that someone might be able to help resolve at least some of these issues.
Here is the file for you to look over.
http://www.mediafire.com/file/3hiv33db6v5z39r/baza.zip