I have a ComboBox on a subform and for some reason it is not possible to select an item from the list.
What should I look at to try and fix this please?
I have tried all the ideas I could think of, and have established the below:
The combobox's Locked property is False.
The subform's AllowEdits property is Yes.
The subform's AllowAdditions is No, but changing it to Yes does not fix my problem, and causes another error.
The combobox is bound and the subform's recordset type is an updateable snapshot.
It is a database I have inherited, which now has an Access 2010 frontend, and apparently this combobox did used to work before we migrated over from Access 2003.
Thank you for any help you can give!
Have you tried to change the locked and allowed properties at run-time, my VBA is very rusty but are you sure there are no other events in Code being fired when you select an item?
Related
I encountered this error when I tried to open a Report.
The record source '~sq_dProduct Summary~sq_dOLEUnbound0' specified on this form or report does not exist.
The name of the recordsource may be misspelled, the recordsource was deleted or renamed, or the recordsource exists in a different database.
In the Form or Report's Design view or Layout view, display the property sheet by clicking the Properties button, and then set the RecordSource property to an existing table or query.
And it came up to be a blank "Print Preview" report. But when I right-click on the report and go to "Design View", there are data inside. I don't know what is wrong. Can anyone please help?
This the naming convention Access uses to create queries behind the scenes when you set a RecordSource property using the builder button in design view of a form/report. When you press the builder button, you are presented with a QBE window (Query By Example). When you save the form or report, Access creates this query, hides it from the DB container, and uses it internally, although you see the actual SQL in the RecordSource property. This is why it appears to work in design view.
The problem is that the DB Engine can no longer find this "cached", hidden query.
I would:
Copy the RecordSource property of the form or report to a text file.
Drop the reports RecordSource Repair and compact the database
Reopen the report, and paste in the RecordSource again.
If you are using subforms, combo boxes, list boxes, etc. that may also have a RecordSource property, you should do the same with them until you find the culprit. In other words, anywhere in the design of the report/form that you see a RecordSource property that has a SQL statement as the value for the RecordSource property.
A sure way to get around it is to create a normal query, then set the RecordSource property of all of the the form/report/controls to this permanent Access object.
In ms access I have a form which also has a sub-form. I wanted to programmatically change the RecordsetType in the main-form to snapshot when the sub-table/sub-form has associated records in the one-to-many relationship. I wrote some vba code to do this but I was experiencing some very odd behaviour.
I then discovered that it was because when I change the RecordsetType, the form refreshes and navigates back to the first record. That then causes the On Current event and associated code to fire in both the sub-form and main-form twice. I was thinking of using DoCmd.SearchForRecord to navigate back to the original record but quickly realized that it wouldn't work because the the WHERE condition in the DoCmd.SearchForRecord gets overridden when the events fire the second time around. It all seemed so inefficient any way.
Are there any other methods to do what I am trying to do? I don't really want to set the controls in the form to 'Disabled'.
MS Access has a selection of form properties that should suit: AllowEdits, AllowDeletions and AllowAdditions. These can be set separately or together. In this case, it seems that you need AllowAddition set to Yes and AllowEdits set to No.
I recently got help on When select value from combo, highlight that record in Access subform datasheet and now I'm trying to do a related task.
How can I make the subform give me a new row for data entry from a button on the main form?
Tried the method found here with no luck: http://www.access-programmers.co.uk/forums/showthread.php?t=26537
EDIT: Not sure if it matters, but the table my subform is supposed to update is a linked table to SQL Server.
Please first make sure your recordsource is updateable by opening the table or query in which your subform recordsource is based, and ensure that you can edit and add new records. If not, then it's possible that your SQL Server linked table is missing a unique indentifier. To create one, simply delete the linked table, and relink it. Upon relinking, MS Access should prompt you to specify a unique index (may take more than one field to make it truly unique). Then try again.
If the subform datasheet is editable and with AllowAdditions turned on, it should already give you the * button to add a new row.
If it doesn't, then you need to check the datasheet's properties and change them to match what you're actually seeking.
it has been a while since I used Access. Doesn't the RecordSource property of the subform give you the underlying table or query. If the source is editable, you should be able to add a record then Requery or Refresh the subform.
For those who need just to add a new record to sub form: just set focus from main form to subform. Then use DoCmd to add new record:
Forms![MainFormName]![SubFormName].SetFocus
DoCmd.GoToRecord , , acNewRec
I have what I believe to be a common question about using a subform in datasheet view in access. My subform has a checkbox on it which performs some logic but checking any checkbox checks that checkbox for all the records. From what I see this behaviour can be altered by linking the checkbox to a datasource. However in my case the subform is based on a non-updatable query so binding to any member of the dataset results in the checkbox being uncheckable.
I am imagining some dastardly temporary table workarounds for this problem but they all feel like horrific hacks. Is there some way around this which won't make me feel too dirty?
So all the data controls, except that one check box, are bound to read-only query fields. And the check box is not bound to anything.
You could base your form on a disconnected ADO recordset. See this article at Database Journal: Create In-Memory ADO Recordsets
That technique seems less dirty to me than using a temporary table to accommodate the check box. Although you didn't tell us anything about the purpose of the check box, I'll hazard a guess this could work for your application.
this has me pretty confused and I can't find the answer anywhere else so thought I'd post here to see if anyone can help!
I have a form in an Access 2007 database with a subform (sfSubform) embedded in it. The subform control's SourceObject is set to be another form (fForm). fForm's RecordSource starts out as a table.
At one point I want to change the data displayed in the subform to the result of a SQL statement, so I use
sfSubform.Form.RecordSource = strSQL.
This works fine. However, if I ouput the name of the RecordSource for fForm after making this change, it still gives the name of the table that I orginially set.
Does sfSubform.Form.RecordSource not change the source of fForm? Is it a copy of fForm that is embedded in the control?
Hope all that makes sense.
The sub-form and the form each have their own record source (or are unbound). That's the whole point, actually -- the ability to present two different data sets. Typically the two forms have related record sources and this relationship is declared using Master/Child Link, but that also is optional according to the need.
So no, changing one won't cause the other to be changed.