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.
Related
I have written two reports in Report Builder. both reports use data from a property table so have unique identifiers eg Property ID.
I am trying to create a drill down from report A so that when you click on a row, it will open up a sub report that will show data from the sub report (Report B) that is specific to the property.
Both reports have the unique identifier EG. Property ID.
I can see how to add a sub report by going to Text box properties, selecting "Action" the selecting "Go to report" but that then opens up the complete report showing numerous properties rather than just the property that I click on.
My question is therfore how do I add a drill down to a second report that only shows the data if the Property ID's match?
I can't seem to find any guides online for this.
Thanks
You need to add a parameter in the properties of the Action.
The name should be the name of the parameter in the report you are linking to. The Value would be that Property ID you have. This way the sub-report will have the parameter value populated as soon as it loads. You can even choose to make it hidden at that point.
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.
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 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.
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.