I'm having to do some maintenance on a Access 2007 application. I've never really used it before so I'm struggling to figure out where things are hidden. This application is broken up into two ACCDB's - one for the application, one with the data. Inside of the application I am attempting to track down where various queries are defined but not having much luck.
I've looked in the data ACCDB and selected the "Queries" category off the sidebar. The queries are not there. Inside of the Visual Basic editor of the application ACCDB, they also don't appear in the "Microsoft Office Access Class Objects".
If I click on "Create", then Query Design it seems to open a designer where I can select these queries. However, I still can't seem to figure out how to actually edit existing ones (which is what I really want to do).
Where on earth can I edit them?
On the sidebar on the left you can select different categories like Tables, Queries etc.; however, queries can also be stored in the RecordSource of Forms, Reports and the RowSource of controls. For instance ListBox and ComboBox have a RowSource property. Queries can be stored as SQL strings in VBA code or Macros or they can even be created dynamically with VBA.
Related
I have an Access DB, and I have about 26 queries that have to be run in order to produce compliance reports. What I am wondering, is it possible to format the Form that's being used by the end user, in such a way as to push through the queries I want them to select. I know it can be done if I use dynamic queries, but there were problems with the dynamic queries that my limited skills were unable to overcome, so I built new, better queries, that do the job they are supposed to with no errors. The problem is I don't want to have to build a new report for each query, but rather have the form feed the query directly to the same report template, but with each query being selected by a different button.
I was certain I could do it via embedded macros, but can't seem to find a way to do that.
I made a database with access, and I created dataentryform and inside it there are some subforms (I have related tables), I used query to provive these subform and without these qaueries I cannot enter data into subforms (if I delete these queries then when I open main form I see blank rectangular inside myform instead of them.
enter image description hereIs there any possible way to lock query and also subform in navigation pane?
In general, as long as the user is running an application on his own PC, you cannot prevent him from deliberately modifying/breaking it. This is true for all applications, not only MS-Access-based ones.
That said, there are some ways to make it harder to accidentally modify it:
The recommended way is to start Access in "runtime mode", either by specifying the /runtime flag on the command line or by renaming your accdb/accde to accdr. That way, the user won't have a navigation pane and can only interact with the application through the ways that you, as the developer, explicitly provide.
You can use user-level security to "lock" your queries. However, user-level security was deprecated with Access 2007. It can only be used with the old, legacy mdb format (rather than the new accdb format) and should not be used for new projects.
I recently created a database application in MS Access 2010 using navigation subforms. The users of this database are used to printing out forms with data from individual records. The navigation subforms cannot be printed in MS Access 2010. I read that I should use reports for printing individual records, and I am in the midst of creating reports for each of the forms. The task of creating all the reports is so laborious that I am concerned about the ability to maintain the database over time. Whenever we change a form, we will also have to change the corresponding report, because both look identical.
Can someone suggest a better way of letting users print out the contents of forms for individual records in an application in which the forms are nested in navigation subforms?
It occurs to me that vba could create an instance of a stand-alone form and print it when a control is clicked in the nested form. Ideally, this might happen behind the scenes, without the form ever becoming visible. This would cut the work of making changes to forms in half. But how would it look in code? Are there reasons not to do this? Do you have any better ideas?
In Access 2003 I was easily able to get to all the tables and edit/view data directly. However, in 2007, I'm unable to find this functionality. I have an MDB with a form, and I can only view the main table of user input data in the Datasheet View.
I'm trying to copy a list of options (there's a lot of them) set to a Combo Box into another program, and it would be easier if I could just get to the Control Source table.
You should be able to see the access objects (tables, queries, macros, forms) in the Navigation Pane on the left side of the screen. It may be hidden in that .mdb, though. If you create a new .mdb and a couple of tables, can you see them?
The UI's a little different and it takes some getting used to.
I would like to create an Access report in which the record source is created via ADO code and then set as the record source for the report when the report is run. The problem I am running into is how to add fields to the report since the recordset is bound to the report at run-time and not design time. Is there way I can manually add the field and make sure the field name matches what will be provided in the recordset field collection? Thank you.
The standard solution to this problem is to add all your fields in design view, up to the max available, and hide all of them, and show only the ones you need. Michael Kaplan explained that when he designed the Access Replication Conflict Resolver, this is the approach he used, precisely because adding controls at runtime quickly uses the lifetime limit on the number of controls on a form (700+, but I can't recall the exact number).
It's also just a bad idea, as #Jeff O says, to do design changes at runtime. For one, it means you can never distribute an MDE.
Several ways to do it, but all of them have their issues. create-dynamic report using vba
Other questions have found the folley in working in design mode programatically.