What is the right way to do some calculation in MS access to be stored in the bound table through the user entry form
Should I make use of VBA or simply from access.
You can make simple calculations directly in a textbox for instance. If you set the control source to something like "=A*B", you will see the result of A * B in the textbox. However, in VBA you can write more complex functions that you can reuse (even from textboxes "=MyFunction(A,B)").
In VBA Functions you can store intermediate results in variables, perform loops and so on. You can even implement some error handling. This is not possible otherwise.
It makes your application easier to maintain, if you keep the code in a central place in modules, compared to spreading the calculations over dozens of controls in forms and reports.
The general rule is that you should not store calculations. If you must write a calculation to a bound textbox, you will have to use VBA. If you are using MS Access 2010, you can make use of calculated columns.
Related
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.
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 have a function that creates a text file and need to run it from the data macro. so then the evens can use it on the table.
How do I go about doing this?
You don't, as per our chat. Data macros even run outside of MS Access, if they used code within MS Access, this could not happen. They are tied to the database engine, which knows nothing about Access front-end.
You can run queries from a data macro AFAIK, and it is possible to create a query to write to a file*, but you cannot run VBA.
* I looked into this a little more and I find: "Queries that contain linked tables, action queries, and database references are not allowed in data macros."
You can do this, but it not recommend. Remember, table triggers and store procedure code does run independent of VBA and in fact it runs even if you don't have Access installed.
However, assuming you going to be using Access to always edit the data (a reasonable assumption), then you can in fact have the table macro call VBA code. There are several ways of doing this, but the most common and useful is to set SetLocalVar to a VBA function. This has the added bonus of being able to pass some values to that function which in most cases is likely required.
So, keep in mind you can call VBA code, but then you are adding creating a dependence from your tables to VBA.
So just use SetLocalVar to some dummy var, and place the VBA function in the expression.
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.
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.