the Manx Man's MS Access Pages
need professional help with a database?
Unbound Forms - Part 1 (030) I have seen a number of postings in the newsgroups lately, with questions about unbound forms. How do they work? Why use them? I am not going to open a can of worms and answer the Why!!! I am going to write a series of articles about the how. At least, the way I see it. I have developed my own particular style of unbound forms. I like them because them give me TOTAL control over a process and make it impossible for the user to "accidentally" mess up data. In order to replace data or add new data the user MUST PURPOSELY click a button called SAVE. I realize that bound forms can be protected with various events. Just remember that I am not going to go into the details of why! Here is an example of my way of creating unbound forms.
All the code segments assume that you have DAO references active. If you are not sure what this means, and you are using Access 2000 or higher, click here. Code for lstData (AfterUpdate event)
Code for cmdSave (OnClick event)
How it Works When you click on an entry in the listbox, the afterupdate event fires and the data from the listbox gets copied into the textboxes.Notice the use of the column(n) property of the listbox. If you change the data in one of the textboxes, you need to click the Save button. When you do, the OnClick event fires and I use recordset methods to find and update the record in the table. What's next? Part 2 of this article will add an Add New button. This adds a bit of a challenge. How does the Save button know whether it is an updated record (needing rst.Edit) or a new record (needing rst.AddNew)? If you would like the sample database that I created to test this series of articles (zipped Access 2000 version only) please click here and scroll to the bottom of the page you are taken to on my new site. NOTE: At this point there is no error protection. I leave it to the reader to add some.
|
tip # 030 || previous tip || next tip