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.
Related
We have a ACCDB including a lot of forms with expression fields (e.g. "=[FieldA] + [FieldB]"). The ms access db is executed with the access runtime (2019) on a Win10 terminal server. All Forms have been migrated from access 2002 to access 2019 (per OASIS SVN Export/Import).
Mostly the content of expression fields would be displayed as expected, but in individual cases all/some expression fields in the form are empty (also after waiting some time). The content of the other fields is displayed. This beviour is data independend and the field expressions are correct. Mostly ist works, but somtimes not (for the same expression field, data record and form). But if a expression field gets the focus, the content is displayed.
Perhaps it depends on the workload of the pc the access db is running. But i'm not an ms access expert. Another problem is, that an mistakenly empty field could be misinterpred by the user.
One solution is to use the onCurrent event of the form to set the field content explicitly (doesn't work for endless forms) or outsource the calculation in the db view.
I am searching for a general solution, without having to modify all forms (> 150). I can't image this is a general problem with ms access.
Many thanks for any help
Cause of the problem were some java processes started in vba per WScript.Shell and WaitOnReturn option. The problem occurs only if one of the processe was running. As a solution we now avoid the WaitOnReturn option if possible.
I have a customized report sitemap for SSRS (which is a report itself) and currently put custom options in the report description. I then use those options in the sitemap to filter reports accordingly.
I was wondering if I could add columns to the ReportServer.dbo.Catalog table?
Or is there a way to add custom properties to the report settings (as in picture)?
Altering the Catalog table in the SSRS database would more than likely break SSRS. At a minimum, it would stop you from being able to upgrade to another version in the future without a whole lot of pain.
If you really need to add custom properties to the report catalog, host your reports in SharePoint. That way, you can add additional fields to the report list it creates all day long, and you won't break a thing.
I have done this, it's nice. I have added a new field to hold the technical description of the report, leaving the canned description field for the business description. With SharePoint, you can all sorts of additional fields, for all types of data. If you know anything about the SharePoint database, you can query that too to pull the addition data into whatever you need.
This may not be the answer you want since the move to SharePoint may not be an option for you, but it is a viable option none the less.
Assuming a fairly conventional SSRS 2012 report (in Visual Studio 2012) with a main report, a set of sub-reports, a shared dataset that is populated at the start of the report, and a shared datasource.
Is there any simple way within a sub-report's custom code (this is VBA, right?) to access the shared dataset, either to read or update records locally? (No updates back to the database itself.) I'm seeing hints out there that this is possible but no clear examples yet.
And if the above is possible, assuming that a call in the sub-report changed a record in the shared dataset, could that record change be displayed in the main report body?
Yes and No.
I think the overall concept would work but a few points won't.
I don't think you'd be able to use the report dataset with VBA. The code won't have access to the report's datasource directly. You'd probably need to use ADO to access the db from VB.
The only way to see the updated data would be to refresh the report - either manually or automatically on the timer.
I don't see how the subreport is going to figure out what to update the value to. You might have some idea that I'm not seeing right now.
The easier way I see this working would be to use parameters that default to NULL. Then select the row to update with one parameter and the value with another. Then have an UPDATE in your main query that only runs if your parameters are populated.
I am making an Access app that will be using Jet exclusively(No SQL Server), and split into front end back end architecture. I have weighed the pros and cons of bound/unbound, and still would like to pursue unbound in this situation.
I have a handful of classes and modules I will be importing into this project which rely on ADO record sets. However, I have read several indications which suggest using DAO to populate Access forms http://support.microsoft.com/kb/281998 {Requirements for Microsoft Jet} . I know that these are totally different libraries, and cannot share info from one another. However, I was thinking that my classes and other ADO dependent objects could use a mix of local tables/queries and form control values which would avoid a potential collision.
So my question: If I only us DAO to fill forms in this project, am I still asking for trouble? If so, what kind of problems should I be aware of? Or is it reasonable to expect that this separation could co-exist if I am careful, and the distinction is explained in the apps documentation?
Mixing DAO and ADO in the same application doesn't really present any problems or complications. I think your question really has a lot more to do with when and why would you use one or the other.
My own standard policy in Access development has been to use ADO only when DAO won't work for something I want to do. For example, with ADO you can access data stores other than Access such as Visual Foxpro, Oracle, MySQL, etc. But ADO isn't always required to achieve this either since you can often use ODBC instead, which means you would then be using DAO together with ODBC linked tables.
Recently I have somewhat switched gears to where I prefer to use ADO exclusively, but I recognize that this is not the common practice among many experienced Access developers. I'm using SQL Server 2008/2012 Express and forms bound to ADO recordsets, and I'm avoiding using any ODBC linked tables at all. My basic reason is that ADO gives me a few more options and more control, although it does come with it's costs. I use a lot of disconnected recordsets and then I "manually" (VBA) write the changes back to the database only if the user clicks the save button. This gives the user the option to make a bunch of changes to a form and it's subforms, but still cancel out if he chooses. With disconnected ADO recordsets it's up to you to determine how to get data changes to the server, although non-disconnected recordsets automatically submit their changes. As near as I can tell, the only ADO recordset type that automatically receives all additions, changes, and deletions from the server (adOpenDynamic) cannot be bound to a form, but that's really not a huge concern if you just want to be able to use ADO bound forms for adding/editing/deleting records.
I've read numerous places that ADO doesn't have any performance advantages over DAO, and in some cases may actually be slower. I cannot say one way or the other, but I don't think this is a big concern. ADO has the advantage that you can actually make your application work across slow and/or unstable network connections (such as WAN/Internet), which is really not feasible with DAO/ODBC. With a pure ADO solution, you are in charge of handling the connection object and all fetches of data. You can set the connection and command timeouts and if the timeouts occur, the connection fails, etc., it's up to you to decide how to handle it. You could, for example, make X number of reconnection attempts. None of this is really possible in DAO/ODBC. As far as I know, the connection object isn't even exposed with ODBC, other than the fact that you can setup the ODBC connection string.
It does take a lot more code to do everything in ADO, particularly if you want to use disconnected recordsets. Recordsets have to be fetched (or fabricated) using code. If you use disconnected recordsets, data has to be written back to the server using code. Whether you use disconnected or connected recordsets, Master/Child relationships on forms have to be manually managed using code (you can't use the Master/Child Link properties).
One potential downside with ADO is that it isn't possible to bind a report to an ADO recordset unless you are using an Access Data Project, which isn't really recommended at this point, seeing that MS is dropping support for ADP's. If you want to use something other than DAO for data on a report, you would have to use Pass Through Queries, and if your data store is MS Access it would make no sense to do that.
I think any discussion about bound and unbound forms is completely unrelated to any discussion about DAO and ADO. Forms can be bound to ADO Recordsets with very few trade-offs. An unbound form could get it's data from a DAO Recordset or ADO Recordset and there would be no difference so unbound forms and ADO are no more related or unrelated to each other than DAO and unbound forms. I really only use unbound forms for creating my own Message Boxes and certain kinds of input boxes or record selection boxes. Usually it's a case where I want data displayed on buttons for a touch screen application and then I go unbound. If I could get similar behavior from Textboxes (and I probably could if I tried hard enough), there would be few cases where an unbound form would be necessary.
It seems to me there has been an idea propagated that unbound forms are the way real professionals develop Access applications. Or that unbound forms are the only way that you get performance. Or that unbound forms should be used if you're not using MS Access as your data store. But none of these ideas really hold up to any scrutiny. Binding forms to ADO recordsets is much easier than going completely unbound. And it's not even possible to use Datasheet Views or Continuous Forms in an unbound manner. If you really want to go unbound in a grid-style view you'd have to use an ActiveX grid control such as iGrid from 10tec, or the MS List View control which usually have more overhead since there is the time needed to fetch the Records and the additional time needed to fill out the grid controls with the data. An unbound form has no performance gains that I can think of over binding the form to an ADO recordset. And there's really no kind of data store that can't use an ADO Recordset, even if you have to use a fabricated ADO recordset.
This is a tremendous oversimplification but your primary performance gains in MS Access come from maximizing the performance of your data store (which usually means moving to SQL Server) and carefully managing how much data you load and present to the user. The easiest way to do the latter is with ADO, but you can also do it with DAO/ODBC as well. ODBC actually has one advantage over ADO, called lazy loading. You can bind a datasheet form or continuous subform to a very large table/DAO recordset and the loading of each record will occur as you scroll. Its a feature I'm not very fond of and I've had users complain about it since you don't get to see the records until you release the scroll bar, but I'd have to argue that it is one of the most efficient ways of handling large amounts of data (> 50,000 records).
There's a fairly extensive article on the UtterAccess Wiki that details the pros and cons of DAO versus ADO (Note that the article got deleted and the only way to view it is the look at the history of what was at one time. Just make sure you scroll down below the diff/comparison). And there's another great article on unbound forms at AccessExperts.com written by Juan Soto.
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.