Help me clean this up: making a series of calculation dependent calculations update when changing...

[bytreeide]

ssanfu,

Thank you for the helpful suggestions. The reason that I have some of my Primary Key Fields as text is because I have an Autonumbering Mechanism working to create the Request Number for each "job". I read somewhere that using the Autonumbers was bad practice because if you have to remove a row for editing or some reason then you permanently lose that number and the new entry would be next one in the sequence. So on Form1Entry I set up my own number counter and then used the queries to get that number into a combo box for each subsequent form. Another reason that I recall what that Autonumbering doesn't support multiple users very well, if there are more then one user inputting data into Form1Entry then there was an understanding that the "universe might implode" when using autonumbers. This might not make sense to you but what you have just suggested runs contrary to what I have initially learned about Access.
The reason for the 1-to-1 relationship between the PK fields is that I wanted data from one record set (on a table or form) to be the only data to be accessed by another specific record set (on another table or form). Judging by the way that you said this is rare, I take it that I should reform my ways.
The attachment fields are intended as place-holders at the moment. My work on this dB will eventually utilized with SharePoint, however my understanding of how this will work is even more limited than my understanding of access.
I didn't try to convert an Excel spreadsheet, but I am very familiar with the way that Excel functions. In data sheet view my tables are short and fat, in design view they are tall and skinny. I tried to do a pivot-table to make it tall and skinny, but that seemed to more complicated than just switching the x- and y-axes, which was all I wanted to do. The ability to make tables appear tall and skinny in the datasheet view still eludes me. I haven't bothered to figure it out, because there are so many other things that I do not understand and this seemed like a small one.
Regarding the fate of the calculated values on Form5EXP and Form6CAP, you mentioned that VBA code would be required to store the values on the table. I thought that that because you changed the name of the Control Source that it would "disconnect" those values from the table. So what If I were to just use the same name again? Where is the harm in that? If I go back to the same name (the one on the Table) that I was using then the values would be saved on the tables, right? Would this make the universe implode again?

Thanks,



bytreeide

[ssanfu]

The reason that I have some of my Primary Key Fields as text is because I have an Autonumbering Mechanism working to create the Request Number for each "job". I read somewhere that using the Autonumbers was bad practice because if you have to remove a row for editing or some reason then you permanently lose that number and the new entry would be next one in the sequence.

You are not using the PK field, you are linking text field to text field.

So on Form1Entry I set up my own number counter and then used the queries to get that number into a combo box for each subsequent form. Another reason that I recall what that Autonumbering doesn't support multiple users very well, if there are more then one user inputting data into Form1Entry then there was an understanding that the "universe might implode" when using autonumbers.
This might not make sense to you but what you have just suggested runs contrary to what I have initially learned about Access.

I have been using Access starting with Access 97. I would advise reading about Autonumbers in the sites I provided. What you have learned about autonumbers is ....well, not correct.

I didn't try to convert an Excel spreadsheet, but I am very familiar with the way that Excel functions.
In data sheet view my tables are short and fat, in design view they are tall and skinny.
I tried to do a pivot-table to make it tall and skinny, but that seemed to more complicated than just switching the x- and y-axes, which was all I wanted to do.
The ability to make tables appear tall and skinny in the datasheet view still eludes me.
I haven't bothered to figure it out, because there are so many other things that I do not understand and this seemed like a small one.

As I said, it "looks" like a spreadsheet design.
Pivoting wouldn't help, the table design is not normalized and needs redesign.

Regarding the fate of the calculated values on Form5EXP and Form6CAP, you mentioned that VBA code would be required to store the values on the table.
I thought that that because you changed the name of the Control Source that it would "disconnect" those values from the table.
So what If I were to just use the same name again?
Where is the harm in that?
If I go back to the same name (the one on the Table) that I was using then the values would be saved on the tables, right?

Attached is another version of your dB using the fields in the tables. There is VBA code to do the calculations. (More on this in a minute)

Would this make the universe implode again?

No and Yes. "No" because it just takes VBA code to do the calculations and save the results.

"Yes" because of SharePoint:

The attachment fields are intended as place-holders at the moment. My work on this dB will eventually utilized with SharePoint,.........

I have never developed for SharePoint. From my understanding, you cannot use VBA with sharePoint. You will have to figure out some other way to do the calculations. Maybe macros.... but I don't use macros either (too limiting).

I have heard there are tutorials on YouTube for using/developing in SharePoint, but I haven't looked for myself.


I hope some of this will help you in your project. Maybe some with SharePoint experience will chime in..........
Good luck....