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.
Related
I am new to MS Access and VBA coding, and what I know I had to teach myself through video tutorials and reading up on the web. I have an input Form which which gets its data from a query. The query itself gets its information from a table and another query. The reason is that the other query is what filters the data so that the current user can only see his/ her own records, and not that of others. It has been designed in such a way that if a subordinate changes from supervisor, one merely have to update the supervisor name, and all the prior data in the table for that subordinate will also then reflect for the new supervisor, and no longer the old supervisor.
The problem is that the delete button on the input Form (which was created with the button wizard) not only delete the record from the table, but also from the table used to filter the subordinates. I only want it to delete the record from the actual table used in the data source query.
How would I go about to stop it from deleting in both tables?
I have attached a snapshot of a portion of the data source query, just so that you can understand what is meant by the above. The delete button on the input Form deletes the data from the table named "TableReviewNotes" and "TableAuditorNames". It should only delete the record from "TableReviewNotes".
Thanks in advance.
I want to preface this by saying I don't have any real programming background, I'm just trying to update an existing database at work.
We have an access database and I want to add an additional Y/N checkbox to an existing form. The form updates a SQL table. Currently the record source is a SQL statement.
I can go to the SQL table, add a new field and make it Yes/No data type. There are other Yes/No fields in the table and the default settings for the new field are identical to the others. I next go and update the linked table through External Data in the ribbon. I can go into the table in Access and see the new field - so far, so good.
Next, go to the form design view and form properties, go to the record source, update the SQL statement to include the new field. (I've also tried this thru query builder, same result.) From here, I start to get the error.
If I go back to form view and change any data in the form and hit the next record button or save button, I get the Write Conflict error. "This record has been changed by another user since you started editing it..." The 'Save Record' button is greyed out. I am the only person accessing the database or SQL server.
I've tried to finish building the new button and linking it to the new field in control source (that went fine), but it didn't make any difference. If I go in to edit the record source and remove the new field, everything works again (but of course, the new field isn't in the control source list, so isn't linked to the check box).
Any ideas? Thanks.
A strong contender for the reason for your problem is the form itself.
Most likely the form is setup with a specific query as the Record Source. Its not to say that that is inherently incorrect, but it makes adding new columns to the source significantly more difficult.
The problem would likely be solved if you just changed the Record Source to reference the table itself, rather than a query, if that is in fact how it is referenced.
If Ms Access tries to pull data from a table using a query through a form it will inherently Pessimistically Lock the table in question, making it unable to be modified. However, you can usually still modify the table through the query itself, but you would need to add the column changes into that query first.
I'm not quite sure if I am making sense here, but something like this (for a table called "Table1"):
In theory, if the form is the problem... then if you closed it and tried to make modifications to the table, then the changes should work when the form is closed.
Someone else fixed it for me, but from what I understand, it was a communication issue between SQL and Access. Something with the setting of the null value in SQL not being set the way that Access could understand.
We had the issue narrowed down. When the new field was added to the table, you couldn't change any info directly in the table, but you could with the form.
If you added the new field to the form's record source, you couldn't edit any info at all.
Thanks for everyone's input.
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.
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 Access 2003 database which uses a main form with a datasheet in a subform. The main form allows the user to select from a menu which updates the recordsource of the subform. The subform also updates the number and type of fields available for editing based on the number and types of fields in the form's recordsource. It's basically a dynamic datasheet generator. This works just fine in Access 2003 and has been for years. If I open the same database in Access 2007 (full or runtime), most of the menu selections work. However, if I choose any menu option that references one particular table, the subform shows column headers, but does not show any rows of data or display any errors. It's as if the query is returning zero rows. Why would there be a difference in Access 2007? Did they add new reserved words?
Things I've tried:
Updated every field in the table to ensure there are no null values (no change)
Renamed every field and the table name just in case there are new reserved words (no change)
Compacted and repaired the front end and back end (no change)
Tried including and excluding fields one by one to see if anything changed (no change)
Put the form's recordsource in a new query. (it returned the expected number of rows)
Checked to make sure the form is not set to data entry mode. (It's not)
Checked to ensure that no filters were being applied in code. (none were)
Checked to make sure the query is updateable in Access 2007. (It is)
Selectively deleted chunks of data from the source table. (no change)
I'm stumped.
I was able to finally resolve the issue. As I noted above, my datasheet is a subform. The parent form sets the options that determine how the subform will be built. While the datasheet is being built, the subform's sourceobject is replaced with a blank form to hide the prior datasheet and present a smooth transition to the new datasheet. It works beautifully in Access 2000/2003.
When the blank form is replaced with the new datasheet in Access 2007, I found that Access is automatically assigning the primary key of the subform data to the LinkMasterFields and LinkChildFields properties of the unbound parent form. Those properties had previously been blank, and I never set them in code. Perhaps this is as an attempt by Access 2007 to be helpful rather than a bug, but the behavior difference is not noted in any tech reference I can find, including the built-in help file. Since the parent form is unbound, it has the effect of filtering out all of my subform records. If I explicitly set LinkMasterFields="" and LinkMChildFields="" during the form substitution step, everything works as it did before. Hooray!
Again, the solution is that when setting the sourceobject of a subform, be sure to explicitly set the linkmastfields and linkchildfields properties to prevent Access from doing it for you. I hope this saves someone the hours of frustration I experienced.