In my database is a Form based on a query which has a subdatasheet defined. When the Form is in DataSheet view, each record shows the plus sign which can be expanded to show related records according the subdatasheet defined on the source query. In other words, the Datasheet view automatically shows the Subdatasheet--as expected and as desired, so I know it can function like this.
I then created a new Form based on the same query as the existing, working Form. However, the new Datasheet view will not show the Subdatasheet... no plus sign, nothing. Next I created a test database with a couple related tables, and I also ensured that the tables have a Subdatasheet defined. If I open the tables directly I see the plus signs and Subdatasheet as expected. But once again if I define a form on those tables, it will not show the Subdatasheet when viewed in Datasheet mode. There is no separate setting for an Access Form to define the Subdatasheet, rather it can only inherit the Subdatasheet setting from its record source object (i.e. table or query).
Is there any way to force a Form (in Datasheet view) to show the Subdatasheet already defined on the record source object? Why might the new form function differently than the original even when it's based on the same query?
I'm using Access 2013 and database with 2007-2013 file format.
Subdatasheet view is only available in DataSheet view.
Also it is recommended to use Subdatasheet view for only reading and not editing as unexpected errors may result.
From Microsoft:
If you add subdatasheets to your tables, limit the use of these
subdatasheets to viewing, and not editing, important business data. If
you want to edit data in a table, we recommend that you use forms to
edit the data instead of subdatasheets, as data entry errors are more
likely to occur in datasheet view if users are not careful to scroll
to the correct cell. Also note that adding a subdatasheet to a large
table can adversely affect the performance of the table.
Microsoft Office Access automatically creates a subdatasheet when you
create a table that matches one of the following criteria:
The table is in a one-to-one relationship.
The table is the "one" side of a one-to-many relationship, where the
table's SubdatasheetName property is set to Auto.
A relationship is defined by matching the primary key and the foreign
key fields in the related tables.
You can also add a subdatasheet to any table, query, or form in a
database. In Datasheet view, a form can display only one subdatasheet
at a time.
Related
I want to be able to track any changes made to any of the fields in an existing table. The scenario is as follows:
the user opens the datasheet view for an existing table in MS Access 2007/2010
updates values in 2 fields and 5 rows (10 cells)
saves the table (overwrites it)
I want to be able to push the changes (10 changes/rows) to a new table and then be able to open it in datasheet view to refer to it. Is there a way I can do this in access without using form?
In 2010 and later you can use data macros, or what often other systems called table triggers.
You cannot in 2007.
Keep in mind that your use of the term “save table” is VERY wrong in the context here. In fact VERY wrong in the context of most databases. The user does not “save” the table.
You can ONLY edit ONE ROW at a time in a datasheet. When you move off that record then the ROW is saved (not the table). , and if you move off, then the record is saved.
In 2010 and later, you have use of table procedure code. This thus will allow one to use a table trigger.
So 2010 and later does support table triggers and store procedure code. But since your question in includes Access 2007, then my suggestion to use table triggers (called data macros) may not work unless you can restrict users to 2010 and beyond.
In the follow example, when a user updates a row, then a “audit” table is updated with the user information. The function fosusername() is in fact a VBA function. This code is called from the before change update event for the table.
Of course the problem here is the VERY basis of your question assumes that users save a table – they don’t, they edit + save “single” records, or a single row at a time. So figuring “out” how a user is done would certainly be a challenge. So while code can be run when the users edit data, having table code run “when” the user closes the table is not possible.
As the end of the day, it likely best you create a datasheet that looks just like the table, and then change a few settings to “lock down” and prevent the user from using tables directly.
As far as I know there is no solution for this without using a form. I do not know of events (like a change or dirty event) for the actual data tables.
In a form you could use the dirty property to make sure you fetch the data. You can make the form look like a datahseet with DoCmd.RunCommand acCmdDatasheetView or set the form in datasheet view on default.
I have an ancient Access application that I've recently moved the data to a SQL backend using the SQL Server Migration Assistant, and almost everything is working except for one issue.
In the application, we have a form with another form inside of it. The outside form finds specific "issues" entered into the system, and then looks for a history record(the inside form) that is associated with this issue. If a history record is present, it works perfectly, as the record shows up in the embedded form just fine. However, if there is no history record yet present in the database, the entire details sections of the embedded form blank out entirely. The properties are all set exactly the same as when it was a pure Access Database, but now that I've switched it to pull from SQL using Linked Tables, the form is now blank when I don't have a record to pull from.
EDIT: I learned that there are two conditions that when both met will cause a form's details pane to go blank: (1) there are no existing records to be displayed, and (2) it is not possible to add a new record.
This means that the second condition is where my issue lies. I tried scrolling to the bottom of each of the linked tables in Access, and for the History records table, I was not able to add any new rows, but for the Issues table, I was. Something is keeping me from being able to edit this one table for some reason.
I think the behavior you described may happen when the record source of the subform (your "inner form") is read-only. When matching rows exist, they are displayed. But, when no matching rows exist, you can't add a row so the subform's bound data controls are disabled.
Open the subform in Design View. Select the form and open its property sheet (Alt+Enter). Find the Record Source property on the Data tab of the property sheet. If the property value is a SELECT statement, copy it and past into SQL View of a new Access query then switch the query to Datasheet View. If the property is the name of a table or saved query, open that object directly in Datasheet View.
Once you have the form's record source opened in Datasheet View, are you able to add a row? If not, make sure the SQL Server user has INSERT permission for the data source. However, even with INSERT privilege, Access may have linked the data source as read-only if it was unable to identify a field or combination of fields which uniquely identify each row. If that is the case, you may need to re-link the table and tell Access which field(s) to use as the primary key.
The main entity in my database has about a hundred fields. I organized the fields between many tables and added a 1-to-1 relationship between the tables.
For data entry (and later data editing), I envision a "wizard" with a form for each table and a "Next" button to advance to the next screen/table. The primary key would be entered on the first screen and subsequently passed to all remaining screens.
I have heard a tab control with subforms might be the way to go.
What steps should I perform to create this wizard?
Note: Use the following schema as a simplified example of my database.
Sample Schema (can't upload images from work)
You can use a hidden TextField in the parent form which contains your primary ID.
For every of your subforms you just set in the properties that the subform is linked to the content of this textfield. This way you can get all your subforms synchronized.
I need help in creating my first application in MS Access 2007.
Consider a table in MS Access with a column "AgeGroup" and the possible values for this column are "Child" and "Adult". Is there an option in MS Access to enter data into this column using a combo-box with these two values in Datasheet view?
The Simple (but questionable) solution:
(in strict accordance with OP's question)
Create a new table
Add the column which you want to control by a combobox and give it a column name and the Text type.
Make sure that the appropriate column is selected and then click the Lookup tab page in the MS Access table designer
Change the Display Control from TextBox to Combo Box
Select Row Source Type = Value List
Enter the following for Row Source: Child,Adult
Since you probably want to leverage the fact that MS Access is a relational database, you could also have the have the Child and Adult alternatives as rows in a separate AgeCategory table. In order to connect the rows in this table with your combo box you would have to use other Lookup settings. This I leave as an excercise to you.
EDIT: As HansUp is pointing out, it is really not a very good solution define this combo box lookup along with the table definition.
This is probably a better approach for a real world solution:
Create your table
Create a new form which uses your table as data source
Add a combo-box to the form and specify the row sourcing for it
Switch the Form to Datasheet View. A form in Datasheet View looks exactly like the type of row editor which you get when you double-click on a table.
Read The Evils of Lookup Fields in Tables
Instead of creating an evil lookup field in your table, build a form which uses the table (or a query based on the table) as the form's record source.
Add your combo box to the form. Use a value list or another query as the combo's row source. Switch the form to datasheet view. You can also select datasheet for "Default View" on the form's property sheet.
In ms-access 2007, i'm trying to make a form for a table. this table has foreign keys from 2 parent tables. so i thought i would make these fields a lookup. but i couldn't create a single lookup for each parent table because they are composite keys.
I decided to create a query in which for each of these parent tables and the child table with an extra field for each composite key. this works fine with a normal form using an unbound ComboBox... but the unbound ComboBox does not work in a DataSheet Subform. when i make changes to a ComboBox in the Subform code, they are applied to all the other ComboBoxes in the same column as well.
My questions:
is there a way to change the values of the individual unbound ComboBox?
is there a different control i should be using other than the ComboBox or the DataSheet Subform?
what is the normal work around for this situation?
I cannot bind the ComboBox's because the field from the query is calculated/an-expression as I said.
I ran across a form of this problem myself, so for the sake of posterity:
While generally, the advice "Don't use continuous forms/datasheets in this situtation" is the best advice...It is possible to work around this.
However, access will not let you update the value of a single control on a datasheet. What can be used instead in this case is a temporary table, which can, when used as a recordsource, become the values of those controls. You will need to repopulate the table, and requery the controls (requerying the entire form should work as well) every time the calculation needs to change, however. Furthermore, should you enable editing on the controls, you will have to write some VBA on each control to handle the update event (Before Update), and run your own query to update the source tables, not merely the temporary table. Annoying to do perhaps, but effective.
There is another possibillity, which may also work, but I haven't tried to do something quite like this myself. The rowsource of a combobox can be very complex, so it is probable that you do not need to update the comboboxes with VBA at all. The rowsource can depend on other controls (such as another combobox) using the syntax Me.Form!controlName or Forms!FormName!ControlName, which will allow you to form the composite key. Of course, you can also select from queries with a rowsource. What is more interesting is that queries can reference controls on your form, provided the form is open, and you should safely be able to modify that with VBA should you have to.
Between the two of these, you should be able to force access, kicking and screaming, to display any data you wish, even on a datasheet, and to allow the user to change that data (but only if you want it to), and using the BeforeUpdate event, drag modified data back to whatever table it came from.
Continuous forms and datasheets do not work well for editing in situations where combo boxes need to be changed conditionally. The problem is that if you use the OnCurrent event to set the Rowsource of the combo box, it will be OK for that row, but will then hide the stored values for other rows.
The solution is to never use continuous forms/datasheets for editing data when this is the case (I hardly ever use them for editing, in fact). You can create two subforms, a continuous/datasheet subform that functions as a list, and a detail subform, that displays one record. Make the list subform uneditable, and the detail subform editable. You can link the two of them by using the Link Child/Link Master property of the detail subform control, and set it to the PK of the list subform.
If your list subform is Me!List and your detail is Me!Form, and the PK field is MyID, your link properties for the detail subform would be:
Master: Me!List.Form!MyID
Child: MyID
When you move to a different record in the list form, it will be automatically loaded in the child form. Any edits to the previously displayed detail will be saved before record departure.