Page 1 of 2 12 LastLast
Results 1 to 15 of 27
  1. #1
    dylcon is offline Competent Performer
    Windows 7 64bit Access 2010 32bit
    Join Date
    May 2013
    Location
    Ann Arbor
    Posts
    130

    Synchronization of database setup and form design


    Hello, I have recently created a database meant for managing inventory.
    I have started writing queries and bulding forms, and a lot of it is running smoothly, but I am having a few snags.
    To give a brief background, I am currently designing a form in which a user will fill out when an incoming part comes into our company. The form NEEDS to ask the user for at least the PartNumber and the PONumber, but the way I have my relationships set up, I am not exactly sure how to design the forms (not the physical layout, but where the data goes). So when I have an incoming part, will I use the PartPOID to figure out which part number and PO number it is? I am not exactly sure how to make a form for the user that is not confusing.

    Attached is a picture of my relationships and my database.
    New Compressed (zipped) Folder.zipClick image for larger version. 

Name:	Capture6.jpg 
Views:	12 
Size:	76.2 KB 
ID:	12665

  2. #2
    Join Date
    May 2013
    Location
    Dallas TX
    Posts
    1,742
    The wonderful thing about Access is that, to Access, a query is just like a table. Now that your tables are structured pretty well, you can create a query that has the information that you are looking for, then treat that query as a table.

    So, first, create a single query (say, qryPartPOAll) that, for each tblPartPO record, gives you ALL the information from that point right. (PartInfo, POinfo, Customer, PartType).

    Once you have that query, you can design your simplest interface that meets your needs.

    For example, on the form header, you could have controls that allow the user to select the company, and/or the PO, and/or the Part Number. I've done this before, where each of the three controls has an AfterUpdate that sets a value and calls a common routine to build (and turn on) the filter used by a form or control. I also put a "Clear" button to turn off all the filters.

    The result of this might appear in another combobox control that displays any POs and Part Numbers that are available given those settings.

    You'll need to think about precedence rules for the controls, exception handling, and so on. If the user changes the company dropdown, for example, the PO and PartNo dropdowns should reset before the SQL is rebuilt. Whether (or when) you want the PartNo and PO dropdowns to detect NotInlist and move to an add screen. That kind of stuff.

    If anybody knows of a good sample database that includes this kind of functionality, please chime in. It's not quite a classic cascading combobox application, since the PO and Part are mutually interdependent and many-to-many.

  3. #3
    dylcon is offline Competent Performer
    Windows 7 64bit Access 2010 32bit
    Join Date
    May 2013
    Location
    Ann Arbor
    Posts
    130
    Dal,
    That makes sense and is helpful for the next step, but how do I connect the Part# to the PO# when a part comes in? Will this be connected by the PartPOID?

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

    High Level Screen Flow

    That link is established by the tblPartPo record that you (in most cases) will have entered previously. There's lots of ways you can design this, but you need to make sure that the tblpartInfo record and the tblPOInfo record are both created before the tblPartPo (obviously), and the tblPartPO record must exist before any Incoming, Outgoing or Adjustment record is created for them.

    So, your first form designs must be the forms that allow efficient entry of those three simplest types of records. I've listed the various designs in a sort of modular order, so that each one can build on the work from the prior ones.

    First, create simple screens for
    A) entering company info.
    B) entering PO info -- JUST the POs, for a selected company.
    C) entering Part info -- JUST the parts, for a selected company.

    Next, create a screen for entering the tblPartPo records for a company.

    Sample design - Dialog for PO/Part combination
    D1) Select existing PO (if not existing, popup screen B to enter new PO)
    D2) Select existing part (if not existing, popup screen C to Enter new Part)
    D3) validate that no tblPartPO record already exists for the combination
    D4) Create tblPartPO record

    Next, design the data entry screen for Incoming, which will be very similar to the ones for outgoing and adjustments. Outgoing and adjustments will NEVER have to deal with the issue of part/PO combinations that do not exist, so you might be tempted to code those screens first. I would not do that, since a good design for this one will FORCE a good design for the simpler screens. YMMV.

    Let me give you an example design for dialog E - the interface doesn't have to work this particular way, but this interface would work.

    E0) When a part arrives, presumably there is a packing slip or something that includes the part number and the relevant PO number.

    E1) Your data entry form for shipping arrivals will allow the user to select/enter the company.

    If the company exists, your form would populate a dropdown for PO and a dropdown for part number.

    If the company does not exist, then your form would pop up dialog A to allow entry of a new company.

    Then either

    E2(a) Your user can then select/enter the PO number.

    If the PO number does not exist, then your form would pop up dialog D to allow entry of a new PO and part combination.

    If the PO number exists, your form would re-populate the dropdown for part number, limiting to that PO. (Crosscheck - If there are no parts for that PO, then your form would pop up dialog D to allow entry of a new PO and part combination.)

    E2(b) Your user can then select/enter the part number.

    If the Part number does not exist, then your form would pop up dialog D to allow entry of a new PO and part combination.

    If the part number exists, your form would re-populate the dropdown for PO number, limiting to that part. (Crosscheck - If there are no POs for that Part, then your form would pop up dialog D to allow entry of a new PO and part combination.)

    E2(c) Alternative Design - If the total number of parts and POs are expected to be low for each company, say, less than 10-15 valid combinations at any one time, you could just provide a drop-down box with the valid combinations. If more than that, you could provide text boxes for the PO number and/or the part number, and have the text boxes enable the filter for a single combined dropdown that displays available valid combinations. If the combination is not listed, give the user a button to launch dialog D.

    E3) Once the company, Part and PO number were selected and match, the form would allow entry of a new receiving record for that part and PO. "Selected and match" means there must exist a PartPOID record with that PartID and that POInfoID.

    F) After you've completed dialog E, clone it and simplify for screen F to make it do only what you need for outgoing shipments, linking it to the different tables etc.

    G) After you've completed dialog F, clone it and add a dropdown to select the adjustment type, linking it to the different tables etc.


    That's the vast majority of your high-level system design. Does that all make sense?

  5. #5
    dylcon is offline Competent Performer
    Windows 7 64bit Access 2010 32bit
    Join Date
    May 2013
    Location
    Ann Arbor
    Posts
    130
    Dal, you are the most helpful and thorough person that I know of. Thank you very much. If I have further questions regarding this, I will ask, but as of now, my high-level system design seems to be achieved and I will mark this thread as solved.

  6. #6
    dylcon is offline Competent Performer
    Windows 7 64bit Access 2010 32bit
    Join Date
    May 2013
    Location
    Ann Arbor
    Posts
    130
    Dal, would it make more sense to not allow the user to enter in Dialog D, but instead use a query to append the records from the tblPartInfo and tblPOInfo to tblPartPO? This way the user does not have to go through the relatively not-so-intuitive/seemingly unnecessary inputs. I am just not 100% sure how the timing would work out for this.

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

    Either or

    I believe that's just a confusion about terminology. I was trying to describe an example approach, and it wasn't intended to circumscribe your methodology, for instance, whether you added the new records via an append query, or whether you instead used a form opened in data entry mode, or exactly how you got the requisite new records into the PO and Part tables.

    There are a few technical requirements based upon record dependencies. The company record must exist before the Part or PO records can be created, right? The Part and PO must both exist before a PartPO record can be created, right? Otherwise, there's nothing to link the PartPO record to. Likewise, the PartPO must exist before any of the transaction records can be created.

    So, occasionally, when the guy is on the PartPO entry screen, and he needs a part that is NOT already in the database for that company, what happens? Somehow, he has to go back to screen C to enter the part. The workflow must facilitate that happening, whether it is by calling Screen C itself, calling a clone of Screen C, showing a different dedicated subform, or some other way. (Same thing for PO.)

    Advice: In general, you should design the workflow the way that (1) minimizes the effort by the user, (2) causes the user to do it right automatically, and (3) is supportable at your current level of expertise. In other words, a way that doesn't involve weird conniptions in the user's workflow or in your code. You can write it out in prose, like I did, or draw little pictures, or whatever makes you comfortable that you know what behavior will make the entry job easy.

    Now, whether you prefer to put screen C as a hidden subform on the D screen and unhide it when needed, or pop it up modally or non-modally in front of screen D, or just msgbox "sorry, Bud, no such part; Go to screen C first, then come back here" is a workflow design issue. Please be aware of the technical requirement that you'll have to refresh the queries after the new part or PO record is added, but otherwise do it any way that makes sense to you.

    What I wrote out for you is quick and dirty high-level analysis. Pretend I'm telling you some stuff about remodeling your bathroom. The critical rule is - it's your bathroom.

    I could be wrong - I do that at least once or twice a day, just to keep in practice - and also I could be right but sloppy in my phraseology, and also I could be right in what I say but not telling you something important that I'm not happening to think about, like to put that s-trap (I think it's called) under your sink to catch the smells.

    If what I wrote seems hard or wonky, then do it another way. You'll work out the details as you refine and implement the design. No worries.

  8. #8
    dylcon is offline Competent Performer
    Windows 7 64bit Access 2010 32bit
    Join Date
    May 2013
    Location
    Ann Arbor
    Posts
    130
    Ok, sounds good. Thanks again Dal

  9. #9
    dylcon is offline Competent Performer
    Windows 7 64bit Access 2010 32bit
    Join Date
    May 2013
    Location
    Ann Arbor
    Posts
    130

    Parts D and E

    Hello again Dal,

    I have a couple of questions...again.

    D) How can I check that a no tblPartPO record already exists for a certain combination of Part and PO. I have the fields indexed within the table, but I would prefer to check it on my own as well so I can give the user a warning and reset the form.

    E) When filling the combo boxes, how would I properly cascade them? It seems difficult because I am searching through tblPartPO where only the ID's exist as FKs and not the actual PartNumber or PONumber. I would prefer to not use lookups (as I have heard they can cause errors) and it would not make as much sense for the comboboxes to be filled using the PartInfo and POInfo tables... any suggestions?

    I am also having trouble with filling the PartPOID. Once the proper customer, PO number, and part number were selected and matched, how do I get the proper PartPOID onto the tblIncoming? My plan was to correctly cascade the comboboxes, which means that there would only be one choice for the PartPOID. I could just have this hidden on the form, but still have it's control source go to its FK on the tblIncoming. My only problem is that I do not know how cascade the combobox based upon two different criteria.
    Last edited by dylcon; 06-11-2013 at 12:56 PM.

  10. #10
    Join Date
    May 2013
    Location
    Dallas TX
    Posts
    1,742
    Okay, a lot of these are versions of the same question. Here's the root question: How do I code the SQL to get the key of a record that matches X description, and how do I know if there are none that fit?

    If you could answer that root question, then it solves both questions D and ... let's call the last question F.

    The answer to question F is, you take the value you want and enter it into the appropriate control on the form/subform, that is bound to the field your want the information in. You could do that by setting the defaultvalue for that bound control on the form or subform, or a master/child link field, with the subform opened as data entry, or whatever.

    The cascade question E is more complicated. But, first, I want to correct what you said.
    I am searching through tblPartPO where only the ID's exist as FKs and not the actual PartNumber or PONumber
    Nope. You are searching via a query that joins some tables. You are correct that the tblPartPO record is at the left side of the join, and the tblPartInfo and tblPOInfo records *must* exist for each tblPartPO record. So, build the query for the whole thing, and then use the two combo boxes to filter the query results.

    I'll work on a description of one or more ways to code the cascade.

  11. #11
    dylcon is offline Competent Performer
    Windows 7 64bit Access 2010 32bit
    Join Date
    May 2013
    Location
    Ann Arbor
    Posts
    130
    Dal, I believe that I have already have my comboboxes set up for part E. I have working combo boxes that fill in the PartNumber and matching PONumber for a given CustomerName. I did not build a query for the whole thing. Would you mind explaining further what exactly this means?

    I am, however, still confused about how I would get the PartPOID. Unless I am misunderstanding what is being said, I would prefer that the user does not see this relatively arbitrary (at least from the users standpoint) piece of information.
    Last edited by dylcon; 06-11-2013 at 02:15 PM. Reason: Unsure about query building

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

    Simple Enough

    Hmmm. I seem to have lost a relatively lengthy post describing one possible method, but your post makes it irrelevant. oh well.

    Absolutely right that the user should never need to see the partPOID, but it is crucial that you have it available behind the scenes. You get it by asking for it from a query that has the info you need. If you have the POInfoID and the PartID, it can be as simple as
    Code:
    txtPartPOID = NZ(DLookup([partPOID],"tblpartPO","PartID = " & txtPartID & " AND POInfoID = " & txtPOInfoID),0)
    ' then test txtPartPOID for zero to make sure you got a record rather than NULL...
    Dmax and DMin would get the same result, and are useful to remember if your query might return multiple records.

    The reason I assumed you would code the whole query for JOINing the three tables (or even five) is that you'll need the related PONumber and PartNumber almost every time you use the tblPartPO, so I'd create a qryPartPOInfo that you can pull up any time you need to see that stuff together.

  13. #13
    dylcon is offline Competent Performer
    Windows 7 64bit Access 2010 32bit
    Join Date
    May 2013
    Location
    Ann Arbor
    Posts
    130
    Ok, thanks a lot for the helpful suggestion. Since I have the POInfoID and the PartID after the user selects the form, I inserted that statement into an event, but for some reason it gave me an error

    I have been doing some reading on INNER JOIN queries and I am wondering if this is what is required of me to use. I have also noticed that it seems like these table would already have been 'joined' together because there is a relationship. Like I said earlier, I still don't understand this process too well, so if you could explian how to go about creating this query, that would be a significant help. If I need to start a new thread, please let me know. Thanks again!

    Edit:
    So I will leave the above, but I have been doing some reading on queries and realized how useful they are. So just to make sure I am on the right track:
    1) I have created a query that creates a table that now has the PartPOID, PartID, PartNumber, POInfoID, and PONumber.
    2) Next step is to use filters (Customer-->PartNumber-->PONumber-->PartPOID).
    3) The PartPOID will not appear on the form for the user, but the number will be used for my transaction tables.

    Does this sound like I am on the right track?
    Attached Files Attached Files
    Last edited by dylcon; 06-12-2013 at 10:00 AM. Reason: New Findings

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

    Big Picture: QUERIES, SQL AND JOINS

    Okay, lots of ground to cover. This post is the Big Picture about joins. And, it looks like you don't need it anymore, given your 11:00 edit of post 13...

    QUERIES, SQL AND JOINS

    If a query contains more than one table, then any way you make it happen, in the background somewhere there will be a JOIN written in SQL. (If there's only one table, there probably won't be a JOIN.)

    Check out Chapter 6 of Crystal Long's Tutorial for a quick overview of SQL, at
    http://www.accessmvp.com/Strive4Peac...Chapter_06.pdf. Look at figures 6-2 and 6-3, which show the design view and SQL view of the same query. Then look at the text immediately following figure 6-3, where Crystal cleans up the SQL and bolds some items to explain what they mean.

    INNER JOINS

    An INNER JOIN means that only the matching records from each table will be returned from the query. The same INNER JOIN query can be coded multiple ways. The following two queries are equivalent, if I've coded them correctly. The first version is an implicit INNER JOIN, while the second one is an explicit version of the same INNER JOIN.
    Code:
    SELECT Table1.Key, Table1.Field1, Table1.Field2, Table2.Field3
    FROM Table1, Table2 
    WHERE Table1.Key = Table2.Table1Key
    AND Table1.Field1 = "X";
    
    SELECT Table1.Key, Table1.Field1, Table1.Field2, Table2.Field3
    FROM Table1
    INNER JOIN Table2 
    ON Table1.Key = Table2.Table1Key
    WHERE Table1.Field1 = "X";
    OUTER JOINS

    A LEFT JOIN, which is an example of an OUTER JOIN, will return all the records from the first (left) table, along with the matching records from the second (right) table. If no matching record exists on the right table, then all fields from the right table will show up as NULL.
    There's no technical difference between these two OUTER JOIN queries, if I've coded them correctly.
    Code:
    SELECT A.*, B.* 
    FROM TableA AS A
    LEFT JOIN TableB AS B 
    ON A.Key1 = B.Key2;
    
    SELECT A.*, B.* 
    FROM TableB AS B
    RIGHT JOIN TableA AS A
    ON A.Key1 = B.Key2;
    The two OUTER JOINs above are equivalent, but programmers, by convention, use LEFT JOINS in preference to RIGHT JOINs. That convention allows you to remember that the far left table is the one from which all records are retained.

    FULL JOINS, CROSS JOINS, ETC

    A FULL OUTER JOIN is like a LEFT and RIGHT join at the same time... all appropriate records in both tables will be returned, with NULL in the other table's fields if there was no match in the other table. I don't use these much.

    A CROSS JOIN, also called a Cartesian product, basically joins every record of the left table to every record of the right table. This is extremely useful, but only in a few situations. Here's one write-up of that subject http://weblogs.sqlteam.com/jeffs/arc...9/12/7755.aspx.

    PIVOT table joins are cool things for analysis of data, which I've never yet had a need for, so I can't speak to them. Crystal Long writes about them in Chapter 6, the link I gave you above.

  15. #15
    Join Date
    May 2013
    Location
    Dallas TX
    Posts
    1,742
    dylcon -Yes, exactly right.

    BUT, you didn't have to actually make a temporary table for that. In most circumstances, as far as Access is concerned, a query IS a table. Just about anyplace you can use a table, you can use a stored query.

    The exception is when you are doing complex joins of queries and tables until the Jet db engine just gets too confused to figure it all out, then you might implement a temporary table to make the instructions simpler for Jet's limited brainpower --and for any programmers who might have to follow you, including yourself in the middle of the night a few months down the road.

    Looks like your SQL build for PONumbercbo in PartNumbercbo_AfterUpdate() needs one less SELECT statement, and needs a JOIN to get the PONumber. Try this:
    Code:
        strSourceOne = "SELECT PP.PartPOID, PO.PONumber " & _
                        "FROM tblPartPO AS PP, tblPOInfo AS PO " & _
                        "WHERE PartID = " & Me.PartNumbercbo _
                        & " AND PP.POInfoID = PO.POInfoID " _
                        & " ORDER BY PO.PONumber"

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

Similar Threads

  1. Replies: 2
    Last Post: 01-28-2013, 04:42 PM
  2. New Database Setup
    By sirwalterjones in forum Access
    Replies: 3
    Last Post: 12-14-2011, 08:38 PM
  3. Help database setup please!
    By clzhou in forum Access
    Replies: 4
    Last Post: 07-10-2011, 11:30 PM
  4. DB Design & Table Setup Help
    By Zanzibarjones in forum Database Design
    Replies: 58
    Last Post: 06-14-2011, 10:54 AM
  5. Need help with database setup
    By ctyler in forum Database Design
    Replies: 6
    Last Post: 08-30-2010, 01:35 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