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.
Related
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'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.
In Access 2003 I used to import special xls files provided to us by a third party. I used ADODB for this, which worked perfectly.
ADODB is no longer an option in Access 2007/2010, and I don't think you can "query" a spreadsheet using DAO or ADO.
So, are there any alternatives?
I don't think you can "query" a spreadsheet using DAO or ADO.
You can indeed query an Excel workbook using ADO with the OLE DB provider for Access (Jet, whatever). See this MSDN article for more details.
ADODB is no longer an option in Access 2007/2010,
That is not the case. I think you must have misunderstood something, which is hardly surprising considering there is a lot of nonsense out there on the interwebs surrounding "ADO vs DAO" in Access.
I'm not exactly sure what happened when ADO classic was introduced to the Access2000 community but it seems that a lot of old-timers were left with hurt egos/pride. The marketing message from Microsoft was in effect, "DAO is now the old way of working and ADO is the new." In a deliberate move by MS,, new engine features were generally only available via ADO.
As is often the case when entrench positions are threatened, there was a counter-movement by long time Access+DAO fans. This often took the form of, "throw enough mud and some will stick." People newly arrived in AccessLand would be confused by the mixed messages. In the newsgroups, aspiring Access MVPs emulated existing Access MVPs' anti-ADO stance.
Between the 200 and 2007 releases, the Access product became IMO somewhat stale as regards the engine, responsibility for which had been handed to the SQL Server team, who had for all practical purposes given up on it: their attempts to make it comply with entry-level Standard SQL-92 were thwarted by the Windows team, whose components relied on features that flew in the face of the Standard. The ADO classic team had similarly been disbanded. Visual Basic COM, which effectively shared VBA libraries with the Office suite, was killed off in favour of VB.NET and ADO.NET was born,
The Access2007 team shook things up again. They reclaimed the engine from the SQL Server and Windows teams by taking a private branch. They ditched user level security, presumably because it was too complex for them to maintain. They added multi-valued types that arguably violate 1NF. Brave stuff! While some features could be accommodated in ADO classic by authoring a new OLE DB provider for Access, others could not. For example, full support (e.g. updating via SQL) for multi-valued data types in ADO would require a change to the ADO classic libraries which the Access team does not own.
Because DAO was owned by Access, the new version (called ACEDAO) got features the new OLE DB provider with the old ADO classic libraries would lack (although ADO was required to use the engine on 64 bit machines). However, what they did not do was to retrospectively fix DAO to accommodate the Access2000-era functionality that went into ADO only.
Naturally, the Access team promoted ACEDAO as first class citizen. Of course, the long-time Access+DAO fans were delighted: "ADO has been deprecated in favour of ADO.NET," they crowed. In truth, the net result is a mixed bag. See this thread for full details.
In your VBA project in Access click on Tools / References then find "Microsoft Excel 14.0 Object Library". This will give you access to all of the VBA Excel objects so you can do whatever you want to the spreadsheet.
As others have said running queries on the sheet is not an option. If you're used to thinking in terms of databases think about running a check on the template to make sure the headings match so you more than likely have a good file you're reading from. Then once you've verified the document setup SQL inserts on the lines with records on them into a table in an Access Database then run your queries from there. Check here for writing your SQL code:
SQL Statement Help
If you want to get more advanced in your VBA if your files are small you could run searches by setting up an object with setters/getters and store the records into a collection class then iterate across it with the data you're looking for.
I do this in some projects where I know the lists are small, gets away from reading/writing to tables when I really just want to read the data and run some real basic calculations like count the number of a particular widget and place the count on a report. Collection classes are great for this. Here's a good link for some more info on collections:
Collections in Visual Basic
Good luck!
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.
Rather than generate my RS reports by directly accessing a SQL database, I'd like to take advantage of Domain Objects I've already written in another application, where complex business rules and calculations already exist so that I don't have to duplicate that logic in stored procedures and other code. I want to keep it DRY.
It would be nice to treat the reporting concern as just another type of view
Is that possible with Reporting Services? It seems logical that it should be, but I'm not finding much information out there.
Yes. You can use the ReportViewer control in Local Processing mode. In this mode, you can just pass a DataSource instead of directly accessing the Database.
Keep in mind that there are certain things that you cannot do in LocalMode that you can in ServerMode. One that I recall, is exporting to anything other than PDF or Excel.