Yes, I sure can! Attached.
Sales_Tracker_amended_1.1.odb (5.8 KB)
Also,
in case it’s an OS related or LibreOffice distro for my OS, my os is Linux Mint 21.3 MATE 64-bit
in case it’s an OS related or LibreOffice distro for my OS, my os is Linux Mint 21.3 MATE 64-bit
OK, I’m not sure what is going on now. I began using the DB you provided to build my database and create a form. I can make edits in the table, but I can not make changes to some of the sub-form (using a query for sales records) fields in the form. I do not have them set to “read only.”
Sales_Tracker_Dev.odb (21.2 KB)
@WJoel,
I looked at Villeroys attachment and it does an admirable job in displaying the data using a style similar to your own.
.
the source of the issue with the database that you uploaded ‘Sales_Tracker_Dev.odb’ was a failure to link the main-form and sub-form Master to Slave fields.
‘Sales_Tracker_Dev.odb’ includes several queries which filter the data by date.
there are more versatile methods you can use in order to achieve similar results, take a look at this attachment:
SalesT3.odb (25.6 KB)
That’s what I was doing wrong! Thank you very much cpb. I really appreciate your patience, recommendations and help.
Thank you very much Villeroy! I never realized how good a form could work and look. You did a great job creating them and it looks fantastic!
We have a one-to-many relation between 2 tables. Each sale belongs to exactly one company. One company can have zero, one or more sales. I drew the relation line in the relations manager. The one-side is a primary key, the many side is a foreign key.
The default setting for such a relation make it impossible to enter a sale with a non-existing company ID or delete a company as long as there are any sales of that company in the sales table. This is called “referencial integrity”.
Given that a table is editable (has a primary key), SELECT * FROM "table" always returns an editable record set. Instead of the sales table itself, I created a query SELECT "table".*, <some calculation> AS "alias" FROM "table"which simply appends to the table fields a calculation result under some title “alias”.
The company of each sale is referenced by an integer company ID. List boxes let us select a company ID by name and write the corresponding ID into the foreign key field. The listbox query SELECT "Company Name", "Company ID" FROM "Table_Companies" ORDER BY "Company Name" ASC fills a listbox with visible names in the first column while writing the second column’s ID value into the sales table. Since each sale belongs to one company, the subform only shows a single record with the company details. I forgot to disable the navigation toolbar for this single record. It might be a good idea to keep the parent form’s navigation bar when the subform has the focus.
The other view point on a one-to-many relation is represented in the companies form. The one-side is represented in the main form. The many-side is in the subform.