Where does Access do it's WRITES?

  • Thread starter Thread starter harrzack
  • Start date Start date
H

harrzack

I'm new to Accesss (20 years in another 4GL db app), and am wondering where
the actual save/commit is done in a simple Access db. I'm used to an
environment where the user initiates and edit/new cycle, then does either a
Save or Cancel. The "hot commit" that Access appears to use is a bit
disconcerting!

I'm currently working with "Access 2003 Inside Out" and haven't found any
comments regarding where/how data saves and writes (or cancels) are done.
 
harrzack said:
I'm new to Accesss (20 years in another 4GL db app), and am wondering
where the actual save/commit is done in a simple Access db. I'm used
to an environment where the user initiates and edit/new cycle, then
does either a Save or Cancel. The "hot commit" that Access appears to
use is a bit disconcerting!

I'm currently working with "Access 2003 Inside Out" and haven't found
any comments regarding where/how data saves and writes (or cancels)
are done.

In nearly all cases when you leave a dirty record it is saved. This
minimizes concurrency problems because a user only keeps a lock on an edited
record for the smallest amount of time possible.
 
Access writes the data to the table based on a few different events.
If you are using a form and you go to a new record, a new record is not
actually created at that time in the underlying table(s) of the form's
recordset. It only creates an empty record for you to enter data into. If
you cancel the record before it is updated, the new empty record is discarded.

Whether the record is new or not, when you navigate to a different record in
the form, the record is updated, but still not actually written to the
table(s). It will also update the record when you close the form. When you
close the form it will update the tables. You can also explicitly update the
tables by requerying the form.

When you requery or refresh the form, it will update the form's recordset
with any additions, deletions, or changes made by other users.

What language were you working in before?
 
Thanks for that commentary -- I'll take your info and study it a bit. I
previously worked with Omnis Studio (and Omnis as far back as V3.24 in '87!).
I see a lot of similarity in the "OO Style" of Studio and Access, but there
is a lot of new techniques to learn with Access.
 
With some DBMS's, like Oracle, you have to issue a Commit statement in SQL to
save any data changes. Often the program using the database, such as Oracle
Forms, with have AutoCommit options to take care of this for you.

In essesnce, Access is always in AutoCommit mode.
 
harrzack said:
Thanks for that commentary -- I'll take your info and study it a bit. I
previously worked with Omnis Studio (and Omnis as far back as V3.24 in
'87!).
I see a lot of similarity in the "OO Style" of Studio and Access, but
there
is a lot of new techniques to learn with Access.


Did you use Omnis with Raining Data's d3 database?

if you did, I have a following article that I wrote quite a few years ago on
converting an application from the pick database system (raining data d3) to
ms-access.

you find that article here:
http://www.members.shaw.ca/AlbertKallal/Articles/fog0000000003.html

Even if you weren't using pick/raining data d3 with Omnis, you'll likely
find the above article a good read anyway.
 
Dave,
As far as I know, when you navigate to another record on a form, the
record that you were on is written to the table in the database at that
point. As a matter of fact if you move from a form to a sub-form the
record is written to the table at that point.

You can test this by updating an existing record and then moving to the
next record. Then print a report using the record that was just updated
- you will see the updated information in the report.

'====================================================
John Spencer
Access MVP 2002-2005, 2007-2008
Center for Health Program Development and Management
University of Maryland Baltimore County
'====================================================
 
harrzack said:
I'm new to Accesss (20 years in another 4GL db app), and am wondering where
the actual save/commit is done in a simple Access db. I'm used to an
environment where the user initiates and edit/new cycle, then does either a
Save or Cancel. The "hot commit" that Access appears to use is a bit
disconcerting!

If you have the Record Selector visible on the left hand side of the
screen, which is the default, watch as it changes from a black, right
facing triangle to a pencil and back to a triangle. That's simplistic
but it tells you when Access/Jet has a record locked.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
Never worked with Pick. I was total Omnis/Studio, coming up from V3.24 on Mac
thru V5, then into Studio 2.0 and on. With Studio V3.2 (around 2001 or so),
things got pretty good, software-wise. But by then other tools had become
more popular, and they lost their window of opportunity. Did it take hold in
the Pick/D3 community?
 
harrzack said:
Never worked with Pick. I was total Omnis/Studio, coming up from V3.24 on
Mac
thru V5, then into Studio 2.0 and on. With Studio V3.2 (around 2001 or
so),
things got pretty good, software-wise. But by then other tools had become
more popular, and they lost their window of opportunity. Did it take hold
in
the Pick/D3 community?

Unfortunately it did not at all take off in the pick community. I think it
was a bit of mistake that they purchased d3/pick.

Also, the tools were not as easy as they could be when used with pick/d3.

The Omnis studio is nice, but Omnis didn't really integrate with multi value
datasets in pick in a seamless way without having to write code, and to me
that misses the point.

We needed an MS access like drag and drop creator for pick. The integrated
forms designer for Omnis did not automatic respect the controlling/dependent
datasets that were defined in pick's dictionaries (at least the versions I
saw did not).

To me I find it absolutely remarkable that the new version of MS access now
has a multi value data type, and now that MS access works with share point,
the conceptual data model is very similar to what pick is like (but, pick/d3
is 30 plus years old).
 
Back
Top