Tezza444,
I hear you. Now let me try this answer on you. I'll start with what you have heard, though, because I have to use it for comparison purposes.
When you have data in something that looks like a spreadsheet, Excel has functions that allow you to do comparisons within a range that can be horizontal, vertical, or a little bit of both. Those functions are associated with individual cells. It works from the cell outward because Excel data cells are individually independent. That is, you can put anything you please in an Excel data cell regardless of what is to its left, right, top, or bottom. Granted, if you put a function that looks in one or more of those directions, you have stated some degree of dependence. That dependence, however, has to be repeated for every cell. You have ways to repeat a cell definition, but it has to be repeated individually every time you want to look in other cells, i.e. establish dependence.
Access tables are not Excel data cells. You cannot put a function in an Access table. You only put raw data in tables. When you use Access to do that, you take away certain degrees of data independence. The left and right neighbors to a field in an Access table are still totally independent. However, the data format and interpretation of the items on the next or previous row are now fixed by the way the table was defined.
This vertical "lockdown" occurs because Access works vertically when computing what we call aggregates - SUM, MAX, COUNT, etc. For you to design data that has to be treated horizontally (i.e. find the MAX of several fields in the same row) you are stepping away from what Access does. This is why we tell you that you are choosing a wrong data structure.
The fix to this is normalization - among other things, a way to make your data be aligned vertically for various types of aggregate functions including MAX, MIN, COUNT, etc.
In the case where you had some things on the same row and wanted a horizontal aggregate, the "correct" solution in Access is to have each of those items in the row as members of a CHILD TABLE that associates the individual items with some other part of the row that is the parent of that group of elements.
I'll explain that a bit more. In order for you to perform your horizontal aggregate, the logical implication is that the horizontal group of cells containing the values to be tested are all similar in some way. It is clear that you did not understand this fully. The real significance of this condition is that those items are treated alike - but they are different than other items to the left or right of the range of slots they occupy.
This is a VERY significant concept in normalization because it says that the values in question need to be in a separate table. Things that are treated together need to stay together; things that are treated differently need to stay apart. This "purity of usage" or "purity of purpose" eventually leads you to being able to focus on the properties of things that are kept together and to minimize your concern for interactions with things not kept together. The final goal of normalization is to allow you to see AND EXPLOIT how your data sets' parts relate to each other. A side effect of normalization, when done well, is to reduce the size of your data sets to a minimum by minimizing needless repetition of entries.
I hope that gives you something to think about regarding the advice you were given earlier. I reviewed your posts and only see code relating to a coding issue, but nowhere did you tell us what you were actually trying to do using your words to describe the problem. Now the problem that you have left us with is that we don't have any insight into the real-world problem you are attacking. We don't know enough about the specifics of your problem so can't give you much insight in how to solve it specifically to what you are trying to do.
