In my table I have one unique customer number per many invoice numbers. I only want to see that unique customer number with a summary of all the invoices on the print preview screen and see the unique customer number associated with the invoices on the list of the combo box using the drop down arrow. How do I do that? I am using Access 2007
Sounds like your first problem would be addressed with writing a report to show the result of a query that would list the summary details of all invoices tied to a customer number. This number would be fed to the query from your calling form.
Your second issue sounds like a combo box on your form that would be populated by a SQL SELECT statement in your control source that would pull information on invoice numbers tied to the customer number presented on the form.
I'm being general as I don't know your implementation, and you have failed to provide any context and previously tried-and-failed code.
Related
I have a form that uses a query to open and display a specific customer info based on a customer ID that is manually entered by the user.
The form populates with the customer info from a table where the customer ID can only occur one time. A sub form opens below the customer info with a list of items owned by that customer from another table where the customer ID can occur many times but the items owned is limited by a unique Serial Number.
I have this form set to No Edits so someone does not hose up the original data.
I would like for the user to select a particular Owned Item / Serial Number, and have that SN copied and used to automatically populate another query to open a new work request on that SN.
I don't know if this is possible or not but if so some help with the code or macro would be most helpful.
I understand that using Ctrl C and Ctrl V are the simple answer but the people using this don't want the extra effort and in some cases it is beyond them to even that right.
Create a buttom in the subform and write there a code to start a new record with the same serial as the current record in the subform
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.
I'm pretty new to Access and coding in general and I've been working on a database that was filled with data extracted from SAP.
I have a query that works as a way to "summarize" the information of a bunch of records from some purchase orders, it does sum the total of each PO, it's date as well as other information. It does consolidate a variety of items related to the purchase order into a single record that is displayed in a continuous subform for easy analysis in this structure.
[MES_CORTE][SOLPED][PO][FirstMIGO][TOTALPOVALUE]
This way, the user can preview easily each purchase order, date, value and other relevant information. This query is also used to generate some reports.
However, I want to be able of opening the source table ([Registro_OC]) and search the related records by clicking a field on the subform for a detailed view and posibly to edit or enter new data. is it posible?
I've tried to code some macros but can't figure out how to reference the table fields related to the query fields that are on the form.
Also, it seems that Access doesn't allow to create subforms based on continous forms.
Any help and opinions are appreciated.
I have a table [inventory] with inventory items, and a bunch of columns with different information for those. Mainly, part#, description, price. I am trying to create both a purchase order form [POForm] and, and a inventory transactions form [TransactionsForm], but that one thing I've been stuck on is getting a combo box look up I use to select the part# from [inventory], to also fill my fields for description, and price for that item in my form. I need the fields that are filled to be able to have formula's run off of them, and the information to be saved into the table for that form [TransactionsTable], [POTable].
I've tried making my part# combo box include the fields for the description and price, and using =[part#].[column](x) in the other fields as a lookup, and it looks right visually, but that is apparently just a visual of that data, but technically the field is still blank, because those other fields remain empty in the table for that form, and I am not able to run a formula off the price.
As per my understanding and please correct me if I am wrong. you have a form that shows your inventory data Part# Description & price. This form has a combo box that allows you to select a particular part # to view its related record data description and price.
Now you want to click a command button after selecting a particular part # to update your transaction form and POtable.
1.you have to create a query,
2.insert the inventory table in it
3.select append from the query type in the ms access ribbon
4.a window will appear, choose the transaction table as the destination table to append to.
5.double click on the fields that you want to retrieve its data from the inventory table
6.then in the table below in the query itself in the "append to" row you will find drop-down menu including all the fields from the transaction table. choose the corresponding fields. note if the fields have the same name in both tables access will do it automatically.
7.in the criteria row type the following [Forms]![Inventory Form Name]![the name of the field in the form]. do that for each field in the happen query.
8.save the query and name it
9.go-to design view in your inventory form and create a command button, in the click on event creat macro of the following: openquery-->type the append query name
10.save and close macro builder
11.open your form, select part#, click on the button
12.access will ask you to confirm appending process. click ok/yes
13.check your transaction table to confirm that the append process was successfully performed
14.Tip if you do not want the confirmation msg of append to appear, in the click on event go to the macro builder and choose in the ribbon show all actions then in the first line of the macro builder insert setwarnings - NO
the same is to be applied for the POtable.
Anyways, I hope you find this clear and helpful but I have only one concern you do not have to append part description and price in transaction and PO tables as you already have this data in your database in the inventory table. Generally speaking no need to include the same information in multiple tables otherwise you are not benefitting from the idea of a relational database.
I hope I addressed your inquiry.
I have a table that stores invoices and a form based off of that table that looks like an invoice so that you can search previous invoices. Currently I am creating the invoices in excel and then exporting the data as a new record into the Invoice table. I was wondering if there was a way I could create the invoices from my Invoice form. I have a table of all of the products and prices we carry that would used for the invoice.
Is there a way to put a search button on the invoice form that would search for a record or "product" in the product table and insert it into the fields of a new invoice?
I have looked a some code to connect to the products table and insert it into fields in the invoice form, but how do I search as well?
Any thought or ideas? Any help would be much appreciated!!
Handling this through VBA and control events is typically the best choice:
Use an unbound text box in your form as your search input field. This will allow the user to input some text into a box and hit enter, or click some related "GO" button if you choose to perform some sort of search.
Set the `OnChange` property of this text box control to the name of the macro or method you designed to handle this event (or click event property if you've instead set up a button to a) check the textbox value; and b) handle it; typically allowing for both the user pressing enter or clicking the button to perform this action). You may also simply call an `inputbox` from some button click event to pop up a prompt to allow the user to enter the product value to search for.
Within your handling script, use DLookup() to use that user-supplied value against your products table to get some meaningful product value back which you can then place anywhere on your form.
Also, although I'm not familiar with your particular setup, it seems as though you should ditch your excel file and go with a direct user interfacing MS Access input form. You may find it always easier to deal with user input directly rather than indirectly through oustide files. That way, you have better control over user input validation and user feedback vs fearing whatever the Excel client feels like putting in those spreadsheets.
Not sure this is the right design. Do you only invoice one product at a time?
Also, it doesn't sound as if you are thinking in terms of primary keys.
Nor does it sound as if you thinking "relationally".
Let me clarify. In most invoicing systems, there is usually an Invoices table, then an InvoiceItems table. The relationship between the invoice items and the invoice would be one invoice to (potentially but not necessarily) many items.
Then you have your Products table. The relationship between the Products and InvoiceItems is one product to many InvoiceItems. Ie, you can sell a given product to many different customers.
So we have:
Invoices --> InvoiceItems
Products --> InvoiceItems
Now you need to implement this in your forms.
Matching your tables and their relationships, you create an InvoiceForm and you create an InvoiceItemsSubForm. The InvoiceItemsSubForm, to hold many items, is a continuous form.
In the InvoiceItemsSubForm, you will have a field that takes the Primary Key of the Product (along with other fields such as date, number of products purchased, etc).
To search for your products, you can have a combo box that has the ProductId and ProductName fields. This combo box serves two purposes: it allows you to search for your products, and it allows you to input the product you want in your InvoiceItem record.
If I have misunderstood your question, my apologies. If I haven't misunderstood your question, you have a lot to learn...