As vanilla as you can get: A main form with the order details (i.e cust number, delivery address, etc) and a subform with the actual details of the order (product code, quantity, etc). So far, so generic, and I'm really embarrassed to be this stuck.
Right now, with this setup, I'm in one of two scenarios - either:
getting duplicate order records: The first one (when I open the form) is created and links to the customer ID no problem (using rs.AddNew). However, when the form finishes populating the bound fields it shows a new order number in the order number control (that's not created yet, as far as I can see from refreshing the table). Then when I use the subform to add the order details, it creates the links to this new order number, which doesn't have the customer number in it.
If I remove the .AddNew to the recordset in my form_load, I end up not creating a new Order record (and the order number control shows "(New)"), but when I start to add order details, I then get told that I haven't given the order number in my order detail entry.
I suspect I'm entirely confused and have too many queries/too much code in too many places.
Standard table setup:Customer, Orders, Order_Detail, Products.
Order_Detail has an autonumber PK, but FKs to Orders and Products, as you'd expect.
I've got a main form that has a query that returns all the data that should go on the form. For the time being, most of the form is unbound, because I was struggling so badly with this. I can change that easily enough though.
The subform has the parent/child link set, and so I'm just at a loss.
I recognise that I'm doing something stupid: When I do the .AddNew, it's all good. When I go back and populate the form with bound values it creates a new order. If I don't populate the controls, I get (new) and none of it works.
Main form record source:
SELECT Orders.ID, Orders.Customer_Id, Orders.Display_Order_Id, Orders.Date_Ordered, Orders.Notes, Orders.Deliver_Date, Orders.Delivery_Address, Orders.Web_Order_Id, Orders.Order_Cost, Orders.Discount_Amount, Orders.Delivery_Title, Orders.Delivery_First_Name, Orders.Delivery_Surname, Orders.Billing_Address, Orders.EmplID, Orders.SpecificDelivery, Orders.CallRequired FROM Orders;
(If I remove this, it asks for ID when the form launches, so...)
Master: ID (from the Orders table)
Child: Order_ID (from the Order_Detail table)
Sfrm query (I've reduced this to be as simple as possible - it's essentially select * from order_detail)
SELECT Order_Detail.ID, Order_Detail.Order_Id, Order_Detail.Product_Id, Order_Detail.UnitPrice, Order_Detail.Quantity, Order_Detail.Discount, Order_Detail.Last_Updt_Tstamp, Order_Detail.UserID
FROM Order_Detail;
All I want to have happen is create a new order for the customer number that potentially allows it to have no Order Detail, but when it does have order detail, it doesn't throw an error.
Related
I am new to Microsoft Access and I am trying to build a Case Tracking system for our Employee Relations folks. I have a table for Employees and a table for Cases. They are linked by Employee ID. I also have a form to incorporates fields from both tables so they can fill out when a case comes in. How do I save the data on the form into a master case history table? I want to capture the employee data as it was when the case was added since departments, managers and other fields are dynamic for the Employee. My form includes:
Employee Table
Employee ID,
Company,
Job Family Group,
Cases Table
Case Number,
Case Date,
Case Type,
I know I can obviously write a query to join them, but it will show me the employee facts as they are as of the last data refresh. Any help you can provide would be greatly appreciated! Thank you again.
Actually, the way you approach this?
Well, you have a main form - employees.
Then, you have (make) a sub form of cases.
Now, that sub form can be a grid like display - perhaps you select (click) on a row to show + edit more details, or perhaps just a sub form as a grid (continues form) will suffice.
In other words, you don't make the form update both tables at once, but in fact use a main form, and a sub form.
Say, I have a table of Hotels. And I need/want to display hotel information, and THEN ALSO display people booked into that hotel?
so, I create a form based on table People. That table People of course has a column that relates back to the hotel they are booked to.
So, you get this:
So, each form STILL ALMOST ALWAYS will be based on ONE table. Don't try and make some multi-table join for the forms data source.
So, in your example?
you build a main form - employees - it can show all the information (and let you edit/add etc.) to that form.
For each case, from the case table?
Well, go off and build a 100% separate form for display of "case(s)".
Then save that form. Now, open up your employee form, and in design mode, simple drag + drop in the cases form into that form.
So, you don't actually base the form and its table on more then one table, but you combine multiple forms EACH based on their one respective table.
But, as above shows, the end result is a main form + sub form, and that gets you the relational database setup, and allows you to do this without having to write code.
Picture of my relevant fields simplified for this example:
I am currently working on updating a database in Access for work that has more or less been just a spreadsheet up to this point. As such, I have a lot of information stored on a single table and I'm looking to avoid creating new tables that have to be manually filled in if possible. I track our purchases, confirming whether or not all the items on a particular purchase order or "PO" has come in, or if that PO only came in with a partial shipment. This database does not track POs as they are created, only as they are received by shipping, so I do not have a separate table that lists all the POs.
I am trying to create checkboxes in my table that synchronize with other checkboxes of the same PO, so when I receive the final shipment in for a PO, I can click "Order Complete?" (see linked image above) and all of the checkboxes with that same PO# will also be selected.
So far, in my fairly limited Access knowledge, I have attempted to make a new table from a query that listed only shipments with PO#s and then removed duplicate PO#s. I put the same "Order Complete?" field in the new table and then linked the PO# field on both tables and the Order Complete? field on both tables, but this didn't match them up. My coding knowledge is fairly limited and a little rusty so I was wondering if there was any simple way to do this without a really deep dive into coding.
I am constructing a MySQL Database with the end goal of creating a GUI CRUD frontend in Microsoft Access. In the attached picture is the layout for the contacts section of this database. [Current table relationships]
Ideally, all of the tables in this screenshot (barring payments) would be populated in one Access form, but I'm having trouble working out a way to make this happen. The most obvious answer (with my limited SQL knowledge) is to create a massive view connecting all of these tables, and then have the Access form call a stored procedure (either one massive SP, or one for each field? Not clear on this) to C/R/U/D the view.
I tested out creating a view with a few tables (one many-to-many relationship and one one-to-many) below:
CREATE
ALGORITHM = UNDEFINED
DEFINER = lauren3#%
SQL SECURITY DEFINER
VIEW peopleformview AS
SELECT
p.PersonID AS personid,
p.Title AS title,
p.FirstName AS firstname,
p.LastName AS lastname,
p.Role AS role,
p.DOB AS dob,
p.PassportNum AS passportnum,
p.Alumni AS alumni,
p.Degree AS degree,
p.Nickname AS nickname,
p.Email AS email,
p.PermissiontoEmail AS permissiontoemail,
ar.agent AS agent,
a.AddressID AS AddressID,
a.Address1 AS Address1,
a.Address2 AS Address2,
a.City AS City,
a.State_Province AS State_Province,
a.PostCode AS PostCode,
a.Country AS Country
FROM
(((people p
LEFT JOIN agentref ar ON ((p.agentref_agentid = ar.agentid)))
LEFT JOIN people_has_addresses pha ON ((pha.people_PersonID = p.PersonID)))
LEFT JOIN addresses a ON ((pha.addresses_AddressID = a.AddressID)))
Am I on the right track here? It seems that such a view would get unweidly quickly.
Be it the desktop, the web or just about any platform?
You model and display and edit relational data by cobbling together parts that are based on the relationships.
But, you actually base each part directly on a single table. You don’t create a view server side to join all that data together. And you don't use SQL either.
If you have one customer, and 30 invoices, then if you join the tables, then the customer will appear 30 times. You can’t possible edit such a mess as one data row.
So this would be the related tables:
So, in the case of access, you would build a form that edits the main customer. Such a form lets you edit one customer at a time. Build that one form – get it working all nice.
Again, above is based on one linked table.
Now, to display the invoices for the one customer? Ok, now build a new form (multiple items form). And you base this form on the invoices table.
Once you build the two forms? Well, open up your main customer form in design mode, and now simply drag + drop in the invoices form from the nave pane.
So, you wind up with a screen like this:
You can see the main form has things like customer name, address etc.
And the other form (a sub form) shows the list of invoices you have for this one customer.
The beauty of Access is it will connect up the main form, and the sub form for you, and do so without code. So, each main customer record you navigate to will now show the child related records in that sub form. You do this by setting the link master and child settings in the sub form control:
Now, of course each invoice will have a “main” invoice part. (Date, customer, maybe billing address). And for each invoice, you will have a child table of invoice details. (Quantity, item, price amount etc. for each thing in that one invoice). So once again, the above simple concept is repeated for this invoice form, and the child form of “invoice details”.
So, in above when I click on an invoice, we simply open up a main invoice form to the ONE invoice record, and the child invoice details is again displayed as a sub form. Like this:
So, be this desktop development, or even web development?
You create a user interface based on dropping parts into a form that are each based on a single table.
So each part that displays records as a general rule will be based on a SINGLE table. You thus as a result for such data editing will NEVER use a view or data joined together for editing.
And with Access you not use any sql either.
Each bit and part you used to edit data will be directly based on ONE single linked table in access and not some view.
As a result, you don’t need views, and you don’t even need sql for each part you build.
The ability to edit relational data will thus be based on how you cobble together each bit and part, but each of those parts are NOT going to be based on some sql query, and in fact not based on a view either. Each of the parts you use will be based directly on a linked table, and a single table at that.
Each part you use here ONLY ever edits ONE record at time. Read that last sentence 10 times to ensure you grasp this simple rule.
So, you can certainly get creative. So, here is an example form that shows 3 tables all at the same time. IN this example, we have an event, a then people and their donation for the event. And we need to split out the donation into different accounts. Someone might give $50, but 10 is for funerals, and the other $40 might be for the school.
The top part is the donation event (one record). ON the left side is a continues form that shows the people that donated to the event, and their amount. And on the right side we show the accounts for a single donation we selected on the left side. Each donation can be split out into multiple accounts.
This is a common and “classic” accounting type screen in which you enter a given amount, but split it out and apply it into multiple accounts.
And again, the above Access form is not based on views or even sql queries, but each part we placed into the form is based a single linked table.
So it is the slicing and dicing of bits and parts that you place into a form that allows and gives you the ability to edit related data, but each part is only based on a single table out of your elated data model.
It is “how” you cobble together these bits and parts that allows the magic of editing of related data. As such, this process and thinking on your part has really very little to do with building views that join together related data. In all of the above examples, I did not write any sql or create any views, and each part was simply based directly on a linked table, and not even some sql. So your related data model is a “guide” and will give you information as to what table and part comes next in building your user interface.
First of all, I am a total NOOB! I am trying to make an Access DB for handling orders through an entire process. As such, I have created tables based on each of the individual processes. The order data, which holds only the basic information is in tblCurrentOrders. Each of the other processes is linked to tblCurrentOrders by the OrderNumber field. The first step of the process is due date information is entered in the tblPlanner table. Obviously, until data is entered in tblPlanner, no OrderNumber exists (this will hold true for the other tables, too, if I ever get that far).
I want to create a form based tblCurrentOrders that shows only the records without corresponding entries in tblPlanner (new orders) and then I want to be able to enter the tblPlanner info in a subform. I have tried making a form based on tblCurrentOrders with a subform based on tblPlanner, but I can't figure out how to only display new orders. I also tried basing the form on a query that only showed new orders, but I don't know how to make the subform based on tblPlanner to work.
Please Help!!
Well, the easiest way to link the tables would be to create your OrderNumber in the tblPlanner when you start a new order. Then add a flag and timestamp as to whether it's "released" yet.
EDIT
Since you provide a little bit more detail, I'll edit my response to more closely align for your desired approach.
Creating a "New Order" is a multi-step process. So it's usually best to create a Command Button on a form that calls VBA code. This will allow you to control each step and make sure it's correct.
Step A: First you want to:
1) Create a Control Form (if you haven't already) that allows you to put Command Buttons which will launch different VBA code or open different display Forms.
2) On the Control Form, create a List Box that allows you to select an existing OrderNumber.
3) On the Control Form, create a Command Button to open an Order Form which uses the selected List Box OrderNumber. When that Order Form opens, it will populate with the tblCurrentOrders data for that OrderNumber and also populate the subform with tblPlanner data. (As long as you have them linked properly.)
4) On the Control Form, create a Command Button to open the Order Form with a set of records which are "New Orders" only. See the more detailed process below in Step C.
5) On the Control Form, create a Command Button to Launch VBA code that will create a "New Order". This is a multi step process detailed below in Step B.
6) Create any other buttons or controls that allow you to monitor or advance your "Order" along the way to completion. (This is a ton of work to get all the pieces in place.)
Step B: When you press the Command Button to create a "New Order" you want to create VBA code that will:
1) Create a new record in the tblCurrentOrders table.
2) Create a Unique OrderNumber on the new Record. It's usually best if you control the generation of this number and don't just let it be a system generated sequence number. But whatever you desire is ok as long as it's Unique.
3) Set your ReleasedFlag to false on the new tblCurrentOrders record.
4) Make sure your ReleasedTimeStamp is null. (Or whatever value you want it to be.)
5) You may want a CreatedTimeStamp which you can populate with a date of Now().
6) Populate any other "Initalization" fields that need to be filled. (Like Backorder status, Return flags, Shorted Flags, etc. etc. etc.)
7) Create a new record in the tblPlanner table.
8) Copy the Unique OrderNumber that you created for the tblCurrentOrders record into the OrderNumber field on the new tblPlanner record. This creates a link for you to use with your subqueries and subforms.
9) Now you can open the Order Form with this new OrderNumber.
Step C: When you press the Command Button to open a set of records which are "New Orders" only:
The Command Button needs to launch a query to find "...tblCurrentOrders that shows only the records without corresponding entries in tblPlanner (new orders)":
You just need to select tblCurrentOrders that have a ReleasedFlag set to false.
`SELECT * FROM tblCurrentOrders WHERE ReleasedFlag = false`
So when you say: "...and then I want to be able to enter the tblPlanner info in a subform"... you can create a subform linking to tblPlanner based on the tblCurrentOrders OrderNumber field.
This is all reliant on you observing that when you say "...records without corresponding entries in tblPlanner..." That you really mean: records without released entries in tblPlanner. And that means: in order for a record to exist in tblCurrentOrders, it has to have a corresponding blank (or starter) record created in tblPlanner. Thus now you can display blank tblPlanner records that are linked to unreleased tblCurrentOrders records.
Then once your data entry people are done monkeying around with the New Order, they can "Release" the order (usually by clicking on a Release Command Button). At that point, you can set your ReleasedTimeStamp to Now() and set your ReleasedFlag to True in the tblCurrentOrders. It's officially no longer a "new order" and is now a live order in your system.
You are at the tip of the iceberg for creating a home grown order entry system. The complexities for building a good one are immense. Best of luck figuring it all out. Just remember to use time stamps and ID fields so you can go back and un-do what may have been done by accident.
Hope this all helps. :)
Basics about the database
I am working on a (relatively) simple database that stores inventory data. I am using Microsoft Access 2010 in order to do this. I have six tables with the following relationships:
Relationships of Database
I have created forms which combine the Transaction table with Ordered, Received, Allocated, or Dispensed. Each form requests an amount which will then be used to update On Hand, On Order, or Allocated (from the Material table) respectively.
The Problem
For example, my form to update Transaction and Order should be able to take in the Amount ordered, save all the data from the fields to the Transaction and Order tables as well as add the amount from Amount to On Order in the Materials table.
I have been working on this database for the past two days. I have searched several times for possible ways to perform a similar function, but have come up with nothing. All the tutorials I have found which seem remotely close to what I need to accomplish are for versions of Access which are much older than 2010. Unfortunately I have had little experience with the actual coding within Access, so I am stuck clicking around within the buttons on its menus.
What I have tried
Currently, the program is set to run the following Update query:
Screenshot of update query
This query works if I have one Material stored in the database but adds all the Amount values from Ordered to On Order every time it is ran, which is unfortunately not what I need it to do. I only need each Amount value added to On Order once.
You need to relate the Ordered and Material tables by adding a foreign key field to the Material table, ex. OrderedFK (Long Integer). This new field must be updated whenever a row is inserted into the Ordered table (assuming the "No" Field is AutoNumber). This is typically performed by using a Form (Ordered) and Sub-Form (Material) and setting the sub-form' Link Master (No) and Link Child fields (OrderedFK).
You can then join the Ordered and Material tables on the Update Query to achieve the desired result.