Stupid Q: What is on Dirty?

[Veli Izzet]

Hi all,

Can anybody explain this?

TIA

 

[Dirk Goldgar]

Hi all,

Can anybody explain this?

Somebody probably can. I'll have a go.

"Dirty" is a term commonly used in programming to represent a state in
which data has been modified but not saved. Forms have a Dirty
property, which is True if the form's current record has been modified
but not yet saved, and False otherwise; and they also have a Dirty
*event* which is raised whenever the form becomes Dirty through user
action -- that is, when the current record is first modified by the
user.

Forms also have an "OnDirty" property, which you'll see on the Event tab
of the form's property sheet. This property tells the form what to do
when the Dirty event is raised -- call an event procedure, run a macro,
call a function, or do nothing.

 

[Veli Izzet]

Thanks Dirk,

I sometimes have a problem; when I am updating data in a form, and when
I want to print a report with that data, I see that the printed report
carries old data. I have to leave the form and then comeback again to
have the new updated data.

It seems that the data and the form are dirty, but the data is not saved
yet.

The questions are; when is the data saved to the database? Can it be
forced to be saved before? etc. etc.

I am asking about best procedures

 

[Dirk Goldgar]

Thanks Dirk,

I sometimes have a problem; when I am updating data in a form, and
when I want to print a report with that data, I see that the printed
report carries old data. I have to leave the form and then comeback
again to have the new updated data.

This is a common problem.

It seems that the data and the form are dirty, but the data is not
saved yet.

Right -- although, technically speaking, that's a redundant statement.
If the form is "dirty", then by definition that data is not saved yet.

The questions are; when is the data saved to the database? Can it be
forced to be saved before? etc. etc.

I am asking about best procedures

There are a number of things that will cause the data to be saved.
User-interface actions that will do it include closing the form, moving
to another record, choosing the menu item Records->Save Record, or
pressing Shift+Enter. Programmatically, you can do this by executing
any of the following statements:

RunCommand acCmdSaveRecord
(but the form must have the focus)

Me.Refresh
(but that does a lot more than just save the current
record, so it's not very efficient)

Me.Requery
(but that does a *lot* more than just save the current
record, so it's both inefficient and cumbersome)

Me.Dirty = False
(my personal favorite)

That last one, setting the Dirty property to False, takes advantage of a
fact I failed to mention before about the form's Dirty property -- it's
a writable property. Setting the Dirty property to False causes the
form to "make it so" by saving the record.

It's slightly more efficient to only force the record to be saved if in
fact it's dirty, so I usually test that first unless I already know that
the form is dirty. My code, therefore, is usually like this:

If Me.Dirty Then Me.Dirty = False

The only drawback is that, if the record can't be saved for some
reason -- it fails validation, maybe, or has a duplicate-key error --
the error that is raised when you execute Me.Dirty = False is sometimes
misleading: it says something about being "unable to set the property",
not "can't save the record". So it's best to have error-handling code
in place that takes this into account.

 

[Albert D.Kallal]

Yes, as you edit the single record in the form, as you edit it, is of course
not yet written to disk.

When you move to another record, close the form, then the record is saved.

So, you can force a save,and for printing of the current record to a report,
you need to save first....then print.

So,

if me.dirty = true then
me.dirty = false
end if
docmd.OpenReport "myport",,,"id = " & me!id

The above is generally the code you need to print the current record you are
viewing...

 

[Veli Izzet]

Thanks,

So setting Me.Dirty to false does not only change the dirty situation,
but also forces save..

Question about this save operation: Is it directly written to the disk,
or does it stay in the buffer, etc. until whatever..

This question is of course a little off topic and is more about data
corruption, etc.

 

[Veli Izzet]

Dirk,

Another thing: sometimes I need to add some items to a combobox on the
form before leaving the form (the comboboxes are limited to list). In
that case, when I comeback the comboboxes still have the old list.

How can this be remedied?
Do I use Me.requery? Can it be done without user
intervention,automatically?(Maybe after update property of the combobox)

Again thanks for your help

 

[John Vinson]

How can this be remedied?
Do I use Me.requery? Can it be done without user
intervention,automatically?(Maybe after update property of the combobox)

Requery *the combo box itself* in some appropriate event (the
AfterUpdate event of the form or control which updates its rowsource,
for example):

Me!cboComboBoxName.Requery

John W. Vinson[MVP]

 

[Dirk Goldgar]

So setting Me.Dirty to false does not only change the dirty situation,
but also forces save..
Right.

Question about this save operation: Is it directly written to the
disk, or does it stay in the buffer, etc. until whatever..

The database engine does use a cache to hold the data, so changes that
you make don't necessarily get written to disk right away. Normally
this isn't a problem, because all the operations you do on the current
database are using the same connection and hence the same cache.
Howver, if you open a separate connection to the database, there can be
timing problems between the connections as changes you make via one
connection aren't immediately seen by the other. There is a command you
can issue to the database engine -- DBEngine.Idle dbRefreshCache -- to
make it pause until cache operations are complete, but it is seldom
needed.

 

[Dirk Goldgar]

Dirk,

Another thing: sometimes I need to add some items to a combobox on the
form before leaving the form (the comboboxes are limited to list). In
that case, when I comeback the comboboxes still have the old list.

How can this be remedied?
Do I use Me.requery? Can it be done without user
intervention,automatically?(Maybe after update property of the
combobox)

John Vinson has answered as I would have.

 

[Veli Izzet]

Well,

Yesterday while working, all of a sudden the database became corrupt,
and although I was in the application, it started to say it cannot find
the database. Had to kill the ms access from the taskmanager, and next
time I opened the application it said something to the effect that "It
either was not a database or it would try to repair the database".

This is both weird and frightful as you can loose data..

The question that comes to mind is how reliable Access is as a database,
in general..

 

[Dirk Goldgar]

Well,

Yesterday while working, all of a sudden the database became corrupt,
and although I was in the application, it started to say it cannot
find the database. Had to kill the ms access from the taskmanager,
and next time I opened the application it said something to the
effect that "It either was not a database or it would try to repair
the database".

This is both weird and frightful as you can loose data..

The question that comes to mind is how reliable Access is as a
database, in general..

I've never experienced anything of the sort. Were you working over a
network? When Access is operating over a network, it's very vulnerable
to network errors. This is particularly bad when the front-end database
(or only database, if the application isn't split into front-end and
back-end) is on a network share, because then a lot of design info is
sent back and forth across the network. So a networked database should
be split, and you want the network to be rock-solid. Wireless
connections don't cut it, and flaky NIC cards are right out.

Aside from that, which is really a question of network reliability, I'm
not aware of any reliability issues with Access/Jet databases. Was a
network involved in your case?

 

[Veli Izzet]

Actually no, It was on my notebook.

I might have opened more than one instance however.

 

[Dirk Goldgar]

Actually no, It was on my notebook.

I might have opened more than one instance however.

I don't know what would have caused that. I suspect a hardware failure
of some kind, though there are certainly ways of corrupting an Access
database -- for example, never try to open one with Microsoft Word! I
would say that, since Jet (being a file-server database engine) cannot
recover from errors as easily as SQL Server, one should always have a
backup scheme that covers the business needs. If you're dealing with
mission-critical data for which a restore from last night's backup
represents a serious loss, then you shouldn't be using Jet as the
back-end database (though you could still be using Access).

Anyway, if you want to explore the question of reliability in more
detail and get some other opinions, I suggest you post a question
specifically on that subject.