I'm doing some development work on an Access 2013 database. Originally, it was designed so that the record source was set at design time and a filter was added to restrict the records on Open. For a couple of reasons, I changed this to where the record source is being cast in code as the form opens -
Me.Form.RecordSource = SQLstr
But when I do this, where the form should be displaying 5 records, it only displays 1 and that is a new record.
When I look at the query in the design screen, the query returns the correct record set.
Curiously, when the form is open, at the bottom of the form, the filter button is yellow. When I click on that, the whole set shows. When I click it again, the set does not change, but continues to show the same (correct) set.
I don't see any code in the filter (there was, but I've removed it). If I clear the Filter in code, then the filter button is disabled and I can only see the one record.
Does anyone see something I'm missing here?
Thanks -
Alan
OK, it looks like I was going too far in referencing the form:
Me.form.RecordSource = SQLstr
puts the code in the correct place (or seems to) but doesn't execute right.
If I use:
Me.RecordSource = SQLstr
Then it works correctly - displays no filter icon on the form and show the right result set
Not sure how referencing the form causes a problem and why (if it causes a problem) it doesn't fail. But that's what I'm getting
Related
Here's the crux of the question, I have 26 compliance queries to run, in a previous question it was suggested that I should filter a single query, or two, on a single report. I like this idea, and have rewritten the query to pull all available data from all the fields, this query works fine. The report will work fine as well, as it does with a model query that I had coded up beforehand. What I would like to do is this:
The end user is being given an interface in access that is locked down, I want them to click a button, and that button will run the query and send to the text box just the field that is called for.
I have tried doing this through VB using the where clause and aliasing the column being called, this did not work at all. I have the report currently pulling the correct data, but not displaying the dates along side it. But it is filtering correctly aside from that.
So what needs to happen is this : Button click : Query runs, and is filtered for "Compliance Issue 1" and puts the dates in "Compliance Issue 1" in the text box on the report.
Right now... I get a list of names, the correct list of names, but an empty column.
I have tried using OpenArgs, but all it did was fill in the date column with "Compliance Issue 1" not the actual data in that column.
Is what I am trying to do even possible in access, and if so does someone have a reference or suggested starting point.
My background : 6 Months of python coding, 3 months of SQL , and some limited access from 20 years ago.
As noted, using the filter of the openreport is without question the way to go (one would not write a whole bunch of different queries - you can send/have any filter for that report - you can EVEN use a sub query in the filter that you send to the report.
As for displaying values in the report that are not from "rows" of data?
There are two approaches that work quite well.
First up, is you have that launcher form. This of course allows the user to select critrea - maybe even some nice combob boxes. These selections take care and you build up the filter in code that you pass to the report.
As for text boxes to be filled out from that form and inclluded in the report?
If they are static values from the report (say filter options, or even just a notes box that you could type in some text? To display such values in textboxes on the report?
You can directly set the text box data source (in the designer) to the report propter form like this:
=(forms!MyPromptForm!notes)
So, any value you shove into text boxes on the report prompt form can thus be displayed in any text box on the report with the above type of expression. And it does not even take code to achieve this goal. So, you could say with above enter some notes into that text box, and thus on the report, whatever you typed into that text box will now show up in the report. You just drop in a text box onto the report, and set the data source of the text box to the above expression that references the form with the values we want from that form.
The next approach, and I often use this in the case that some value/expression/calculation has to occur for each row. In this case, you can use the reports on-detail format event. This allows you to run code for EACH row of data.
You are free to run ANY code in that event - and that includes after running such code to set a text box in the reports detail section.
So, say the query only had the Hotel ID (PK). This is a lame example, but you could then write this code in the on-format event of the reports detail section.
dim strSQL as string
dim rst as DAO.RecordSet
strSQL = "SELECT HotelName from tblHotels where ID = " & me.HotelID
set rst = CurrentDb.OpenRecordSet(strSQL)
me.HotelName = rst!HotelName
rst.Close
So in above, we assume that a row text box is called HotelID, and then in code we build a whole sql query from scratch, pulled the row data from a table, and then SHOVE/SET the value of the un-bound text box called hotelName.
As noted, the above is a simple example, but we are free to run any code we want, pull any data we want, and set the value of ANY text box for the given detail section ONE row of values.
So, above shows two approaches. The first approach is code free - and you can put forms! expression directly into the report, and the values from that report prompt form will thus show up directly in the report. However, if you need VBA code to run for each row, pull values, walk the dog, and THEN set a text box on that one details row of data, then you are as above shows free to write procedural code in the report that fires + runs for each row of data - and that means you can quite much do anything you want in terms of running code. I mean, even that on detail format event COULD pull values from your report prompt form, but as the 1st example shows, you can shove in forms! expression directly into a text box - and those forms! expressions can be values from a existing form that is open before the report is launched.
I have a lot of checkboxes (with yes/no fields in the underlying tables) and lately Access has been crashing a lot. After some research it seems null values in the checkboxes could be to blame, so I set out to follow Allen Browne's instructions (http://allenbrowne.com/NoYesNo.html) for replacing them with number fields. Everything was going great until I got to the step where I set the display control to 106 (checkbox). This is not an option in the table and I don't understand why. I set my table up like he stated but I only have the option for a textbox, listbox, or combobox.
I also tried just typing 106 into the Display Control field, but it gives me an error that it isn't an item on the list. In his article, he mentions to fix the error above to use SetPropertyDAO(), but I have no idea what that means, how to do it, or where to do it. Do I built it in code somewhere? The link he has brings you to a script where he uses that to fix his printers or something.
Close your table.
Open Immediate Window with Ctrl+G
Paste the code:
CurrentDb.TableDefs("Table1").Fields("Field1").Properties("DisplayControl") = CInt(acCheckBox)
Replace table and field name to your names.
Run the code by putting the cursor at the end of the line and hit Return.
If you get an error, open the table in design view, and set the display control to something (it doesn't matter what), save and close, repeat.
I have a report that changes based on the query used in the record source.
I did this to consolidate 6 different reports that printed the same formate and to the same label printer but they all used different data types/sources. I was able to convert all by 1.
The one I am having trouble with is one where there is a form, with a combobox and a textbox. The combobox has a table that its connected to with 11 different symbols ranging from Hearts to & and # stuff like that. The textbox will take any number/text combo.
When I run a query that I set up with [Forms]![frmPrintPtouchLabel]![txtName] and [Forms]![frmPrintPtouchLabel]![cmbSymbol].
The query pulls the right information except for the symbol that columb is left blank. Can anyone provide any reasoning as to why this is happening and how I can fix it?
Thank you.
Looks like there was fluke somewhere in my code or I was just over thinking something. After setting up a blank query I set a field: Symbol: [Forms]![frmPrintPtouchLabel]![cmbSymbol], and a field Name: [Forms]![frmPrintPtouchLabel]![txtName]
and I set up a button in a form that does DoCmd.OpenQuery "qry_TestQuery", in that same form there is the combobox with the Symbols, and a textbox for the Name, when I input those two and click the button the query opens with the proper information. Thanks for all that helped.
I have 2 bugs beginning to show up in my app, both in subforms. New text boxes, labels and check boxes will only display in design view.
Bigger problem: I can add a check box by dragging it from the field list but get the error 'Control can't be edited; it's bound to an unknown field [FieldName]' when I attempt to click it in form view.
I can edit the value directly in the table and I can edit the value in the form's underlying query as well.
I've tried decompiling/recompiling and importing all my objects into a new database. I tried using a different machine to see if there was something wrong on mine. nada
This is an existing application with hundreds of man hours into it. I can't just start from scratch.
I was getting this - It took me a while to realize because the error statement only persisted while data list item was click-depressed. It turns out in my case that somehow a number of spaces existed in the Control Source property. I found this when I entered the table name in the field and the error statement switched from Control can't be edited; it's bound to an unknown field '(bunch of spaces) ' to Control can't be edited; it's bound to an unknown field [tableName]. After deleting the [tablename] and ensuring no spaces in Control Source, the combobox toggled to 'unbound' and there was peace in the valley.
I had a similar problem. After many hours of work I discovered that all of a sudden I had to add the table name to the Control Source property.
Go to the properties for the control and add the table name i.e. tbl_MyTable.MyField.
I have no idea why Access sees an ambiguity problem all of a sudden for just that one field but that was obviously the case.
I had this problem and tried adding the table name to no avail. On the load event of the form, I changed the recordset (same table but filtered using what is passed by me.openargs instead of on the docmd.openform command due to needing the id passed for other things to work) in VBA. I thought that once you set the form to the recordset, you were done and could close the recordset. Not so, leave the recordset open until you actually leave the form or this error will occur.
Change the control source from "=[Some_Value_in_Table]" to [Some_Value_in_Table]. To be more precise remove the equal to sign.
I tried all these things - to no avail. I had a few fields bound and only one of them was causing grief - the others were fine. I swapped the Control Source around between controls to isolate the issue - it was definitely only related to the field somehow - after refreshing external links, removing and re-adding the offending field from the Access query opening and closing the offending form - everything somehow fell into place - I can't say exactly what fixed the problem - but my life can now return to normal! In a nutshell - these are the steps I followed:
* refresh links to external table
* remove and re-add fields in query
* confirm the the field is editable at the query level
* copy and paste the table.fieldName from the query's sql statement
* save - close query
* paste into the Control Source
* save and close form!
Good luck!
I have a combo-box on a form with:
ControlSource=Target Basis ---------- [A field in the form recordsource]
RowSource=Target Basis -------------- [A separate table of the same name]
RowSourceType = Table/Query
The table "Target Basis" has 20-odd values. The above behaves as expected ... until,
VB code changes the above as follows:
Select Case xyzVar 'xyzVar is taken from another field on form.
Case xyzValue
Me.Target_Basis.RowSourceType = "Value List"
Me.Target_Basis.RowSource = vbNullString
Me.Target_Basis.RowSource = "'Trend Channel'; 'Adjusted Trnd Ch.'"
Me.Target_Basis.Locked = False
Me.Target_Basis = "Choose"
Case Else 'etc.
Upon completion of the above code, the text "Choose" appears in the combo as expected, but when the user drops the choice list, only one option appears, and it's the following text --
SELECT [Target Basis].Basis FROM [Target Basis]
I used documenter on the entire database and determined that the above query is not defined anywhere. I assumed that the system must be generating it from the controlSource name. To check this, I changed the name of the separate table (i.e. the rowSource table) from "Target Basis" to "Target Type". I got the identical behavior, except that now the single item in the list was --
SELECT [Target Type].Basis FROM [Target Type]
At that point I changed the name of the table back to "Target Basis"; however, the item that appears in the droplist remains as above -- despite that now, neither the query nor the table "Target Type" exist in the system. I tried closing, compacting and re-opening the Db; no change.
Further experimentation revealed the following:
When the code completes execution, the rowSourceType and rowSource are as they should be. I checked this by creating a button that outputs these properties. As soon as the user clicks on the combo's drop arrow however, the rowSource property changes to the SELECT statement above. The rowSourceType stays "Value List", which is why it appears in the drop list rather than executing.
If the controlSource is deleted, i.e. the control is unbound, the problem disappears.
Where is this query coming from??
Much obliged for any insight - IG
Firstly, I'm not sure why you have:
Me.Target_Basis.RowSource = vbNullString
I think it is unnecessary and may be causing the problem.
Try adding Me.Target_Basis.Requery to refresh the combobox list.
Access often leaves "ghosts in the machine". I've been working with Access for close to 20 years and I can't tell you how many times I've had to fix a problem and then import all the forms/macros/queries/etc.. into a fresh empty database. it happens. Not sure if that's your current problem, but it does happen.