I have a form with a subform, and I want the subform record source that populates the subform to change depending on the inputs on some combo boxes in the main form.
Using VBA, I have built a function that generates the SQL statement I want to populate the subform with. I know this works because I have tested it with the msgbox and it gives me the SQL statement I want. The sql statement uses an aggregate function so the resulting table has a different structure than the table it is querying from.
The code I use to change the subform record source is:
me![subformname subform].form.recordsource=myfunction()
This has worked for me in the past, but does not work here, I simply get "#Name?" in the subform on my form.
When I open the subform separately I get "#Name?" but when I open the Recourd Source and run the query from the record source I get a value so I am confused.
Any ideas?
Try setting up two subforms - one for each format that you need - and when you swap the underlying recordsets also swap or hide/unhide the relevant subform. Then you can set the controlsource for the relevant controls to the fields that are actually available in the current recordset.
I got it to work by changing the structure of the subform I was changing so that the structure stayed the same when I altered the recordsource. The lesson is, you can change the recordsource in VBA, but you can't change the structure of the subform.
My problem occurred because I used an alias in my subform record source SELECT query. When I replaced the alias table names with the actual database table names in my VBA code, the .recordsource = strSQL01 statement worked and the data appeared in my subform.
Related
I have simple table subform with 2 pulldown comboboxes. The challenge I'm having is that even though I've carefully mapped parameters to the subform's query driven table will NOT populate with data. I have made sure to have the "me.requery" event (after update) for each combobox pulldown.
Combobox 1 = [cmb_opt_verified]
Combobox 2 = [cmb_srv_capture_status]
The comboboxes are within a subform, that is embedded in to tab control, that is embedded into the parent Form
Where
Is the parent form
Is the subform
Is combobox 1
Is combobox 2
Is a table that is powered by a query with the combobox parameters mapped to it.
The table query has the subforms combo-box parameters mapped with respect to the subform's table. The expected result is a list from the application of combobox 1 AND combobox 2 user selection.
[Forms]![Server Data Workbench]![srv_AML_detail].[Form]![cmb_opt_verified]
[Forms]![Server Data Workbench]![srv_AML_detail].[Form]![cmb_srv_capture_status]
I've tried leaving the form running and switching between pulldown options, but not luck. The query is not updating at all even with refreshes. I am able to see the list if I hard code into the query either options from combobox 1 and combobox 2
Is there a way I can determine if the values that are in the comboboxes are truly making it to the query? Or is there something I'm missing in the mapping of the comboboxes to the form and query?
Any help is greatly appreciated.
Embarrassing.. my combobox was bounded to the wrong column. I fixed it by writing in a msgbox [forms]![blah]... and it displayed the recordID and not the text itself. Problem resolved. It's strange how in some cases the bounded column is right while in other cases it's wrong. guess it's MSAccess way to keep you on your toes - or the product is very buggy.
For a client I have to use MS Access 2007 as a lightweight front-end to SQL Server 2008.
One of the requirements, security-wise, is that I need to fetch my recordset data via stored procedures. I'm doing this via SQLOLEDB, based on tutorials provided here: http://accessexperts.com/blog/2011/07/29/sql-server-stored-procedure-guide-for-microsoft-access-part-1/
I have a mainform with some general data, on which I also set the form recordset (Me.recordset) in the code-behind. At the bottom of the form, there is a subform, with a table of rows of data. This is also an ADO recordset being set in the code. In order to make those subform records editable, I made a extra recordset in which I cloned the data in, then I bound it to the subform's recordset (Me.recordset -> but in context subform). I added a save button after each row in the subform, and via an event I'm doing the writes manually via another stored procedure.
This all works, but I get some very weird behavior when I edit some data in the first row (for example), and then click on a field in another row (for example the second row). Now suddenly all my fields change to '#Name?'; basically my subform gets unbound.
Now I'm not sure how to debug this, let stand fix it. Any help on this error is greatly appreciated.
I forget to put tempRs.ActiveConnection = Nothing
It is working as intended now :)
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 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.
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.