• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 955
  • Last Modified:

Vb.net unspecified error Jet Engine Access

I have developed a desktop application in vb.net connecting to an access database.

I have had the application installed and working properly on 40 + machines for the past year. I am now experiencing problem in 3 newly acquired machines when i try to use the application. I basically get an unspecified error message when "hitting" the database.

I have done all windows updates to ensure that .net framework and security updates were in place. I do not understand why only these 3 machines are causing the problem. I am at a loss since the message only displays unspecified error.

Any help please?!!
0
virgilar
Asked:
virgilar
  • 5
  • 4
  • 2
1 Solution
 
SStoryCommented:
I'm sorry, but that is not enough information for anyone to solve your problem.

What were the prior machines? What OS? What Service Pack?  What are the new machines? What OS? What Service Pack?  Do you have network connectivity between the new machine and the db location? or is the DB a standalone thing that gets installed on each computer?

Have you checked the Event Viewer?
0
 
ChetOS82Commented:
Check the TEMP and TMP environmental variables to make sure they are set to valid locations.  Make sure the currently logged in user has access to the specified path.

Is the access database local, or on a shared network drive?
0
 
virgilarAuthor Commented:
Here is some more information:

For all machines the operating system is: Windows XP professional with service pack 3.

The databases are local: installed under the a folder in the c:\ drive of each machine.

Since the databases are local, there is no need for network connectivity.

I have checked the event viewer and the for system and applications and no errors or warnings have been reported for this issue.


0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
SStoryCommented:
I would download Filemon.exe from
http://technet.microsoft.com/en-us/sysinternals/bb896642.aspx

and Regmon.exe from
http://technet.microsoft.com/en-us/sysinternals/bb896652.aspx

Run them both, setting the filters to avoid things you don't care to weed through. Then run your app on the machine with problems.  As soon as the error appears click the button to stop capturing data, then go through the log. Look for Access Denied and other errors.

Also, I assume you have the same MDAC on all machine?
0
 
virgilarAuthor Commented:
Althought i found out what the problem is, i still do not have a solution for it. Bascially, faster newer machines are "hitting" the access database too quickly causing the program to error out. I am using adodb in vb.net since it was a migration from vb 6. I guess i should be seriously considering using ado.net.

Thanks for all the inputs.

0
 
ChetOS82Commented:
How do you know this is the problem?
0
 
virgilarAuthor Commented:
I disabled some subroutines that were making calls to the database and the problem disapearead. However, i cannot just go without the routines i disabled so i must come up with a different way to connect and retrieve records from my access database.

That will be a huge problem since it is a large application.

0
 
SStoryCommented:
"faster newer machines are "hitting" the access database too quickly causing the program to error out."

Hmm.. That doesn't make a lot of sense.  Can you paste some of the offending code?  What version of Access?  97?  If so 97 has problems on newer machines unless JET 3.5 SPK 3 is applied.
0
 
virgilarAuthor Commented:
I guess that was an amateur explanation to the problem.

Maybe you can help me understand what is going on. I am going to attach a word document containing some explanation and some sample code.

Please take a look at it if you can.
Sample-Code.doc
0
 
SStoryCommented:
OK. I would assume you have done this, but...
Can you run the code on the offending machines in a debugger?  Or if not--ie. dev env not on that machine, then the next best thing is to put in debugging code the old fashioned way.  In the routines that you think have problems, assume NOTHING.  Put code lines that will output the values of variables, complete SQL statements, etc. So that you can be sure you are getting what you expect to be getting.  Compile that and put in on the offending machine.  Run it and see what happens.  Is there a certain Line where execution blows up? Where does the error come from? This is the first step in debugging.  Once you know that, don't assume that anything is always happening like it should, but rather test it by seeing what you are getting.  For example in the SQL string you use variables. Are they getting valid values?  Do you allow NULL in db fields? If so are they causing problems anywhere.  Check all of these sort of things.

Again I would make sure that the latest SPK for the JET engine you are using is installed on the machine.  I have seen it do wierd things otherwise. I also assume you put the correct MDAC (Microsoft Data Access Components) on each machine.
0
 
virgilarAuthor Commented:
Thanks for all the inputs SStory. I have identified the routine causing the problem and made the necessary changes to correct the issue.

I will award you the points for showing interest and willingness to help.

Thanks once more.
0

Featured Post

[Webinar] Database Backup and Recovery

Does your company store data on premises, off site, in the cloud, or a combination of these? If you answered “yes”, you need a data backup recovery plan that fits each and every platform. Watch now as as Percona teaches us how to build agile data backup recovery plan.

  • 5
  • 4
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now