I have created a database with one form and one table. The form is basically an application and asks questions about each person/applicant. I've written skip logic/conditional formatting in different events for disabling/enabling certain questions or text; as well as used Access's built-in Conditional Formatting for enabling and disabling text fields and other controls.
For times when I want to disabled Checkboxes, Access's conditional formatting is not an option for this type of control, so I have written VBA code to disable these checkboxes based on the lead-in questions, which works great. The issue that I am having is that if I finish an applicant and some fields have become disabled as a result of my VBA, when I create a new record, those fields remain disabled, whereas, the fields that I used the Conditional Formatting tool are reset correctly.
Its my understanding that I will need to write some code to reset these controls for when there is a new record. I wasn't sure which Form event to use. Also, I want to preserve what has been enabled and disabled as I review records. So if I go back to a record where a checkbox was disabled, it remains disabled, etc.
You want to use the Form_Current event. This event fires once each time you go to a record.
As a result, it fires in the following situations:
When you open the form
When you move to an existing record
When you move to an empty record
Related
I have a detail report with interactive sorting on the headers.
After the report is refreshed, the user would like to highlight some rows of data that appear throughout the report in order to see if patterns are detectable.
Say, a vendor name that appears on multiple customer rows might indicate that they all shopped at the same vendor before their credit card was compromised. Highlighting that vendor name might make it easier to spot whether this is a problem vendor. They won't know what they want to highlight until they start perusing the data, so a run-time parameter won't work.
In the past I used BusinessObjects which had a control that could be used to trigger alerts (formatting changes).
Is there a way to hack such a thing in SSRS?
Is there a way to hack such a thing in SSRS? No.
But, if the report user wants to export the report to Excel, then they can do whatever they would like to that spreadsheet afterward. They just need to know that any changes will not be written back to a data store any where as a result of that.
SSRS is purely for reporting data, not altering it, or annotating it. Changing the report output in Report Manager is not possible, either.
If you need to be able to highlight data in a report at run time, you can do that via a combination of properties and expressions in the RDL. Your business users would need to tell you what the rules for that are, then you can make the changes in what ever dev tool you are using to create reports.
I hope this clarifies some things for you.
Add a parameter that is populated with Vendor names.
Then in your rows, right click and go to TextBox Properties. Then click the Fill tab on the left and next to Fill Color press the fx button to add code:
=IIF(Parameters!VendorName.Label = Fields!VendorName.Value, "OrangeRed", "White")
This will highlight the cell OrangeRed if the VendorName in this row matches the one selected in the parameter.
What is the difference between bound and unbound controls in MS Access?
How do they differ? And when on an MS Access Form in design view, how can we tell if a form is bound or not?
Bound elements are linked directly back to the relevant tables, and when you amend any data within form's, your changes are immediately written to the tables. This can often lead to people questioning why "when I close a form does it save the changes?" Well that's bound behaviour for you, and to prevent any updates you must use procedures such as BeforeUpdate to cancel if necessary. Bound controls are easy to identify as they will contain the field names from the table in design view.
Unbound forms are quite the opposite, they are not tied directly to database fields and involve more coding work in order to initially populate them in normal view. However these will not automatically make changes to your tables without a custom procedure you have written e.g. a Save button. This allows a little more control, but also involves more work and good understanding of VBA coding. Unbound controls are also easy to identify as they will contain the word unbound in design view.
Note: There is much more can be said but this is a basic outline.
A bound control is one that is bound to a field in a table or to a function. An unbound control has no Control Source property, similarly, a bound form has no Record Source. You can check the property sheet.
I'm experimenting with Reports in MS-Access 2003 and I have to ask what value is there, if any, to adding interactive controls to a Report? This includes Command Buttons, Checkboxes, etc that are made inactive once the Report is viewed in its proper Print Layout.
I'm opposed in general to the use of user interface controls on reports, but it actually is an advantage that you can save a form as a report. That's one reason you could end up with interactive controls on a report.
Arguably, one can also justify combo boxes and option groups, the first because it saves a join in the report's recordsource (which might cause complications or performance issues), and the second because it provides not just an indication of the stored value, but also what it means and what the other options are.
Check boxes I see no issue with at all. They are a good way of indicating Boolean values.
Command buttons I can't justify, but are likely supported simply for the compatibility issue that allows you to save a form as a report.
I have an old Access database that is being upgraded to work with Access 2007. The client is complaining that it is slow now. I am looking for ways to optimize it.
There is one subform that is in a particular tab on the form. I have been wondering -- does the subform still update/query even when it is not visible?
If this is configurable --- how?
All controls refresh/update whether visible or not.
It's generally considered good practice to not load recordsets until they are needed. If you have many subforms in a tab control, you can use the tab control's OnChange event to load/unload your subforms, or, alternatively, to set the recordsources.
However, with only a couple of subforms, this is not likely to be a big help. But with a half dozen or so, it's a different issue.
You can remove the recordsource from the subform and add it back when the form is made visible, or simply remove the whole subform and add that back.
Good day...
The root of my issue is that there's no context menu allowing the user to delete a row from a form. The "delete" button on the ribbon is also disabled. In Access 2003, apparently this function was available, but since our recent "upgrade" to 2007 (file is still in MDB format) it's no longer there.
Please keep in mind I'm not an Access dev, nor did I create this app - I inherited support for it. ;) Now for the details, and what I've tried.
The form in question is a subform on a larger form. I've tried turning "AllowDeletes" on on both forms. I've checked the toolbar and ribbon properties on the forms to see if they loaded some custom stuff, but no. I've tried changing the "record locks" to "on edit", no joy. I examined the query to see if it was "too complicated" to permit a delete - as far as I can tell, it's a very simple two (linked) table join. Compared to another form in this app that does permit row deletes, it has a much more complicated (multi-join, built on queries) query.
Is there a resource that would describe the required conditions for allowing deletes?
Thanks in advance...
Open the query that is the basis for the subform. Can you edit a record? If not, the query is probably the problem.
Are you quite sure the change in functionality happened with the 2007 upgrade? Because the next likely cause is a setting, one of many accesses via the form design interface OR in VBA code.