It is important to note that using the SetOption method only affects the run-time values of the registry and does not physically change the values in the registry. Thus, once Jet is restarted, it will read the values in the registry. This means that in order to control Jet’s registry setting the developer must use the SetOption method in code that executes every time an application starts. Below is a code sample that illustrates how a developer might use the SetOption method to optimize code to take advantage of Jet’s buffer setting:
Sub Main()
On Error GoTo ErrorHandler
Dim db As Database, rs As Recordset, ws As Workspace
Dim strCompanyName As String, _
strContactName As String, _
lngReads As Long, lngWrites As Long
Set db = _
OpenDatabase("c:\northwind.mdb", False, False)
DBEngine.SetOption dbMaxBufferSize, 128
Set rs = db.OpenRecordset _
("SELECT * FROM Customers", dbOpenDynaset)
Set ws = Workspaces(0)
lngReads = DBEngine.ISAMStats(0, True)
lngWrites = DBEngine.ISAMStats(1, True)
While Not rs.EOF
rs.Edit
strCompanyName = rs!CompanyName
strContactName = rs!ContactName
rs!CompanyName = strCompanyName
rs!ContactName = strContactName
rs.Update
rs.MoveNext
Wend
' The null transaction ensures no more asynchronous
' activity that could yield inaccurate statistics.
ws.BeginTrans
ws.CommitTrans
lngReads = DBEngine.ISAMStats(0)
lngWrites = DBEngine.ISAMStats(1)
MsgBox "Total reads " & CStr(lngReads) & _
" Total writes " & CStr(lngWrites)
Exit Sub
ErrorHandler:
MsgBox "An error has occurred " & Err & " " & Error
Resume Next
End Sub
Note: If the dbMaxBufferSize value above is modified from 128 to 2048, the number of writes will decrease from 20 to 11. This is an extreme example to illustrate the point while using the Northwind database. Using these numbers for a real world scenario is not recommended.
While programmatically flushing Jet’s write cache isn’t necessarily a performance enhancement, it allows developers to guarantee that their data has been written to disk after they issue the DAO CommitTrans method. While Jet does tell the operating system to write its data to disk after a CommitTrans, the operating system has a lazy-write cache that does not necessarily write data to disk, but does notify Jet that the data has been written to its cache. While Jet could tell the operating system to bypass its lazy-write cache, doing so would cause significant performance degradation. Therefore, to give developers the best default performance, but allow for increased functionality, Jet exposed an interface to bypass Windows 95’s and Windows NT Server/Workstation’s lazy-write cache. (Note: This feature works only for Windows 95 and Windows NT Server/Workstation. If the .mdb file is used with any other operating system, the feature will not work.) You can programmatically flush the cache by using an additional property on the CommitTrans method called dbForceOSFlush (for example, ws.CommitTrans dbForceOSFlush).
A feature of Jet 3.0 was the ability to have performance parity between a database being opened as shared and a database being opened exclusively. This was largely accomplished by improved buffer refreshing. However, to implement that feature, it was necessary to modify the behavior of PageTimeout to check the database header page (DBH). The default for checking the DBH was determined by the PageTimeOut setting in the registry and by default would retry it every five seconds. While this proved optimal for performance, the drawback was that a user could go for almost ten seconds before seeing changes made by other users. The workaround for this behavior was to set the PageTimeOut registry setting to a lower value. However, this resulted in a performance hit as Jet was forced to read the DBH more frequently, resulting in increased I/O.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.