Results 1 to 6 of 6

Thread: DAO Jet access not updating data immediately

  1. #1

    Thread Starter
    Addicted Member
    Join Date
    Mar 2009
    Posts
    212

    DAO Jet access not updating data immediately

    DAO (JetEngine3.51), Access mdb (dbVersion30), running windows 7 x64 ultimate with the MDB on a local drive (and not the c:\program files\ folder).

    I've got this annoying problem.

    I need to monitor changes to a certain table, so I added a field dbDate 'DateTimeLastChanged' and I use the following code to write the record:
    Code:
    Set rs = db.openrecordset("SELECT * FROM MyTable WHERE MyID=" & lMyID)
    If Not rs.EOF Then
      rs.Edit
    Else
      rs.AddNew
    End if
    rs.Fields!SomeField = SomeValue
    rs.Fields!DateTimeLastChanged = Now
    rs.Fields.Update
    rs.close
    Now I use some other query (on a timer every 10 seconds) to get all records that have changed since the last time it was read using a query like so (where '#11-12-2018 14:04:24#' is a value ofcourse:
    Code:
    dtDateTimeCheckedNew = Now
    Set rs = db.openrecordset("SELECT * FROM MyTable WHERE DateTimeLastChanged>=" & strQueryDateTime(dtDateTimeCheckedLast)) 'strQueryDateTime results in '#11-12-2018 14:04:24#'
    Do While Not rs.EOF
      call DoSomethingWithChangedRecord(rs)
      rs.MoveNext
    Loop
    rs.close
    dtDateTimeCheckedLast = dtDateTimeCheckedNew
    Now I run (on the same machine) in VB the application(AppIDE) , but also compiled (AppComp).
    When I save something in AppComp, it sometimes does not seem to be picked up on AppIDE, and it's really a second or 2 after I did the update, so not while querying (which is why I store the a new DateTimeChecked before I start querying and use that for the next query).
    Same ofcourse also happens the otherway round, when I save something in AppIDE it isn't always picked up in AppComp.

    very VERY annoying..
    Maybe someone knows what's going on, or knows another method of doing what I want to do.

  2. #2
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    6,590

    Re: DAO Jet access not updating data immediately

    SuperDre, you've come to the right place.

    I've been using the DAO (DAO360) for many years with great success, and it's virtually always used in a LAN environment with anywhere from 3 to 20 people using the same database. However, early on, I had some DAO caching problems that would occasionally crop up and cause problems. To solve that, I disabled all the DAO caching. With the seek and access rates (and server buffering) of hard drives these days, there's just no need for this DAO caching. Here's a snippet of code that does that for you:

    Code:
    
    Public Sub SetDaoRegistryOverrideOptions()
        ' The following makes sure that the DAO.DBEngine properties are set correctly.
        ' Documentation is below.
        ' These first three really shouldn't be used since the CommitSync is set.
        DAO.DBEngine.SetOption dbExclusiveAsyncDelay, 2000
        DAO.DBEngine.SetOption dbSharedAsyncDelay, 0
        DAO.DBEngine.SetOption dbFlushTransactionTimeout, 500
        '
        DAO.DBEngine.SetOption dbUserCommitSync, "yes"
        DAO.DBEngine.SetOption dbImplicitCommitSync, "yes"
        DAO.DBEngine.SetOption dbLockRetry, 20
        DAO.DBEngine.SetOption dbPageTimeout, 5000
        DAO.DBEngine.SetOption dbMaxLocksPerFile, 9500
        DAO.DBEngine.SetOption dbLockDelay, 100
        DAO.DBEngine.SetOption dbRecycleLVs, 0
    End Sub
    
    

    Now, you need to call that code VERY early on, definitely before you open any Workspace and/or databases. In fact, I call that code and then immediately open my workspace, and then start opening databases. That code should hopefully solve all your problems.

    Also, here's a version of it with all the Microsoft documentation about each of the settings. It's actually this longer version I have in my code:

    Code:
    Public Sub SetDaoRegistryOverrideOptions()
        ' The following makes sure that the DAO.DBEngine properties are set correctly.
        ' Documentation is below.
        ' These first three really shouldn't be used since the CommitSync is set.
        DAO.DBEngine.SetOption dbExclusiveAsyncDelay, 2000
        DAO.DBEngine.SetOption dbSharedAsyncDelay, 0
        DAO.DBEngine.SetOption dbFlushTransactionTimeout, 500
        '
        DAO.DBEngine.SetOption dbUserCommitSync, "yes"
        DAO.DBEngine.SetOption dbImplicitCommitSync, "yes"
        DAO.DBEngine.SetOption dbLockRetry, 20
        DAO.DBEngine.SetOption dbPageTimeout, 5000
        DAO.DBEngine.SetOption dbMaxLocksPerFile, 9500
        DAO.DBEngine.SetOption dbLockDelay, 100
        DAO.DBEngine.SetOption dbRecycleLVs, 0
        '
        '
        ' dbMaxBufferSize           The MaxBufferSize key
        ' dbUserCommitSync          The UserCommitSync key
        ' dbImplicitCommitSync      The ImplicitCommitSync key
        ' dbFlushTransactionTimeout The FlushTransactionTimeout key
        ' dbExclusiveAsyncDelay     The ExclusiveAsyncDelay key
        ' dbSharedAsyncDelay        The SharedAsyncDelay key
        
        
        ' dbPageTimeout             The PageTimeout key
        ' dbLockDelay               The LockDelay key
        ' dbMaxLocksPerFile         The MaxLocksPerFile key
        ' dbRecycleLVs              The RecycleLVs key
        ' dbLockRetry               The LockRetry key
        '
        '
        '
        ' **** Threads **** (not setable through SetOption)
        '
        ' A thread is a software process running independently on a multitasking
        ' operating system such as Windows 98 or Windows NT Workstation. For example,
        ' the ability to use multiple threads allows you to run a communications
        ' software program to download a file at the same time as you use your word
        ' processor to edit a document. Microsoft Jet uses threads internally to enhance
        ' performance and provide background services such as read-ahead caching,
        ' write-behind caching (transaction commit), cache maintenance, and the
        ' detection of changes made to shared databases. By default, Microsoft Jet
        ' uses up to a maximum of three threads. You may want to try increasing the
        ' Threads setting if a large number of actions are performed in your application,
        ' or if it contains a large number of linked tables.
        '
        '
        ' **** MaxBufferSize ****
        '
        ' Microsoft Jet reads and writes data in 2K pages, placing the data in a
        ' temporary holding area called the buffer as required by its operations. By
        ' default, when performing operations that add, delete, or update records and
        ' that aren 't part of an explicit transaction, Microsoft Jet automatically
        ' performs internal transactions that group changes to records and temporarily
        ' saves them in the buffer. After a specified time, or when the size specified
        ' by the MaxBufferSize setting is exceeded, it then writes the data as a chunk
        ' to the database. This minimizes the time spent reading and writing data to
        ' the database. Additionally, Microsoft Jet can minimize the time spent reading
        ' data for tables, queries, forms, or reports by reading available data from
        ' its buffer.
        '
        ' See Also For information about other settings that regulate the management of
        ' transactions, see "ImplicitCommitSync," "ExclusiveAsyncDelay," and
        ' "SharedAsyncDelay" later in this section.
        ' The MaxBufferSize setting specifies a "high water mark" for the size of the
        ' buffer that Microsoft Jet uses to work with records in memory, measured in
        ' kilobytes. Microsoft Jet can temporarily exceed the MaxBufferSize. As soon as
        ' it does, however, it starts a background thread to write data to the database
        ' to bring the buffer's size down to the specified "high water mark."
        ' By default, Microsoft Jet allocates memory for its internal buffer on an as-
        ' needed basis up to the MaxBufferSize. The default value written in the
        ' Windows Registry for the MaxBufferSize setting when Access is installed is 0,
        ' which indicates that Microsoft Jet calculates the setting based on the
        ' following formula:
        '
        ' ((Total RAM in K - 12,288)/4 + 512K)
        '
        ' For example, on a system with 32 MB of RAM (32,768K), Microsoft Jet uses a
        ' MaxBufferSize setting of 5,632 KB.
        ' You can override the default calculated setting by specifying a different
        ' MaxBufferSize value. This sets a new "high water mark." The minimum value
        ' that Microsoft Jet uses by default is 512K, but you can specify a value as
        ' low as 128K. However, setting the MaxBufferSize to a value less than 512K is
        ' not recommended for Access applications because it can seriously degrade
        ' performance.
        '
        ' For computers with 16 MB or less of installed RAM, there is generally no need
        ' to override the calculated setting. For computers with 32 MB of RAM, you may
        ' see some performance improvement when specifying a larger MaxBufferSize if no
        ' other applications are running at the same time as Access. For example, tests
        ' have shown performance improvements in applications that perform large
        ' transactions when a MaxBufferSize as large as 8 MB is specified.
        ' Specifying a MaxBufferSize larger than 8 MB hasn't been found to increase
        ' performance. Setting a value too high can degrade performance due to the
        ' added CPU overhead needed to manage the cache, and due to the fact that the
        ' operating system may start swapping Microsoft Jet's cache to disk as virtual
        ' memory.
        '
        ' Note When specifying a MaxBufferSize setting that is larger than the default,
        ' you should also increase the SharedAsyncDelay setting to increase the time
        ' that data is held in the buffer. If you don't increase the SharedAsyncDelay
        ' setting, Microsoft Jet writes the contents of its buffer to the database
        ' before it has had time to utilize the additional memory you specified. For
        ' more information about the SharedAsyncDelay setting, see "SharedAsyncDelay"
        ' later in this section.
        '
        '
        ' **** UserCommitSync ****
        '
        ' The UserCommitSync setting determines whether changes made as part of an
        ' explicit transaction (a change made to data by using the BeginTrans,
        ' CommitTrans, and Rollback methods) are written to the database in synchronous
        ' mode or asynchronous mode. In synchronous mode, Microsoft Jet doesn't return
        ' control to the application code until the changes made by the CommitTrans
        ' method are written to the database. In asynchronous mode, Microsoft Jet
        ' stores the changes in its memory buffer, returns control to the application
        ' code immediately, and then writes the changes to the database in a background
        ' thread. Microsoft Jet begins writing the changes either after a specified
        ' period of time (determined by the FlushTransactionTimeout setting, or by the
        ' SharedAsyncDelay or ExclusiveAsyncDelay settings described later in this
        ' section) or when the MaxBufferSize is exceeded. The default UserCommitSync
        ' setting is Yes, which specifies synchronous mode. It is not recommended that
        ' you change this setting because in asynchronous mode, there is no guarantee
        ' that information has been written to disk before your code proceeds to the
        ' next command.
        '
        ' Note If you've used explicit transactions to improve performance in previous
        ' versions of Access, you no longer need to do so. For more information, see
        ' "Using Transactions to Update Records" later in this chapter.
        ' See Also For more information about transactions, see "Microsoft Jet
        ' Transactions," in Chapter 6, "Working with Records and Fields."
        '
        '
        ' **** ImplicitCommitSync ****
        '
        ' By default, when performing operations that add, delete, or update records
        ' outside of explicit transactions, Microsoft Jet automatically performs
        ' internal transactions that temporarily save data in its memory buffer, and
        ' then later write the data as a chunk to the disk. The ImplicitCommitSync
        ' setting determines whether changes made by using these automatic internal
        ' transactions are written to the database in synchronous mode or asynchronous
        ' mode. The default setting is No, which specifies that these changes are
        ' written to the database in asynchronous mode; this provides the best
        ' performance. If you want internal transactions to be written to the database
        ' in synchronous mode, change the ImplicitCommitSync setting to Yes. If you
        ' change the setting to Yes, you get behavior similar to Microsoft Jet versions
        ' 2.x and earlier when you weren't employing explicit transactions. However,
        ' doing so can also impair performance considerably, so it is not recommended
        ' that you change this setting.
        '
        '
        ' **** FlushTransactionTimeout ****
        '
        ' The FlushTransactionTimeout setting determines Microsoft Jet's method of
        ' performing asynchronous writes to a database file. The
        ' FlushTransactionTimeout setting is the number of milliseconds after which
        ' Microsoft Jet starts writing database changes to disk from its cache. Changes
        ' are written to disk after the specified amount of time has expired and if no
        ' new pages have been added to the cache during that interval. The only
        ' exception is if the size of the cache exceeds the MaxBufferSize setting, at
        ' which point the cache starts asynchronous writes regardless of whether the
        ' time has expired. The default setting is 500 milliseconds. The only reason to
        ' increase the value of the FlushTransactionTimeout setting is if the database
        ' is being updated over a slow wide area network (WAN) or local area network
        ' (LAN) connection. Increasing this value for databases being updated over fast
        ' WAN and typical LAN connections does not improve performance.
        ' The FlushTransactionTimeout setting overrides both the ExclusiveAsyncDelay
        ' and SharedAsyncDelay Registry settings, and is the preferred method of
        ' determining how Microsoft Jet performs asynchronous writes to a database
        ' file. To enable the ExclusiveAsyncDelay and SharedAsyncDelay settings, you
        ' must set the FlushTransactionTimeout entry to a value of 0.
        '
        '
        ' **** ExclusiveAsyncDelay ****
        '
        ' The ExclusiveAsyncDelay setting is the maximum time that can pass before
        ' asynchronous mode changes start to be written to a database that's opened
        ' exclusively. The default setting is 2,000 milliseconds. Decrease this setting
        ' if you want to be sure that changes are written to your database more
        ' frequently, but note that this decreases overall performance. Because the
        ' default setting is already quite long, increasing this setting doesn't
        ' improve performance in most cases. However, if your system has 32 MB of RAM
        ' or more and you have specified a large MaxBufferSize, you may see some
        ' performance improvement if you increase this setting. By default, this
        ' setting is disabled by the FlushTransactionTimeout setting.
        '
        '
        ' **** SharedAsyncDelay ****
        '
        ' The SharedAsyncDelay setting is the maximum time that can pass before
        ' asynchronous mode changes start to be written to a database that's opened in
        ' shared mode. The default setting is 0 milliseconds. Note that this produces a
        ' small delay before changes are made available to other users. Increasing this
        ' value enhances performance in shared databases because there are fewer disk
        ' writes. However, it may reduce the overall concurrency because pages are
        ' locked while they are in the buffer waiting to be written to the database. If
        ' your application performs operations that affect many records, increase this
        ' setting to give Microsoft Jet additional time to temporarily save additions,
        ' deletions, and updates in its buffer before it writes them to the database.
        ' This applies whether your application uses action queries, DAO code, ActiveX®
        ' Data Object (ADO) code, or SQL statements to add, delete, or update records.
        ' By default, this setting is disabled by the FlushTransactionTimeout setting.
        '
        '
        ' **** PageTimeout ****
        '
        ' The PageTimeout setting determines how long Microsoft Jet waits before
        ' checking to see if other users have made changes to the database. If changes
        ' have been made, Microsoft Jet refreshes the data in its memory buffer.
        ' Note This action is equivalent to pressing F9 while viewing a table or query
        ' in Access, or using the Refresh method in DAO or ADO code.
        ' The default PageTimeout setting is 5,000 milliseconds. Decreasing this
        ' setting increases the amount of time spent reading from the disk, thus
        ' impairing performance, but can make the data available to the user more
        ' current. The Refresh Interval setting on the Advanced tab of the Options
        ' dialog box (Tools menu) in Access overrides the PageTimeout setting.
        ' Tip You can override the PageTimeout setting and refresh the cache by using
        ' the dbRefreshCache argument of the Idle method in DAO code. This allows users
        ' to see other users' changes immediately. For more information about the Idle
        ' method, type Idle method in the Office Assistant or on the Answer Wizard tab
        ' in the Help window, and then click Search.
        '
        '
        ' **** LockDelay ****
        '
        ' If Access tries to place a lock on a page in a shared database and a message
        ' that locking has failed is returned, the LockDelay setting determines how
        ' long it waits before it retries. If the time it takes to return the message
        ' exceeds the LockDelay setting, there is no delay. The default setting is 100
        ' milliseconds. On systems that don't manage lock retries themselves, such as
        ' Windows 95 peer-to-peer networking, the LockDelay setting prevents Microsoft
        ' Jet from performing repeated retries over a short period of time. If you are
        ' using such a system, the default setting is usually sufficient to reduce the
        ' number of lock requests sent across the network, which frees up network
        ' bandwidth for other purposes. If your application or its users frequently
        ' lock a large number of records, you may want to try increasing this setting
        ' to further reduce the number of lock requests being sent across the network.
        ' If you are using a server-based networking system that manages lock retries
        ' itself, such as Microsoft® Windows NT® Server or Novell® NetWare®, there is
        ' no need to change this setting.
        '
        '
        ' **** MaxLocksPerFile ****
        '
        ' The MaxLocksPerFile setting determines the maximum number of locks that
        ' Microsoft Jet places against a file. The default setting is 9,500 locks. If
        ' the number of locks required to perform a transaction exceeds the
        ' MaxLocksPerFile setting, the transaction commits (writes) the data that has
        ' locks associated with it, frees the locks, and then continues processing the
        ' transaction. If the maximum number of locks a server can handle is less than
        ' the MaxLocksPerFile setting, the server returns an error message or appears
        ' to hang when performing a large transaction. If this occurs, you should
        ' decrease the MaxLocksPerFile setting. A Novell server can be configured to
        ' perform a maximum of 10,000 locks per connection. A Novell server connection
        ' can include more than one database, so it's possible to exceed the maximum
        ' number of available locks if you are using more than one database at a time.
        '
        '
        ' **** RecycleLVs ****
        '
        ' Long value (LV) pages store data in fields with Memo, OLE object, and
        ' Hyperlink data types, as well as the data that defines forms, reports, and
        ' modules. When a database is open in shared mode, the size of the database
        ' increases when data, forms, reports, and modules are deleted or changed in
        ' such a way that the current LV page must be discarded and replaced with a new
        ' LV page. Sometimes a new LV page is needed to prevent errors for other users
        ' who may still be using the object or data in its original form.
        ' The RecycleLVs setting determines when discarded LV pages become available
        ' for reuse. The default RecycleLVs setting is 0, which specifies that
        ' discarded LV pages continue to occupy space in the database and only become
        ' available for reuse after the last user closes the database. You can change
        ' the RecycleLVs setting to 1 so that discarded LV pages become available for
        ' reuse after Microsoft Jet determines that there's only one user in the
        ' database in shared mode and that new LV data has been added to the database.
        ' Note that setting RecycleLVs to 1 slows down performance somewhat. Therefore,
        ' this is primarily useful when you are creating or modifying forms, reports,
        ' and modules because it minimizes the need to compact the database.
        ' When a database is open in exclusive mode, the RecycleLVs setting has no
        ' effect: discarded LV pages become available for reuse immediately. In both
        ' exclusive mode and shared mode, discarded LV pages are reused only when new
        ' LV data needs to be written to the database. To remove discarded LV pages
        ' before that time, you must compact the database.
        '
        ' **** LockRetry ****
        '
        ' The number of times to repeat attempts to access a locked page before
        ' returning a lock conflict message.  The default is 20.
        '
    End Sub

    Best of Luck,
    Elroy

    EDIT1: SuperDre, on a re-read of your OP, I noticed you're using the DAO 3.51. I don't know if the above will work on that version. However, I have a very high degree of confidence that upgrading to DAO 3.60 won't hurt one single thing in the way your code works. Furthermore, I don't believe the DAO 3.51 is natively pre-installed in later versions of Windows, whereas the DAO 3.60 has been pre-installed in all versions of Windows going back to XP and all the way through Windows 10.
    Any software I post in these forums written by me is provided “AS IS” without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. Please understand that I’ve been programming since the mid-1970s and still have some of that code. My contemporary VB6 project is approaching 1,000 modules. In addition, I have a “VB6 random code folder” that is overflowing. I’ve been at this long enough to truly not know with absolute certainty from whence every single line of my code has come, with much of it coming from programmers under my employ who signed intellectual property transfers. I have not deliberately attempted to remove any licenses and/or attributions from any software. If someone finds that I have inadvertently done so, I sincerely apologize, and, upon notice and reasonable proof, will re-attach those licenses and/or attributions. To all, peace and happiness.

  3. #3
    PowerPoster
    Join Date
    Jun 2013
    Posts
    5,473

    Re: DAO Jet access not updating data immediately

    There is no Rs.Fields.Update Method in DAO-Rs...

    You should use a simple Rs.Update -
    or alternatively (with a bit more "force") - make use of the optional Params like:
    Rs.Update dbUpdateCurrentRecord,True

    Olaf

  4. #4
    PowerPoster ChrisE's Avatar
    Join Date
    Jun 2017
    Location
    Frankfurt
    Posts
    2,795

    Re: DAO Jet access not updating data immediately

    Hi Dre,
    try the option and use a Param. Query

    create a Query based on the Table and add the criteria you need to check for
    save it ... for example Query1
    Code:
    Private Sub Command3_Click()
    Listview1.ListItems.Clear
    Dim Item As ListItem
    Dim rs As Recordset
    Dim qd As QueryDef
    Set qd = db.QueryDefs("Query1")
    qd.Parameters("pID") = Text1.Text 'criteria 
    Set rs = qd.OpenRecordset
     Do Until rs.EOF
            Set Item = Listview1.ListItems.Add(, , rs!FieldName1)
            Item.SubItems(1) = rs!FieldName2
            Item.SubItems(2) = rs!FieldName3
        rs.MoveNext
    Loop
    If Listview1.ListItems.Count > 0 Then
    Label2.Caption = Listview1.ListItems.Count & " your Text for found !"
    If Listview1.ListItems.Count > 0 Then
    'do stuff
    End If
    End If
    If Listview1.ListItems.Count = 0 Then
    Label2.Caption = "nothing found  " & Text1 & " !"
    'do Nothing ?
    End If
    Exit Sub
    End Sub
    regards
    Chris
    to hunt a species to extinction is not logical !
    since 2010 the number of Tigers are rising again in 2016 - 3900 were counted. with Baby Callas it's 3901, my wife and I had 2-3 months the privilege of raising a Baby Tiger.

  5. #5

    Thread Starter
    Addicted Member
    Join Date
    Mar 2009
    Posts
    212

    Re: DAO Jet access not updating data immediately

    Quote Originally Posted by Elroy View Post
    Best of Luck,
    Elroy

    EDIT1: SuperDre, on a re-read of your OP, I noticed you're using the DAO 3.51. I don't know if the above will work on that version. However, I have a very high degree of confidence that upgrading to DAO 3.60 won't hurt one single thing in the way your code works. Furthermore, I don't believe the DAO 3.51 is natively pre-installed in later versions of Windows, whereas the DAO 3.60 has been pre-installed in all versions of Windows going back to XP and all the way through Windows 10.
    Thank you very much Elroy, I'll look into it. And I'll also look into 3.60.


    Quote Originally Posted by Schmidt View Post
    There is no Rs.Fields.Update Method in DAO-Rs...

    You should use a simple Rs.Update -
    or alternatively (with a bit more "force") - make use of the optional Params like:
    Rs.Update dbUpdateCurrentRecord,True

    Olaf
    Thanx Olaf, it was a typo on my part, as you point out, I should have written rs.Update.
    But I don't think dbUpdateCurrentRecord is the Type I want, as the default is dbUpdateRegular ((Default) Pending changes are not cached and are written to disk immediately.), but I'll try the Force:=true part.

    Quote Originally Posted by ChrisE View Post
    Hi Dre,
    try the option and use a Param. Query
    Thanx Chris, I'll first try the other suggestions and if those don't work I'll try yours (To be honest, I don't use querydefs at all (in access) due to them being too maintenance heavy, but if it'll fix this problem for me, I certainly will for this exception )..

  6. #6

    Thread Starter
    Addicted Member
    Join Date
    Mar 2009
    Posts
    212

    Re: DAO Jet access not updating data immediately

    Well, I've been busy:

    Rs.Update dbUpdateCurrentRecord,True well, that one just gives me a 'Invalid argument' error (even though intellisense shows the parameters and the documentation for 3.5 also mentions them). So sadly that a nogo and a

    So I tried the DBEngine.SetOption method. BUT there is no way to check what settings it's actually using, there is no GetOption.
    But I went the 'safe' way:
    Read the original value from the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Jet\3.5\Engines\Jet 3.5), which I also pass a default value from the documentation, I pass the value I get as a default value to another function that reads the value from an INI file which in the end is thrown to DBEngine.SetOption (I use the INI file as simple way to override so I only have to put that file into a folder of a customer or something and not go adding values in the user registry).

    But I didn't notice any difference when I changed some stuff. (also documentation of 3.5 mentions all these settings)

    Quote Originally Posted by Elroy View Post
    Code:
    
    Public Sub SetDaoRegistryOverrideOptions()
        ' The following makes sure that the DAO.DBEngine properties are set correctly.
        ' Documentation is below.
        ' These first three really shouldn't be used since the CommitSync is set.
        DAO.DBEngine.SetOption dbExclusiveAsyncDelay, 2000
        DAO.DBEngine.SetOption dbSharedAsyncDelay, 0
        DAO.DBEngine.SetOption dbFlushTransactionTimeout, 500
        '
        DAO.DBEngine.SetOption dbUserCommitSync, "yes"
        DAO.DBEngine.SetOption dbImplicitCommitSync, "yes"
        DAO.DBEngine.SetOption dbLockRetry, 20
        DAO.DBEngine.SetOption dbPageTimeout, 5000
        DAO.DBEngine.SetOption dbMaxLocksPerFile, 9500
        DAO.DBEngine.SetOption dbLockDelay, 100
        DAO.DBEngine.SetOption dbRecycleLVs, 0
    End Sub
    
    
    Now when I check your settings, and read the documentation, the only difference with default is the ImplicitCommitSync, as SharedAsyncDelay is ignored due to FlushTransactionTimeout not being 0.

    For now I don't have the time to upgrade the project to 3.6 (and with windows 10 I see 4.0 is the default that ships (at least I see an 4.0 registrysetting before I installed my application on my normal windows 10 machine))..

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width