That was an interesting read. The decenters in the comments also echoed a few things that were in the original posted article. Those posts were also ten years old.
The workaround I use is a disconnected ADO recordset - useful for being able to have an 'updateable' crosstab for example but still bound. updates etc being handled in vba. Only disadvantage with ado datasets is the inbuilt sort and filter functionality wont work, so you need to write your own shortcut menu if you want to users to have this functionality.
That's kind of what we are doing here in the form of a post instead. If someone creates a new article for real, I could link back to it at the top of the thread as well. As long as we get the end results everyone can agree on, it'll be good.
I nominate you...
This is the same logic fallacy as the first article.
My point is that the article is not really about bound vs unbound. It is about separating data entry from data editing. I am all for that, but the answer is not unbound forms. I see novice user trying to get a single form that does everything. It is a parent child form with the ability to add and delete parent and child records, navigate,, edit parent or child. For me that is 2-4 separate forms. I almost always separate navigation from adding/editing. Separate adding parent information from adding child information.
Great argument - casts a different light on the subject.
IMO Access is pretty limited in support for unbound forms. Sure you can do it, just not a lot of features to do it. If you are going to do the work to bypass Access' strength of bound forms then use VS which is excellent for unbound forms. The biggest thing is the datagridview. So you can easily do unbound continuous form like things. You can fake this in access with a ton of work and a have inferior product. VS has a native treeview which to me is huge. Doing dynamic controls in Access is a non-starter. So with a lot of work you can get very average unbound forms in Access. Or for little work you can get the power of bound forms. As I said, I use unbound forms only to display data in ways that cannot do with a standard form, but never for data entry or editing.
It would be nice to see some side by side examples of a simple application done both ways. So if for instance TheSearcher showed us one of his predominantly unbound app, then one of us can do the same app using bound RAD techniques. Then we would have a con create example to discuss and point out the differences.
While this is obviously true, it might lead to a short-sighted view. It strongly emphasizes the initial development of a solution and often disregards the ongoing maintenance of a project. I've seen many projects where the quickest (=cheapest) possible approach was choosen for the initial development of a feature but by this the effort for maintaining and extending the functionality was drastically increased. - Finding the right balance can be a tough call. Planning for maintainability and extensibility of a feature involves a lot of guessing the future.
This example does not real showcase what you are asking, but was an attempt to answer a question. The applications that I have seen with heavy use of unbound forms are very brute force. They hardwire a lot of one-off code. I wanted to see why no one has made a wrapper to use unbound forms. I think I got a pretty close solution, then lost interest and never finished. Anyway I made a class called UnboundControl. An unbound control has a property to identify which table and which field it is "bound" to. I also built a collection of UnboundControls so that these can all work together.
Private UCS As New UnboundControls
Private Sub Form_Load()
UCS.Initiliaze "tblDemoUnbound"
UCS.Add Me.UCFirst, "first_Name"
UCS.Add Me.UClast, "Last_Name"
UCS.Add Me.UCemail, "Email"
UCS.Add Me.UCPersonID, "PersonID"
UCS.Add Me.UCdatefield, "DateField"
UCS.Add Me.UClongfield, "longField"
UCS.Add Me.UCdoublefield, "doubleField"
UCS.Add Me.UCcurrencyfield, "currencyField"
End Sub
Private Sub cmdLoad_Click()
UCS.LoadFromPK (Me.PersonID)
End Sub
Private Sub cmdUpdate_Click()
Dim pk As Long
pk = Me.PersonID
UCS.UpdateFromPK (Me.PersonID)
Me.Requery
Me.Recordset.FindFirst "personID = " & pk
End Sub
Private Sub cmdEmail_Click()
If Not Trim(Me.cmboEmail & " ") = "" Then
UCS.LoadFromCriteria ("email = '" & Me.cmboEmail & "'")
End If
End Sub
