Page 1 of 2 12 LastLast
Results 1 to 15 of 23
  1. #1
    fedebrin is offline Novice
    Windows 7 64bit Access 2010 64bit
    Join Date
    Jun 2013
    Posts
    10

    Relate two calculated fields

    Good day!

    I am not an familiar with VBA therefore please be kind ...

    I work for a shipping company and currently working on a database where our sales team can enter weekly projections (forecasts)
    I will then like for both the sales and my department to analyze what was projected versus what was actually loaded (I will update the table with the actual volume that was loaded)

    In principle, the tables I have in mind are:

    1)CUSTOMER with fields:
    o Customer code
    o Customer name

    2)VOLUME PROJECTED with fields:
    o ID
    o Customer code
    o Port of Loading
    o Port of discharge
    o Number of Containers loading WEEK1
    o Number of Containers loading WEEK2


    o Number of Containers loading WEEK3

    3)VOLUME LOADED with fields:
    o ID
    o Customer code
    o Port of Loading
    o Port of discharge
    o Number of Containers loading WEEK1
    o Number of Containers loading WEEK2
    o Number of Containers loading WEEK3

    I have been trying to produce a user friendly FORM where sales can see for a specific customer 2 datasheets (sub forms with vol loaded and projected) and that they can filter to display same info on both datasheets

    The problem I am having is when trying to make a calculated field a PRIMARY ID or trying to relate the VOLUME PROJECTED and VOLUME LOADED tables.
    The IDs on each table to identify each unique table are: [Customer code]&[Port of Loading]&[Port of discharge]

    Is there a way to relate the tables in an easier manner or have a primary key from a calculated field

    Thanks!

  2. #2
    Join Date
    May 2013
    Location
    Dallas TX
    Posts
    1,742

    Quick Analysis and Suggestion

    You're making it too hard for yourself, based upon your preliminary design. let me walk you through my thinking.

    Okay, so an example of the information you are storing in the database is
    For Acme Freight, As/of June 10,
    How many containers are we projecting to ship from Akron to Taos
    for the weeks of June 10-16, June 17-23, and June 24-30
    and a week later,
    For Acme Freight, as/of June 17,
    How many containers are we projecting to ship from Akron to Taos
    for the weeks of June 17-23, June 24-30, and July 1-7.
    And then on June 24, you want to look back and ask,
    How did our projections on June 10 and June 17 match what we actually shipped on June 10-16 and June 17-23?
    Right?

    So, I think you'll get more ability to do analysis if you normalize the projected-by-week and loaded-by-week information to their own tables.

    Code:
    Projection
      ProjKey  (primary Key)
      CompanyKey  (foreign key to company)
      ProjMadeDate
      (various information about the projection and who made it)
    
    ProjByWeek
      PBWKey   (primary key)        
      ProjKey  (foreign Key to projection)
      PBWProjDate         
      PBWProjContainers   
    
    LoadByWeek
      LBWKey    (primary key)        
      CompanyKey
      LoadDate         
      LoadContainers
    Also, it seems odd to me that you'd want to clump your customers' actual behavior at all, in terms of database design, unless your contracts have three-week cycles. It's possible, but I don't know a real-life shipping industry application that would expect that behavior for many of its customers. Thus, I'd expect that you want to break the actual behavior down by DAY, then aggregate it to weeks when you are doing your analysis. But, I've left it by week in the above example. YMMV.

    Given this kind of redesign, your attempt to match calculated fields becomes unneeded, because you'll be comparing information using simple joins on company and date, and just having to pick which of the various projections you are picking (because the -2 week projection for +3 weeks, the -1 projection for +2, and the 0 projection for +1 all refer to the same calendar week.)

  3. #3
    fedebrin is offline Novice
    Windows 7 64bit Access 2010 64bit
    Join Date
    Jun 2013
    Posts
    10
    Hi!

    To your phrase: "I think you'll get more ability to do analysis if you normalize the projected-by-week and loaded-by-week information to their own tables."

    Yes, I have set up individual tables: (1) for projection and (2) for volume loaded.
    and I think you are right, I was over-complicating myself
    trying to link the 2 tables

    Now, I have the created a FORM for sales to easily fill out their projections. The form has 2 subforms (DATASHEETS) one displaying the volume loaded and another datasheet where they can enter all the info for the projections...it will be ideal that when the sales reps applies a filter on the projections datasheet (for example filtering a port of loading) that the datasheet below showing the volume loaded filters as well by the same value

  4. #4
    fedebrin is offline Novice
    Windows 7 64bit Access 2010 64bit
    Join Date
    Jun 2013
    Posts
    10
    I found that I definitely need to relate the two tables given that the POL of the volume loaded is foreign to the POL of the volume projected, where it is complicated is when we have a combination of POL-POD and how can ACCESS identified they are the same...PLEASE HELP!

    One way around (but not practical) is to have one field combining the POL and POD (this is the way the Sales will have to enter it)

  5. #5
    Join Date
    May 2013
    Location
    Dallas TX
    Posts
    1,742
    Do not panic. There is always a way, and usuallly several.

    Your choices -

    (1) Store the POL and POD separately on both the projection records and the actual records. This means that, when you do the analysis, your join will be joining on both conditions. That's not tough. It'll look kind of like this in places.
    Code:
    WHERE ProjCompany = ActCompany 
       AND ProjPOL = ActPOL 
       AND ProjPOD = ActPOD

    (2) Create a POL-POD table and give each combination of POL and POD a unique key. This makes your joins much more efficient to read and run, but it also means that you'll need to join in the POL/POD table and the PortName table when you want to see the actual port names. That's also not tough, but it's more programming up front (dealing with missing combinations of Ports when they occur, and so on.)

    Typically, how I've seen this done is, they choose POL on one drop-down, choose POD on a second one, and the second drop-down box sets a field that states the combination. There's hidden field on the form that holds the key to that POLPOD record. When that second dropdown box is selected, it reads the POLPOD table and checks for existence of that combination, creating it if needed.

    Of course, you can just create a cross of all the ports as POL and POD, and every time you add a new port, add it as POL for every port except itself, and POD for every port INCLUDING itself, and you'll have a full cross without duplicates. Then, there will never be a missing combination, and the discussion is moot.

  6. #6
    fedebrin is offline Novice
    Windows 7 64bit Access 2010 64bit
    Join Date
    Jun 2013
    Posts
    10
    ok, excellent! now this might sound silly but I am not familiar with VB: where would I paste the following Code?

    WHERE ProjCompany = ActCompany AND ProjPOL = ActPOL AND ProjPOD = ActPOD

  7. #7
    fedebrin is offline Novice
    Windows 7 64bit Access 2010 64bit
    Join Date
    Jun 2013
    Posts
    10
    A problem that I also forgot to mention is that for the volume loaded the port pair combinations will not have duplicate (ie only one record of volume loaded for Miami to Kingston) but for the sales projections there will be several records for Miami to Kingston differentiated on commodity.

    I explain below:

    LOADED:
    Miami to Kingston 10 containers loaded on week 20

    PROJECTIONS:
    Miami to Kingston 5 containers of oranges to load on week 20
    Miami to Kingston 5 container of mangoes to load on week 20

    When a query is created the records are repeated

  8. #8
    ssanfu is offline Master of Nothing
    Windows XP Access 2000
    Join Date
    Sep 2010
    Location
    Anchorage, Alaska, USA
    Posts
    9,664
    PMFJI...
    I have been lurking, watching this thread (I am always trying to learn) and I will go back to lurking after this post.
    The structure the OP proposed was not normalized. Every time a week was added, almost every object would have to be modified.

    So I threw together a demo. My demo seems way different than what Dal is providing - like he said, there are many ways.
    Not wanting to confuse the issue, I am not posting my dB (unless there is interest in seeing my method - as unfinished as it is).



    So, now back to the aforementioned lurking. (I wish there was a lurking smilie)

  9. #9
    Join Date
    May 2013
    Location
    Dallas TX
    Posts
    1,742
    fedebrin post#6 - that kind of code would go wherever you were trying to join and analyze the information. You'd adapt that idea to the query that you were trying to do. More on this later.

    fedebrin post#7 - Okay, that's a slight change... but it doesn't hurt too much. Let me make sure - does your actual loading information arrive in a weekly, aggregate form, or are you going to get somthing like this:

    * Miami to Kingston 3 containers loaded on day 142
    * Miami to Kingston 5 containers loaded on day 145
    * Miami to Kingston 2 containers loaded on day 147

    Either way will work, but the way I show above gives you more information to analyze in the long run.

    ssanfu post#8- which structure, the one fedebrin proposed in post #1? Correct, it was clearly not normalized, and would have been a royal pain to do analysis on. With people who aren't very technical, I don't worry about the technical terminology, I talk about "how do we get the information that you want". Third normal form almost always appears naturally when you correctly analyze the entities and the data usage.

  10. #10
    Join Date
    May 2013
    Location
    Dallas TX
    Posts
    1,742

    A Basic Tables and Query Design

    Okay, for this example, I'm going to assume that all your data is in this form. I'm not worrying about how it got that way.
    Code:
    tblProjection
      ProjKey  (primary Key)
      CompanyKey  (foreign key to tblCompany)
      RouteKey    (foreign key to tblRoute - POLPOD table)
      ProjMadeDate
      (various information about the projection and who made it)
    
    tblProjByWeek
      PBWKey   (primary key)        
      ProjKey  (foreign Key to projection)
      PBWProjDate         
      PBWProjContainers   
      PBWprojProduct
    
    tblLoadByWeek
      LBWKey      (primary key)        
      CompanyKey  (foreign key to company table)
      RouteKey    (foreign key to POLPOD table)
      LoadDate         
      LoadContainers
    
    tblCompany
      CompanyKey   (primary key)        
      CompanyName
    
    tblRoute        (POLPOD table)
      RouteID       (primary key)        
      POLPort       (foreign key to tblPort for POL)
      PODPort       (foreign key to tblPort for POD)
    
    tblPort
      PortKey       (primary Key)
      PortName
    Now, I'm going to assume, just for simplicity, that your Loads and projections are all stored on a weekly basis, and LoadDate and PBWProjDate are always going to be the Monday of your accounting week. The code would be slightly different if the dates didn't automatically align.
    First, here's the query (call it qryActLoad) to get the actual results for all companies for all weeks:
    Code:
    SELECT 
       LBW.LoadDate AS EventDate,
       "A" AS EventType,
       LBW.CompanyKey AS CompanyKey,  
       LBW.RouteKey AS RouteKey,
       LBW.LoadDate AS LoadDate,         
       LBW.LoadContainers AS LoadContainers
    FROM tblLoadByWeek AS LBW;
    Second, here's the query (call it qryProjLoad) to get all projected results for all companies for all weeks:
    Code:
    SELECT 
       PROJ.ProjMadeDate AS EventDate,
       "P" AS EventType,
       PROJ.CompanyKey AS CompanyKey,  
       PROJ.RouteKey AS RouteKey,
       PBW.PBWProjDate AS LoadDate,         
       SUM(PBWProjContainers) AS LoadContainers
    FROM tblProjection AS PROJ INNER JOIN tblProjByWeek AS PBW
    ON PROJ.ProjKey = PBW.ProjKey
    GROUP BY EventDate, CompanyKey, RouteKey, LoadDate
    Now, you'll notice that the structure of both those tables is exactly the same, and that if you smashed the two of those queries together, you'd have the total loaded for each week in the "A" record, with the week's date as the EventDate, and the prior projections of the total loaded for each week would be in "P" records, with the date the projection was MADE in the event date.

    So, now we can make a UNION query to get all the information for one Combination of company, Route, and range of LoadDates like this:
    Code:
    SELECT * FROM qryActLoad
    WHERE CompanyKey = 27 
    AND RouteKey = 218
    AND LoadDate BETWEEN #05/06/2013# AND #06/03/2013#
    UNION
    SELECT * FROM qryProjLoad
    WHERE CompanyKey = 27 
    AND RouteKey = 218
    AND LoadDate BETWEEN #05/06/2013# AND #06/03/2013#
    Later, we'll have to bind those queries to the Company table to get the company name, and to the route and port tables to get the port names, but I wanted to make the example as easy as possible so you see what is happening.

    The key to being able to use a database is to understand what entity each table represents, so that when you join them together, you are enforcing the true relationship between the entities, rather than doing things accidentally or by rote.

    I'll pause now for questions, because I know you'll have them.

  11. #11
    ssanfu is offline Master of Nothing
    Windows XP Access 2000
    Join Date
    Sep 2010
    Location
    Anchorage, Alaska, USA
    Posts
    9,664
    ssanfu post#8- which structure, the one fedebrin proposed in post #1? Correct, it was clearly not normalized,
    Correct.

    <lurking mode again >

  12. #12
    fedebrin is offline Novice
    Windows 7 64bit Access 2010 64bit
    Join Date
    Jun 2013
    Posts
    10
    Hi ssanfu, thanks for contributing...ideally I will have the Sales entering the projections assigning them to specific weeks. The info of the loaded cargo will also be on this format

    Therefore I would have fields labeled for every week of the year from Week#1 through Week#52...

    Sorry again if was not clear from the beginning , below I show again the tables I originally had in mind

    1)CUSTOMER with fields:
    Customer code
    Customer name

    2)VOLUME PROJECTED with fields:
    ID
    Customer code
    Port of Loading
    Port of discharge
    Number of Containers loading WEEK1
    Number of Containers loading WEEK2
    Number of Containers loading WEEK3
    Number of Conainers loading WEEK...
    Number of Conainers loading WEEK...
    ...
    Number of Conainers loading WEEK52



    3)VOLUME LOADED with fields:
    ID
    Customer code
    Port of Loading
    Port of discharge
    Number of Containers loading WEEK1
    Number of Containers loading WEEK2
    Number of Containers loading WEEK3
    Number of Conainers loading WEEK...
    Number of Conainers loading WEEK...
    ...
    Number of Conainers loading WEEK52

  13. #13
    ssanfu is offline Master of Nothing
    Windows XP Access 2000
    Join Date
    Sep 2010
    Location
    Anchorage, Alaska, USA
    Posts
    9,664
    Therefore I would have fields labeled for every week of the year from Week#1 through Week#52
    This is not a normalized structure. You would be committing "Spreadsheet". While datasheet mode *might* look like a spreadsheet, it is totally different.

    See Dal's proposed structure (Post#10). It has NO repeating fields (ie Week1, Week2, Week3, ...) because it breaks normalization rules.

    While we have basically the same structure, he has more detail. Follow his lead.....

  14. #14
    Join Date
    May 2013
    Location
    Dallas TX
    Posts
    1,742
    See Dal's proposed structure (Post#10). It has NO repeating fields (ie Week1, Week2, Week3, ...) because it breaks normalization rules.
    Clarification of ssanfu's two different uses of "it" in one sentence...

    It [Dal's proposed structure] has NO repeating fields (ie Week1, Week2, Week3, ...) because it [repeating fields in a record] breaks normalization rules.
    fedebrin - the reason you don't want to put all the weekly projections horizontally on one record is because then it would be nearly impossible to, for example, analyze how the projections for a particular week had changed over time. As the code above has demonstrated, that analysis is almost trivial to do with properly normalized tables.

  15. #15
    fedebrin is offline Novice
    Windows 7 64bit Access 2010 64bit
    Join Date
    Jun 2013
    Posts
    10
    I am trying...will let you know, thanks again for your excellent help!

Page 1 of 2 12 LastLast
Please reply to this thread with any new information or opinions.

Similar Threads

  1. Calculated fields
    By FinChase in forum Queries
    Replies: 5
    Last Post: 02-02-2012, 06:12 PM
  2. Calculated fields?
    By crcastilla in forum Queries
    Replies: 2
    Last Post: 10-31-2011, 09:30 AM
  3. Calculated Fields Help
    By Mossy in forum Queries
    Replies: 4
    Last Post: 10-10-2011, 01:13 AM
  4. Calculated fields
    By graciemora in forum Forms
    Replies: 1
    Last Post: 02-04-2011, 06:07 AM
  5. Replies: 1
    Last Post: 07-25-2009, 05:06 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Other Forums: Microsoft Office Forums