Solved

Native Jet OLE DB Provider vs. Microsoft Access Direct Link

Posted on 2009-07-02
20
990 Views
Last Modified: 2013-11-29
Hello EE,
I am using Access 2003 for this project.  I have a database which has linked tables to 5 other databases.  This databash crashes often and I have already gone through most of the famous steps for crash prevention.  I came across the article below and need to know if my understanding of it is correct and if there's a fast way to implement amongst a lot of users.

It seems like this article is saying that instead of doing the traditional link to a table in another Access database I should:  Go to the control panel's ODBC administrative options and create Access ODBC data source on each PC.  Then within the main access database link to these ODBC connections (instead of linking directly to the other Access database.)  Do I have this right?

LVBarnes

http://support.microsoft.com/kb/299974
excerpt...
When you run Microsoft Jet in an IIS environment, it is recommended that you use the native Jet OLE DB Provider in place of the Microsoft Access ODBC driver. The Microsoft Access ODBC driver (Jet ODBC driver) can have stability issues due to the version of Visual Basic for Applications that is invoked because the version is not thread safe. As a result, when multiple concurrent users make requests of a Microsoft Access database, unpredictable results may occur. The native Jet OLE DB Provider includes fixes and enhancements for stability, performance, and thread pooling (including calling a thread-safe version of Visual Basic for Applications).

0
Comment
Question by:Lawrence Barnes
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 9
  • 9
  • 2
20 Comments
 
LVL 39

Accepted Solution

by:
thenelson earned 500 total points
ID: 24767800
No, it's saying the opposite. don't use ODBC.

Check into these:
Reduce Corruption, Speed up database
All databases are heavy network users. To reduce the risk of corruption and speed up the database, these are things to do for any database:

1: Make sure your hardware is in top shape, all computers are routinely vacuumed to remove dust and lint and your network is set up correctly. Have all the machines on the same domain.

2: Have individual front ends on each machine. I created a database that checks the server for a newer copy of the front end, downloads it if needed, then runs it. You can get a copy of it at: http://www.thenelson.name/, Updated Front End

3: Create a mapped drive for the backend or place the backend folder as close to the root folder and use only UNC path to the backend. Some people (and Microsoft) say the mapped drive is better, some say the UNC path is better. I have found it depends on the network setup.

4: Have the name of the backend and the name of the folders in the UNC path to it as short as possible meeting dos 8.3 naming specs and with only alpha numeric characters. \\server1\C:\db\db1_be.mdb is better than \\Database Server 601\C:\My Database Folder\Database Backends\My Database Backend_be.mdb

5: Don't run a local copy of the front end on the machine that has the backend -- best to have the backend on a true server running a domain with all workstations subscribed to the domain. You might get by running home version for two computers, maybe three sharing a very small, simple Access database on the home version although you may run into sharing problems. In a work situation, running a multi user Access database, all workstations should be running the pro version. It you have less than about five workstations, you might get away with the backend being on a system running pro but more than that or with a complicated database, you need a domain and the server running a server OS. Get up to a dozen heavy users or a couple of dozen light users and the server should be a true server, be dedicated to only serving the one database and the backend should be SQL Server (or SQL Server Express)

All of this is cutting down the number of times accesses need to be qualified, files need to be opened and closed and reduces the complexity of parsing the path all of which reduces the chance of corruption and speed up the database.
0
 
LVL 5

Author Closing Comment

by:Lawrence Barnes
ID: 31599387
Thank you....I'm so glad I asked.  You saved me a lot of work.
0
 
LVL 39

Expert Comment

by:thenelson
ID: 24768212
Did you find a solution for your speed problem?
0
MS Dynamics Made Instantly Simpler

Make Your Microsoft Dynamics Investment Count  & Drastically Decrease Training Time by Providing Intuitive Step-By-Step WalkThru Tutorials.

 
LVL 57
ID: 24771833
<<It seems like this article is saying that instead of doing the traditional link to a table in another Access database I should:  Go to the control panel's ODBC administrative options and create Access ODBC data source on each PC.  Then within the main access database link to these ODBC connections (instead of linking directly to the other Access database.)  Do I have this right?>>
  No because this is a very specific instance.  It's not saying that ODBC is bad, it's saying that ODBC is bad when used in conjuntion with IIS and ASP pages.  It's a very specific circumstance.
  There are many ODBC apps out there than run without problems.
JimD.
0
 
LVL 57
ID: 24771843
and BTW, JET is usually *very* stable when used as the BE for a web server as there is only one user connected at one time, which is the web server software itself.
JimD.
0
 
LVL 5

Author Comment

by:Lawrence Barnes
ID: 24772414
Nelson,
I'm still working on the speed problem and testing out the VBA that was given.

But, while waiting I  decided to try and tackle the crashing.  At this point I have the database on my laptop and it is linked to 5 other databases on the same laptop to rule out network packet crashes.  It is linked to the 5 other databases because they are each at or above 1gb.  Even with this local format, I'm still getting crashes.  I've eliminated yes/no's, decompiled, established static connections to the linked databases, etc.  The fileservers here are fairly slow, but I'll be testing out your changes today.

EE has taught me a lot about SQL processing and I understand that this application should be pointing to SQL server, but for this client that is not an option.  I can't even install a free version on a server nor put a pc on the network that pretends to be a server.
0
 
LVL 57
ID: 24772446
<<Even with this local format, I'm still getting crashes.>>
  "crashes" as in what happens?
JimD.
0
 
LVL 5

Author Comment

by:Lawrence Barnes
ID: 24772448
Hi Jim,

Thanks for your comments, you've planted a seed...instead of having the front end be Access for these 17+ users, maybe switch to an asp type of interface.  If I can do it without the IT support it may be possible.  (Their solution is to build everything within SAP which takes months.  This is a rapid prototype designed to flush out the user needs prior to developing an actual spec document.)

LVBarnes
0
 
LVL 5

Author Comment

by:Lawrence Barnes
ID: 24772775
JIm,

I forgot to answer you other question.  By crash I mean that the standard Microsoft message appears saying that the database is corrupted and that Microsoft wants to send a report as well as compact/repair the database.  Then the system creates a backup copy and the new copy opens almost immediately.  I'm running Office's service pack 3 and I've ensured that the Jet engine is up to date as well.  I do drive a lot of form driven events and the crashing is not triggered by the same thing.  As I've been building I compile often as well.

When I'm done with the above the next steps are to move everthing into a new copy of access (via importing.), recompile, change it to an Access 2002-2003 .mde format and pray.  I wish there were some way to review a crash log that the lay user (that's me) could view to see what data elements are causing it.
0
 
LVL 57
ID: 24773462
So Access itself is crashing?  That's fairly unusual given that you've tried this on different machines and have created a new MDB and imported everything into it.
That means it's either something in the code that's tripping over an Access bug or somehow related to access the data in the remote DBs.
Is there any type of pattern to the crashes (ie while accessing a certain table, using a specific form, etc).
Is the address of the crash always the same or in the same module?
What types of databases are the remote DB's?
Did you check for updated ODBC or OLEDB drivers?
JimD.
0
 
LVL 5

Author Comment

by:Lawrence Barnes
ID: 24774285
....documenting crashes...to answer some of the above.

* Yes, Access crashes and sends data to Microsoft about the crash.
* I hope it's in the code, because then it is fixable.  (One of the reasons I got rid of all the yes/no data types.)
* The remote databases are Access as well, usually containing one or two very large tables.  (Over a million records.)  These are keyed and also have certain fields indexed.
* Regarding drivers, I just used Office Update and also verified that I had the latest Jet engine  I'll post what it is when I find it.

LVBarnes
0
 
LVL 57
ID: 24777274
<<* Regarding drivers, I just used Office Update and also verified that I had the latest Jet engine  I'll post what it is when I find it.>>
  I would update MDAC (Microsoft Data Access Components) as well.
 Also, when you get a crash, click for the details and start noticing the module and address where the crash occurs.  That will usually get you started in a direction (Access itself, VBA problem, or data access).
 Million records or not, you have an unusual situation.
JimD.
0
 
LVL 5

Author Comment

by:Lawrence Barnes
ID: 24785229
If you are interested...just crashed again.  Screenshots attached.  Should I open another ticket to review this?

Error1.jpg
0
 
LVL 57
ID: 24785523
OK, so the crash occured in the Jet Expression Service.  That means it is defintely related to data operations in some way.  The offset was 00006fc9, which is where the error occured.
My suggestion would be to let it crash once or twice more and see if the module and offset are the same. I would also try and pin down if it is some specific action (ie. deleteing child rows).  
Then I would call Microsoft as this is no doubt that this is an Access bug.  I found references on the net in two places with the same error message, but no resolutions were posted.
I also checked for hotfixes and only found one that might be related.  What you said "project" is this an Access project in that your as using SQL Server for the database engine (an ADP) or is it a normal Access app where your using JET (a MDB/MDE)?
JimD.
 
0
 
LVL 57
ID: 24785606
BTW,
this is the first hot fix that may be related:
 http://support.microsoft.com/kb/956722/en-us
 Your on build 8166 of Access, so this might take care of what your seeing.
and this is the second that corrects things broken in SP3:
http://support.microsoft.com/kb/945674
JimD.
0
 
LVL 5

Author Comment

by:Lawrence Barnes
ID: 24785681
Hi Jim,

I'm just using .mdb/.mde for now.  No SQL server available.

Thanks for the tips.  How do I get points to you?

LVBarnes
0
 
LVL 57
ID: 24785756
<<I'm just using .mdb/.mde for now.  No SQL server available.>>
  OK.

<<Thanks for the tips.  How do I get points to you?>>
 At the bottom right of all the comments, you'll see a button "Accept as solution".  Just click that and you can then close the question that way.
JimD.
0
 
LVL 5

Author Comment

by:Lawrence Barnes
ID: 24786061
I've had a few more crashes.. All with the same info.
AppName: msaccess.exe      AppVer: 11.0.8166.0     AppStamp:46437912
ModName: msjtes40.dll      ModVer: 4.0.9502.0      ModStamp:44859905
fDebug: 0       Offset: 00006fc9
0
 
LVL 5

Author Comment

by:Lawrence Barnes
ID: 24786083
Regarding points...this question was closed a while back as it was related to ODBC vs VBA connections, thus the question above.
0
 
LVL 57
ID: 24786366
<<Regarding points...this question was closed a while back as it was related to ODBC vs VBA connections, thus the question above.>>
 Sorry; I forgot.  Don't worry about any points.
JimD.
0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Introduction The Visual Basic for Applications (VBA) language is at the heart of every application that you write. It is your key to taking Access beyond the world of wizards into a world where anything is possible. This article introduces you to…
Describes a method of obtaining an object variable to an already running instance of Microsoft Access so that it can be controlled via automation.
In Microsoft Access, when working with VBA, learn some techniques for writing readable and easily maintained code.
Access reports are powerful and flexible. Learn how to create a query and then a grouped report using the wizard. Modify the report design after the wizard is done to make it look better. There will be another video to explain how to put the final p…

730 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question