Here are some thoughts that might help. Our approach is to have middle
tier classes that handle all data I/O. Each of these classes has
public members that represent the fields in the back end database.
They also have a uniform set of methods (an interface) to access the
typical functionality.
As a small example, lets say we have an employee table that only has 3
fields, LastName, FirstName, and EmployeeId. Lets say we write a class
named EmployeeClass, it would have 3 public members:
Public LastName As String
Public FirstName As String
Public EmployeeId As String
The class would also have Load, Add, Update, and Delete methods. If I
had some form to allow editing a record, here's how the code would look
to populate the textboxes with values from the table:
Outside any methods in the form (so as to make it public to the form)
Dim EmployeeObject as New EmployeeClass()
Inside some method such as OnLoad:
EmployeeObject.Load(EmployeeId)
Me.TextBoxLastName.Text = EmployeeObject.LastName
Me.TextBoxFirstName.Text = EmployeeObject.FirstName
Me.TextBoxEmployeeId.Text = EmployeeObject.EmployeeId
To keep an audit trail, I might do something like this (assuming we are
in some kind of Save method):
If Me.TextBoxLastName.Text <> EmployeeObject.LastName
'Write the old and/or new value to an audit table or whatever you
want
Endif
The same code would apply to the other two textboxes. Since the class
retrieved the data, it isn't directly bound to the textbox, therefore I
can compare the retrieved value to the value in the textbox. The heavy
lifting is done by the EmployeeObject, it takes a bit more work to
create, but the payoff is in flexibility.
I hope this helps, but if you some clarification, let me know and I'll
help as much as I can.
