I have a form with controls that were bound to an ADO data control.  I
removed the ADO data control and the controls are now bound to a recordset.
The recordset is using the Jet 4.0 OLEDB driver, with an adOpenStatic
recordset.  When leaving the form I check to see if any data changes
occurred using the following approach:

dim fld as adodb.field
dim blDataChanged as Boolean
for each fld in adoDC1.Recordset.Fields
    if fld.Value<>fld.OriginalValue then
        blDataChanged = True
    endif
next

Although all controls contain changed values, when each fld value is
compared to its original value, none of the fields' fld.value contain the
changed data which I can see exists by looking at the bound control.  Why
would a bound control show one value and the field it is bound to not show
the same value (fld.value)?  After performing a recordset.update, the proper
values are updated to the database, so the recordset is being updated
properly, but the fld.value is not showing the current value in the
controls.  This prohibits the code from catching fields which changed and
taking the appropriate action.  Any help is appreciated.

Thanks,
Tom

Tom,

I wonder how you UPDATE the changes.

In immediate update mode (in which the provider writes changes to the
underlying data source after you call the Update method), the OriginalValue
property returns the field value that existed prior to any changes (that
is, since the last Update method call). This is the same value that the
CancelUpdate method uses to replace the Value property.

In batch update mode (in which the provider caches multiple changes and
writes them to the underlying data source only when you call the
UpdateBatch method), the OriginalValue property returns the field value
that existed prior to any changes (that is, since the last UpdateBatch
method call). This is the same value that the CancelBatch method uses to
replace the Value property. When you use this property with the
UnderlyingValue property, you can resolve conflicts that arise from batch
updates.

Peter

I am using immediate update mode.  The Original Value and Value properties
are always the same (and are always equal to the "original" value of the
record), even though the text control(s) on the form shows a the new
(changed) value.

Tom,

If you use the Immediate mode, the bound control will automatically fire the UPDATE statement through the underlying
DataSource.  According to MSDN, the OriginalValue property returns the field value that existed prior to any changes (that is,
since the last Update method call), so both OriginalValue and Value are the same as the current one in the bound control.

If you want to control the update of the data by checking if the Original Value has been modified, I suggest you use the following
demo code.

Option Explicit

Dim cnn As ADODB.Connection
Dim rst As ADODB.Recordset

Private Sub Form_Load()
    Set cnn = New ADODB.Connection
    Set rst = New ADODB.Recordset

    With cnn
        .ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=D:\NW2K.mdb;Persist Security Info=False"
        .Open
    End With

    With rst
        .ActiveConnection = cnn
        .Source = "SELECT ProductID, ProductName FROM Products ORDER BY ProductID"
        .CursorLocation = adUseClient
        .LockType = adLockBatchOptimistic
        .CursorType = adOpenStatic
        .Open
    End With

    Set DataGrid1.DataSource = rst
    rst.MoveFirst
End Sub

Private Sub Form_Unload(Cancel As Integer)
    Dim fld As ADODB.Field
    Dim blDataChanged As Boolean

    blDataChanged = False
    rst.MoveFirst

    While Not rst.EOF
        For Each fld In rst.Fields
            If fld.Value <> fld.OriginalValue Then
                blDataChanged = True
            End If
        Next

        rst.MoveNext
    Wend

    MsgBox "The data has been changed yet? " & blDataChanged

    rst.UpdateBatch
    blDataChanged = False

    While Not rst.EOF
        For Each fld In rst.Fields
            If fld.Value <> fld.OriginalValue Then
                blDataChanged = True
            End If
        Next

        rst.MoveNext
    Wend

    MsgBox "The data has been changed yet? " & blDataChanged

    rst.Close
    cnn.Close

    Set rst = Nothing
    Set cnn = Nothing
End Sub

After you call UpdateBatch, the changes are written to the database and the blDataChanged is equal to False.

HTH,

Peter
--------------------


| Subject: Re: Field.value doesn't show value in control
| Date: Fri, 15 Jun 2001 10:09:15 -0400
| Lines: 31
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 5.00.2314.1300
| X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

| Newsgroups: microsoft.public.vb.database.ado
| NNTP-Posting-Host: cc1012108-a.hwrd1.md.home.com 24.3.22.240
| Path: cppssbbsa01.microsoft.com!tkmsftngp01!tkmsftngp03
| Xref: cppssbbsa01.microsoft.com microsoft.public.vb.database.ado:49334
| X-Tomcat-NG: microsoft.public.vb.database.ado
|
| I am using immediate update mode.  The Original Value and Value properties
| are always the same (and are always equal to the "original" value of the
| record), even though the text control(s) on the form shows a the new
| (changed) value.
|

| > Tom,
| >
| > I wonder how you UPDATE the changes.
| >
| > In immediate update mode (in which the provider writes changes to the
| > underlying data source after you call the Update method), the
| OriginalValue
| > property returns the field value that existed prior to any changes (that
| > is, since the last Update method call). This is the same value that the
| > CancelUpdate method uses to replace the Value property.
| >
| > In batch update mode (in which the provider caches multiple changes and
| > writes them to the underlying data source only when you call the
| > UpdateBatch method), the OriginalValue property returns the field value
| > that existed prior to any changes (that is, since the last UpdateBatch
| > method call). This is the same value that the CancelBatch method uses to
| > replace the Value property. When you use this property with the
| > UnderlyingValue property, you can resolve conflicts that arise from batch
| > updates.
| >
| > Peter
| >
|
|
|