Me.dirty raises an error

majhl

Registered User.
Local time
Today, 11:05
Joined
Mar 4, 2008
Messages
89
Using Access 2003 ADP with unbound forms, linked to SQL server database.

I've got the code below in the click event of a button and it raises the error 'runtime error 2455 "you entered an expression that has an invalid reference to the property Dirty'.

I've used the Dirty property in this way before in databases with no problems. The only thing that's different here is that these other dbs weren't ADPs, just straightforward mdbs. So is the problem linked in some way to the database being an ADP file? Is there a way around this?

TIA for any help.

Code:
If Me.Dirty = True Then

    If MsgBox("Close and lose changes?", vbYesNo, "Lose changes") = vbYes Then
    
        Me.Undo
        DoCmd.OpenForm "frmsearch"
        DoCmd.Close acForm, "frmCustomerU"
        
    End If

Else

    DoCmd.OpenForm "frmsearch"
    DoCmd.Close acForm, "frmCustomerU"
    
End If
 
I don't think it works on unbound forms - there's no record source to be dirty.

Do the data objects/connections within the form have a dirty property?
 
I don't think it works on unbound forms - there's no record source to be dirty.

Doh!! Of course, the form's disconnected form it's data source.....

I'll need to check if there's and ADO equivalent of the 'Dirty' property.

Thanks for the reply.
 
Doh!!

I'll need to check if there's and ADO equivalent of the 'Dirty' property.

The form is unbound. That means that the controls on the form are NOT connected to the ADO recordset. The ADO recordset will not know if you changed the contents of a control on a form since the are disconnected.

One possible method is to loop through all the controls on the form that can be edited and compare each on to the field in the ADO recordset used to load the form. If there are any fields that do not match, then you can set you manual flag for "dirty" to true.

Why are you not using a bound form?
 
The form is unbound. That means that the controls on the form are NOT connected to the ADO recordset. The ADO recordset will not know if you changed the contents of a control on a form since the are disconnected.

One possible method is to loop through all the controls on the form that can be edited and compare each on to the field in the ADO recordset used to load the form. If there are any fields that do not match, then you can set you manual flag for "dirty" to true.

Why are you not using a bound form?

Thanks for the tips. Sounds a bit of a pain doing it that way, but needs must I guess...

I'm using unbound forms partly as a learning experience and partly because I might implement this approach in certain projects at work in the future.
 
There are other ways of determining editing having occured of course. You can "watch" the data controls on your form for updates. Should any occur then set your own form module level "dirty" variable. (You could implement more than a boolean result, with values for Dirty, Unedited, Undone etc :-)

FWIW ADP forms operate in a disconnected state - not dissimilar to the efforts of an unbound form. (Don't get me wrong - unbound forms are great and certainly have their place when used as a tool for the correct reason).
If your resons are for control then there is control to be gained with them it's true.
If efficiency - well then that's only partially available.

When you say that you'll "need to check if there's and ADO equivalent of the 'Dirty' property" - that doesn't really apply as you're not working with bound data, so neither the ADP nor ADO is going to help you with any state.
You're filling the form in your own code - and so it's your own code which must monitor its state.

Cheers.
 
When you say that you'll "need to check if there's and ADO equivalent of the 'Dirty' property" - that doesn't really apply as you're not working with bound data, so neither the ADP nor ADO is going to help you with any state.
You're filling the form in your own code - and so it's your own code which must monitor its state.

Yes, I realized that after I'd posted it.

FWIW ADP forms operate in a disconnected state - not dissimilar to the efforts of an unbound form.

I'm intrigued by this. Do you know where I could find further details?
 
>> Do you know where I could find further details?

It's not officially documented AFAIK. Just have it on good authority.
There any many things about form internals (in MDBs even more so) that we'd love to have intimate details of.
 

Users who are viewing this thread

Back
Top Bottom