| david epsom dot com dot au 2005-04-06, 8:01 pm |
| The Option that is labelled "Open databases using record-level
locking" controls the way databases are opened. The options
are record-level locking and page-level locking. Another
'kind' of locking is table-level locking. At the engine level,
these are the kinds of locks that are used.
The decisions about WHEN to lock (early, late, never,
optimistically, pessimistically etc) are controlled
separately, for example by form properties.
Theoretically, there is no reason why the lock scope should
affect the data transfer strategy, but I have noticed some
odd effects of this setting, which is why I suggested that
you try changing it.
(david)
"Neil" <njones@pxdy.com> wrote in message
news:VGG4e.1212$lP1.487@newsread1.news.pas.earthlink.net...
>
> My understanding is that the option in Tools | Options | Advanced is only
> the default record locking for forms, reports, and queries. That is, when
> a new object is created, it is given the default record locking option
> specified there.
>
> I suppose if one edits data directly in a table, the default record
> locking option comes into play. But when there is a form, report, or
> query, the RecordLocks property of that object trumps the default record
> locking option specified in Tools | Options | Advanced. That's my
> understanding, anyway.
>
> Regardless, the point is somewhat moot, since, when dealing with a SQL
> database, Jet can't lock the records anyway. From Access online help:
>
> "Note When you edit data in a linked SQL database table by using ODBC,
> Microsoft Access doesn't lock records; instead, the rules of that SQL
> database govern locking. In this instance, regardless of the
> record-locking setting you choose for your database, Microsoft Access
> always acts as though the No Locks setting has been selected."
>
>
> That could be; but one wouldn't think that going from 21 fields displayed
> to 24 would make that much of a difference. Also, I tried removing the
> three fields, and it's still slow -- which leads me to wonder if it's some
> sort of optimization issue on the SQL end which will eventually work
> itself out. Probably not; but it's a thought.
>
> Neil
>
>
>
>
>
|