• WSJimDettman

    WSJimDettman

    @wsjimdettman

    Viewing 11 replies - 31 through 41 (of 41 total)
    Author
    Replies
    • in reply to: Table locks and user notification (Access 97) #1786445

      Outside of the services offered by JET 4.0 already mentioned, you can use the functions found in Msldbusr.dll, to read the .LDB file. Notification can occur on the netwrok level or be something that you build into the app. Here’s a link to a MSKB article that will give you the info/code that you need:

      http://support.microsoft.com/support/kb/ar…s/Q186/3/04.ASP

      Jim.

      Edited to add active link–Charlotte

    • in reply to: Access XP #529847

      The tip would still apply. Bottom line is your still touching a JET MDB file. Repeated opening and closing under NT is slow. So as long as a recordset is held open against a table (DAO or ADO), that won’t happen and you’ll see a speed up.

      Jim.

    • in reply to: Access XP #529634

      ADO Connection to what? Keep in mind that were talking about a split type of app with the “backend” being a native JET .MDB.

      If the “backend” is Oracle, SQL Server, etc, then the tip about holding a table open doesn’t apply.

      Jim.

    • in reply to: Access XP #529620

      Doesn’t matter because you still end up at JET. Only thing this doesn’t apply to is A2000 with MSDE.

    • in reply to: Access XP #529491

      John,

      It’s nothing fancey. Can be as simple as opening a hidden form that’s bound to a table from the Autoexec macro.

      Or you can set a global recordset variable and just open a table through a startup function.

      In one case where a relink of all the backend tables was being done (about 50 tables), the relink time dropped from two and a half minutes down to 15 seconds or so when the first table relinked was held open until the relink was finished.

      Jim.

      Jim.

    • in reply to: Access XP #529490

      No, it’s a registry hack on the NT server. Don’t remember what the setting is under Novell, but it has the same thing to.

      Jim.

    • in reply to: Access XP #529489

      It’s a little more complicated then that. Access only *requests* locks be placed/removed with the OS/NOS that handles the file operations for the MDB file (and hence the LDB file). It doesn’t handle the locks themselves. For example, it says to the OS/NOS “I want to take a lock on byte 16,000,000 of the file xxxx.LDB” The OS/NOS then takes care of recording the lock. With Win 3.1, that was done by SHARE.EXE. With Win9x, it’s done by vshare.vxd. Under NT, it’s the lock manager.

      This is called extented byte range locking. What that means is is that Access takes locks out on parts of the LDB file that don’t exist. For example, Access uses a “User Lock” to indicate that a user is in the MDB and taking up one of the 255 slots in the LDB file. This lock is placed in the 7 million byte range (if memory serves correct). The LDB file doesn’t have 7 million bytes though. In fact, it will never grow larger then 16K.

      So by using different byte ranges to represent different types of locks, Access can generate whatever type of locking scheme it wants without every writting anything to disk or having to work within any predefined data structure. This means that the locking scheme can be changed from release to release quite easily.

      Jim.

    • in reply to: Access XP #529454

      Keeping a table open in the backend keeps it from repeatedly opening and closing. If a frontend closes all references to a backend, Access goes ahead and closes it. As soon as a reference is made to it, it then opens it again.

      With that process, there is quite a bit of overhead (check for access to the file, placing an entry in the LDB file, placing a user lock, etc) so this can really slow down and app.

      Under NT, the problem seems to worse because its not that great of a performer, especially the lock manager.

      Jim.

    • in reply to: Access XP #529396

      Been doing fine. Hope you are too. But really, from what I’ve heard, A2000 does fine once configured properly and after applying SR1 (bug fix).

      It also seems to deal with locking a lot more then other versions, so when working with NT (which has a poor performing lock manager), it seems to be quite a bit slower. But there are ways around that. Top 5 things you can do for A2000 are:

      1. Hold open a table in the backend MDB for the life of the app.
      2. Turn off the subdata sheet feature.
      3. Turn off name autocorrect.
      4. Make sure the client/server are using hte same default protocol.
      5. Turn off client side caching of files (opportunistic locking under NT)

      Jim.

    • in reply to: Access XP #529360

      Peformance issues?

    • in reply to: Access Character Set #529359

      You can get the correct characters two ways:

      1. Cut and paste from Character Map – This is a windows utility found under Accessories/system tools (it may need to be installed).

      2. Set the controls datasource to:

      =Chr$(xx) & chr$(xx) & …etc.

      Jim.

    Viewing 11 replies - 31 through 41 (of 41 total)