GSDAssociates
asked on
Cause of "Jet database engine cannot find the input table or query [Table Name]" Errors
ISSUE:
An application is randomly disconnected from it's back-end MS Access database and raises the error "The Microsoft Jet database engine cannot find the input table or query [Table Name]. Make sure it exists and that its name is spelled correctly".
The tables in question can be completely random, the error has covered over five different tables in completely different parts of the program (Purchase Orders, Sales Orders, Stock Codes, Sale Units, GRN Receipts, Invoices etc).
TECHNICAL INFO\SETUP:
- The application is a standard Windows program written with Borland Delphi.
- The application uses ADO to connect to the Access database.
- The database is located on a Windows 2003 Small Business Server.
- It's a small TCP\IP LAN based network with 9 workstations.
- All workstations are running Windows XP SP2 or SP3.
- The program establishes connectivity by loading the connection string for the database from a Data Link (.udl) file located in the program directory.
There is also an older IPX\BNC network infrastructure running along side the TCP\IP Cat-5 based network that allows the users to run an old DOS system up on their workstations that is running off an old Novell 3.5 Server. However, consulting with some hardware\network engineers, they have said this should not be affecting the TCP\IP Cat-5 network as they are two completely separate networks.
BACKGROUND INFO:
This is the first and only-site to date we have experienced this issue occur at. The application in question is a standard product in use at over 10+ sites.
We have done a lot of research on the nature of this problem, and the usual suggestion is that the database is in some way corrupted, but we have checked this through and the database is perfectly fine, there does not appear to be any corruptions.
We believe that the error message displayed seems to be more of a symptom rather than pointing to the cause...
We believe that something is forcing a disconnection between our program and the database (maybe Anti-Virus or other security software?) because once this error is received, if you try and do anything else in the program error messages are displayed that show the program is no longer connected to the database and it can't seem to reconnect either. You have to close the application and re-open it continue working as normal.
Our application is designed to trap all errors raised by itself and present them in a special error dialog (MadExcept) however, this error seems to be raised by Windows \ The Microsoft Jet Engine directly....
Also, the error is only being experienced by 6 workstations on the network. The other 3 workstations have NEVER had this error occur.
We have had third party network engineers come in and make changes the network, including replacing the main router, but this error continues to occur.
* * * * * *
Could anyone assist in giving us some help on this problem if they have come across something similar before because we are a bit baffled by what is causing this and how we can remedy the problem.
Many Thanks
- Paul
An application is randomly disconnected from it's back-end MS Access database and raises the error "The Microsoft Jet database engine cannot find the input table or query [Table Name]. Make sure it exists and that its name is spelled correctly".
The tables in question can be completely random, the error has covered over five different tables in completely different parts of the program (Purchase Orders, Sales Orders, Stock Codes, Sale Units, GRN Receipts, Invoices etc).
TECHNICAL INFO\SETUP:
- The application is a standard Windows program written with Borland Delphi.
- The application uses ADO to connect to the Access database.
- The database is located on a Windows 2003 Small Business Server.
- It's a small TCP\IP LAN based network with 9 workstations.
- All workstations are running Windows XP SP2 or SP3.
- The program establishes connectivity by loading the connection string for the database from a Data Link (.udl) file located in the program directory.
There is also an older IPX\BNC network infrastructure running along side the TCP\IP Cat-5 based network that allows the users to run an old DOS system up on their workstations that is running off an old Novell 3.5 Server. However, consulting with some hardware\network engineers, they have said this should not be affecting the TCP\IP Cat-5 network as they are two completely separate networks.
BACKGROUND INFO:
This is the first and only-site to date we have experienced this issue occur at. The application in question is a standard product in use at over 10+ sites.
We have done a lot of research on the nature of this problem, and the usual suggestion is that the database is in some way corrupted, but we have checked this through and the database is perfectly fine, there does not appear to be any corruptions.
We believe that the error message displayed seems to be more of a symptom rather than pointing to the cause...
We believe that something is forcing a disconnection between our program and the database (maybe Anti-Virus or other security software?) because once this error is received, if you try and do anything else in the program error messages are displayed that show the program is no longer connected to the database and it can't seem to reconnect either. You have to close the application and re-open it continue working as normal.
Our application is designed to trap all errors raised by itself and present them in a special error dialog (MadExcept) however, this error seems to be raised by Windows \ The Microsoft Jet Engine directly....
Also, the error is only being experienced by 6 workstations on the network. The other 3 workstations have NEVER had this error occur.
We have had third party network engineers come in and make changes the network, including replacing the main router, but this error continues to occur.
* * * * * *
Could anyone assist in giving us some help on this problem if they have come across something similar before because we are a bit baffled by what is causing this and how we can remedy the problem.
Many Thanks
- Paul
ASKER
Hi Gustav,
Thanks for the reply.... indeed, I am expecting a flood of such comments about upgrading to SQL Server :o)
We suspected maybe a security configuration\permissions could possibly be at play, so checked over the workstations to see if there was any difference in configuration from a security point of view, there doesn't appear to be any difference at a workstation level.
2 of the 3 workstations that seem to be okay are used by accounts people who do have elevated security permissions that allow them to access the accounts share, but 1 of the workstations is used by a normal user who has the same permissions as the other users who are on the other 6 workstations experiencing the problem.
It's a puzzler for sure.
I am contemplating swapping over one of the 'good' machines with a 'bad' one to test if could be a network access point at fault (if it were, the good workstation would all of a sudden start having the problem, and the 'bad' workstation would stop), if that occur though and the good workstation was still not having the error, while the bad one carried on, it could point to something hardware related on the actual machine...
- Paul
Thanks for the reply.... indeed, I am expecting a flood of such comments about upgrading to SQL Server :o)
We suspected maybe a security configuration\permissions could possibly be at play, so checked over the workstations to see if there was any difference in configuration from a security point of view, there doesn't appear to be any difference at a workstation level.
2 of the 3 workstations that seem to be okay are used by accounts people who do have elevated security permissions that allow them to access the accounts share, but 1 of the workstations is used by a normal user who has the same permissions as the other users who are on the other 6 workstations experiencing the problem.
It's a puzzler for sure.
I am contemplating swapping over one of the 'good' machines with a 'bad' one to test if could be a network access point at fault (if it were, the good workstation would all of a sudden start having the problem, and the 'bad' workstation would stop), if that occur though and the good workstation was still not having the error, while the bad one carried on, it could point to something hardware related on the actual machine...
- Paul
The swap is a good idea. It could reveal an error source.
/gustav
/gustav
ASKER
Not sure, I haven't personally written the application in question so I would have to fire the question at our main developer.
One thought though - on the vb forum post, the chap who posted the message mentioned just closing the window... so I presume his program was still running in general, and therefore by re-opening the window, the program (the same running instance) just re-connected and off it went again...
Whereas something seems to be block our program's attempt to re-connect to the data source once it's been disconnected unless you close the program completly and then re-open it...
One thought though - on the vb forum post, the chap who posted the message mentioned just closing the window... so I presume his program was still running in general, and therefore by re-opening the window, the program (the same running instance) just re-connected and off it went again...
Whereas something seems to be block our program's attempt to re-connect to the data source once it's been disconnected unless you close the program completly and then re-open it...
Well, Connection does have a time-out property:
cnn.ConnectionTimeout = integer (seconds)
Default is 15 seconds.
/gustav
cnn.ConnectionTimeout = integer (seconds)
Default is 15 seconds.
/gustav
ASKER
I've asked our main developer to consider the timeouts and come back to me with the info.
From memory when we discussed this before, I think he said he sets all connections to have a 60 second timeout but can't be sure on that.
Do you think a timeout cause the error message "Cannot find input table or query..." etc, I would have thought it would have returned a more timeout speciffic message such as "Connection to [X] timed out"
- Paul
From memory when we discussed this before, I think he said he sets all connections to have a 60 second timeout but can't be sure on that.
Do you think a timeout cause the error message "Cannot find input table or query..." etc, I would have thought it would have returned a more timeout speciffic message such as "Connection to [X] timed out"
- Paul
Yes, your error message would be more likely. The time out of the connection is not an error on its own.
/gustav
/gustav
ASKER
Hi Gustav,
Having spoke with our main developer, he confirms the following:
**************************
There are 2 Time Out setting on the ADO Components:
1. ConnectionTimeOut (TADOConnection)
This defaults to 15 Seconds but I suspect is only relevant when the
Connection is first made (i.e. when the Company has been selected).
2. CommandTimeOut (ADOConnection, TADODataSet, TADOCommand etc..)
This defaults to 30 Seconds. The only time I have had to increase this is for a customer running a bespoke system linked to SQL Server where sometimes they were receiving 'Time Out' errors when running very long Reports which involved a Query which SQL
Server took a while to run.
If timeouts seem to be the problem then this points towards a network or Server log Jam as under normal circumstances the default 30 Seconds should be more than enough time for Access to return the requested data.
**************************
- Paul
Having spoke with our main developer, he confirms the following:
**************************
There are 2 Time Out setting on the ADO Components:
1. ConnectionTimeOut (TADOConnection)
This defaults to 15 Seconds but I suspect is only relevant when the
Connection is first made (i.e. when the Company has been selected).
2. CommandTimeOut (ADOConnection, TADODataSet, TADOCommand etc..)
This defaults to 30 Seconds. The only time I have had to increase this is for a customer running a bespoke system linked to SQL Server where sometimes they were receiving 'Time Out' errors when running very long Reports which involved a Query which SQL
Server took a while to run.
If timeouts seem to be the problem then this points towards a network or Server log Jam as under normal circumstances the default 30 Seconds should be more than enough time for Access to return the requested data.
**************************
- Paul
That sounds right. However, as easy as it is, why not try to set it to, say, 120 seconds for a period and watch if it makes any change.
If it does, I guess it just indicates some error or bottleneck somewhere else, but at least you would know what to look for.
/gustav
If it does, I guess it just indicates some error or bottleneck somewhere else, but at least you would know what to look for.
/gustav
Have you looked at firewalls on the workstations?
Is there a significant difference in memory and/or CPU between the good/bad machines?
Are the NICs setup to be 100 Full on all the workstations and the switch?
If you fire up Task Manager and look at the Networking tab, how do they compare among machines?
Just throwing things out to think about.....
Is there a significant difference in memory and/or CPU between the good/bad machines?
Are the NICs setup to be 100 Full on all the workstations and the switch?
If you fire up Task Manager and look at the Networking tab, how do they compare among machines?
Just throwing things out to think about.....
Paul,
<<Also, the error is only being experienced by 6 workstations on the network. The other 3 workstations have NEVER had this error occur.>>
Sounds like a network problem to me...
<<I am contemplating swapping over one of the 'good' machines with a 'bad' one to test if could be a network access point at fault (if it were, the good workstation would all of a sudden start having the problem, and the 'bad' workstation would stop), if that occur though and the good workstation was still not having the error, while the bad one carried on, it could point to something hardware related on the actual machine...>>
Excellent idea. A gut hunch is your going to find it related to the NIC in some way. Check for any diagnostic protocol's loaded on those machines. Often these diag protocols will disconnect the NIC from the network for a moment, run a diag on the card, then re-connect. Most programs won't notice, but some do. If your app is working at this point, that's the kind of error you'd see. 3COM was great for this.
Also look at the drivers loaded on those cards. See if they are the same.
I would also just double check and ensure your running the same version of JET on all the machines. Look for MSJET*.DLL and check the version numbers. Last, I would also check the version of MDAC (use componet checker) between a good/bad machine. It wasn't clear from your question if your using ODBC or OLEDB, but both of those would be affected by the MDAC version installed.
However I do believe you'll find it's some kind of network problem. I'd check for diag protocol's quick and then move onto the station swap as a first step.
JimD.
<<Also, the error is only being experienced by 6 workstations on the network. The other 3 workstations have NEVER had this error occur.>>
Sounds like a network problem to me...
<<I am contemplating swapping over one of the 'good' machines with a 'bad' one to test if could be a network access point at fault (if it were, the good workstation would all of a sudden start having the problem, and the 'bad' workstation would stop), if that occur though and the good workstation was still not having the error, while the bad one carried on, it could point to something hardware related on the actual machine...>>
Excellent idea. A gut hunch is your going to find it related to the NIC in some way. Check for any diagnostic protocol's loaded on those machines. Often these diag protocols will disconnect the NIC from the network for a moment, run a diag on the card, then re-connect. Most programs won't notice, but some do. If your app is working at this point, that's the kind of error you'd see. 3COM was great for this.
Also look at the drivers loaded on those cards. See if they are the same.
I would also just double check and ensure your running the same version of JET on all the machines. Look for MSJET*.DLL and check the version numbers. Last, I would also check the version of MDAC (use componet checker) between a good/bad machine. It wasn't clear from your question if your using ODBC or OLEDB, but both of those would be affected by the MDAC version installed.
However I do believe you'll find it's some kind of network problem. I'd check for diag protocol's quick and then move onto the station swap as a first step.
JimD.
Oh and one other thing, if you have multiple protocol's loaded to handle the older stuff (ie TCPIP and Netbeui), check the order of the protocols listed. Make sure they are in the same sequence.
I don't remember if that problem applies to XP or not, but it used to be that if the default protocol was different on different machines, timeouts could occur on the other protocols - I'm not sure I remember this exactly as this is an old problem, but it won't hurt to list them in the same order. I'll dig for the MSKB reference and see if I can find it.
JimD.
I don't remember if that problem applies to XP or not, but it used to be that if the default protocol was different on different machines, timeouts could occur on the other protocols - I'm not sure I remember this exactly as this is an old problem, but it won't hurt to list them in the same order. I'll dig for the MSKB reference and see if I can find it.
JimD.
Just a comment on the MDAC: WinXP SP2 and beyond has the MDAC 2.81 already installed and updated via the Windows Update. You have to beat on it to do a "repair". The link below gives you an idea on how to do it.
How to Repair MDAC 2.8 Under Windows XP with SP2 Installed
http://www.macropool.com/en/download/mdac_xp_sp2.html
How to Repair MDAC 2.8 Under Windows XP with SP2 Installed
http://www.macropool.com/en/download/mdac_xp_sp2.html
One other thing: excellent level of detail on the question!
JimD.
JimD.
Jim D.
I have to agree this is a nicely worded, well thought out question. It is very rare to see such a good explanation and know what ground has already been traveled.
>> Oh and one other thing, if you have multiple protocol's loaded to
>> handle the older stuff ....
Does this article sound like the one he should be looking for about protocol order?
How to Optimize Network Connections in Windows XP
http://www.windowsnetworking.com/articles_tutorials/Optimize-Network-Connections-Windows-XP.html
I have to agree this is a nicely worded, well thought out question. It is very rare to see such a good explanation and know what ground has already been traveled.
>> Oh and one other thing, if you have multiple protocol's loaded to
>> handle the older stuff ....
Does this article sound like the one he should be looking for about protocol order?
How to Optimize Network Connections in Windows XP
http://www.windowsnetworking.com/articles_tutorials/Optimize-Network-Connections-Windows-XP.html
Jim,
Yes, that's along the lines I was talking about. However what I was referring to was an age old problem (think it may have been back in the A2/ Win 3.11 days) where time outs would occur if the order of protocols was different.
Since NetBeui has been left in the dust and usually only TCP/IP is loaded now a days, this hasn't been an issue in recent memory. I don't know if the timeout issue would still apply even if they were listed differently or not.
But it's nice to know that even in XP, the order or protocols is still significant. Thanks for posting that.
JimD.
Yes, that's along the lines I was talking about. However what I was referring to was an age old problem (think it may have been back in the A2/ Win 3.11 days) where time outs would occur if the order of protocols was different.
Since NetBeui has been left in the dust and usually only TCP/IP is loaded now a days, this hasn't been an issue in recent memory. I don't know if the timeout issue would still apply even if they were listed differently or not.
But it's nice to know that even in XP, the order or protocols is still significant. Thanks for posting that.
JimD.
>> But it's nice to know that even in XP, the order or protocols is still significant. ....
Well back in our Win98 days, we at one point had IPX/SPX, NetBeui, and TCP/IP on a hubbed network. Our PHB didn't understand why the network was collapsing, and wouldn't give any priority to the Level II techs to go touch the workstations to kill the NetBeui, and eventually the IPX. That was not fun.
Well back in our Win98 days, we at one point had IPX/SPX, NetBeui, and TCP/IP on a hubbed network. Our PHB didn't understand why the network was collapsing, and wouldn't give any priority to the Level II techs to go touch the workstations to kill the NetBeui, and eventually the IPX. That was not fun.
The most important part of the message is the "The Microsoft Jet database engine cannot find the input table or query [Table Name]. Make sure it exists and that its name is spelled correctly".
This indicates that a table or a query has lost (or has none) its connection with the ado-connection.
Now the name of the table that is mentioned in the error is very important.
It is also possible that the table is named as Access reserved names so hence the error.
One of the remedies is to link the table directly to datasource using the table property (build connection).
This indicates that a table or a query has lost (or has none) its connection with the ado-connection.
Now the name of the table that is mentioned in the error is very important.
It is also possible that the table is named as Access reserved names so hence the error.
One of the remedies is to link the table directly to datasource using the table property (build connection).
I've seen this with several of my (non Delphi) applications that use a file server resident MS-Access database. It happens at a user authentication level.
Since the MS-Access database is a file-based system, your users need to maintain a connection to the .MDB file. Normally, your users have a drive letter mapped to a file server share, alternatively mapped with a UNC path. When this connection is made, the user credentials are authenticated with the connection. By default, a lack of activity will cause the credentials to 'timeout' (not the exact term, but an accurate description). When this happens, the connection to the .MDB file is severed. The default interval is roughly 15 minutes.
Note: This timeout also applies when a specific userID/pwd is supplied during drive mapping.
This should be easy to test. Ask your network support person about this timeout interval. Start your application and wait for the timeout period (+1 min).
Check for a disconnected connection.
Since the MS-Access database is a file-based system, your users need to maintain a connection to the .MDB file. Normally, your users have a drive letter mapped to a file server share, alternatively mapped with a UNC path. When this connection is made, the user credentials are authenticated with the connection. By default, a lack of activity will cause the credentials to 'timeout' (not the exact term, but an accurate description). When this happens, the connection to the .MDB file is severed. The default interval is roughly 15 minutes.
Note: This timeout also applies when a specific userID/pwd is supplied during drive mapping.
This should be easy to test. Ask your network support person about this timeout interval. Start your application and wait for the timeout period (+1 min).
Check for a disconnected connection.
i came across this too on our network.
with us it was the firewall. It monitored open connections over every port.
After no activity for 30 min, the connection got severed.
Same errors occured.
Solved it by adding a timer (less than timeout for firewall) to read 1 record from a table setup for this purpose using a query.
This is one of the things that comes with the KeepAlive := True property of the connection
Once opened the connection doesn't provide anything to catch closing errors and reopening it nicely
Sometimes it doesn't even know it's closed.
Happened with printers too.
with us it was the firewall. It monitored open connections over every port.
After no activity for 30 min, the connection got severed.
Same errors occured.
Solved it by adding a timer (less than timeout for firewall) to read 1 record from a table setup for this purpose using a query.
This is one of the things that comes with the KeepAlive := True property of the connection
Once opened the connection doesn't provide anything to catch closing errors and reopening it nicely
Sometimes it doesn't even know it's closed.
Happened with printers too.
In theory, ANY activity across that connection *should* keep the connection active. You don't have to read a record from the database. You might be able to use a FileExists() call to 'ping' the file server FAT
ASKER
Hi All,
Thank you very much for all your comments, you've given me lots of things to check over and try out.
I will start arranging to visit site to test out theories and consult with the customers hardware\network suppliers to look into things.
I will report back afterwards... may take a little while though (a week or so).
In the mean while, any other suggestions\assistance is more than welcome.
Thanks again, check back in a while
- Paul
Thank you very much for all your comments, you've given me lots of things to check over and try out.
I will start arranging to visit site to test out theories and consult with the customers hardware\network suppliers to look into things.
I will report back afterwards... may take a little while though (a week or so).
In the mean while, any other suggestions\assistance is more than welcome.
Thanks again, check back in a while
- Paul
Although the disconnects are a possibility, I think this:
"Also, the error is only being experienced by 6 workstations on the network. The other 3 workstations have NEVER had this error occur."
is a very significant fact. Now it may be that the pattern of usage by these three stations is different from the rest or that it's just a coincidence that they have simply not gotten the error yet, but I would generally think that if timeouts were a problem, they would have seen the errors as well.
Paul is the one to make the call on that though as we don't have enough details to determine that one way or another.
JimD.
"Also, the error is only being experienced by 6 workstations on the network. The other 3 workstations have NEVER had this error occur."
is a very significant fact. Now it may be that the pattern of usage by these three stations is different from the rest or that it's just a coincidence that they have simply not gotten the error yet, but I would generally think that if timeouts were a problem, they would have seen the errors as well.
Paul is the one to make the call on that though as we don't have enough details to determine that one way or another.
JimD.
ASKER
Hi Jim,
Well the usage on the three workstations that are okay is different to the other 6.
The 6 workstations are used by the sales people who put orders on, check stock levels, process enquries etc, so they can tend to jump around alot.
Whereas the three workstations which are okay are used by accounts people who tend not to jump around as much.
This is why I am thinking of trying the machine swap to see if the problem follows a bad machine or stays with the user...
- Paul
Well the usage on the three workstations that are okay is different to the other 6.
The 6 workstations are used by the sales people who put orders on, check stock levels, process enquries etc, so they can tend to jump around alot.
Whereas the three workstations which are okay are used by accounts people who tend not to jump around as much.
This is why I am thinking of trying the machine swap to see if the problem follows a bad machine or stays with the user...
- Paul
Hum well it does sound then like the usage on the 6 is more sporadic, so a timeout could very well be coming into play then. Honestly I've never bumped into any such thing myself, so I'll be very interested to hear if something like that is the cause or not. A spot check of the server logs might be a could idea.
<<This is why I am thinking of trying the machine swap to see if the problem follows a bad machine or stays with the user...>>
yes, I would agree that this is the best approach to start pinning this down.
JimD.
<<This is why I am thinking of trying the machine swap to see if the problem follows a bad machine or stays with the user...>>
yes, I would agree that this is the best approach to start pinning this down.
JimD.
'maximum connections' can also be an issue.
FYI, I just tripped over the MSKB article on mapped drive timeouts in another thread:
Mapped Drive Connection to Network Share May Be Lost
http://support.microsoft.c
JimD.
Mapped Drive Connection to Network Share May Be Lost
http://support.microsoft.c
JimD.
@Jim
Brings a whole new meaning to 'trippy, man' ;-)
Brings a whole new meaning to 'trippy, man' ;-)
'To resolve this behavior, change the default time-out period on the shared network computer.'
Could be,yes...However checking the connection in code would be better ....if not connected then connect...
Better than waiting....
Could be,yes...However checking the connection in code would be better ....if not connected then connect...
Better than waiting....
ASKER
Hi Jim,
Sorry I should have mentioned this in my original post. Originally the application did connect to it's data over a shared drive, but when these errors started happening we switched to UNC instead.
I had also come across the same article, and set both the workstation and server lanman parameters to the max\unlimited timeout setting.
Unfortuantley it didn't seem to make a difference.
- Paul
Sorry I should have mentioned this in my original post. Originally the application did connect to it's data over a shared drive, but when these errors started happening we switched to UNC instead.
I had also come across the same article, and set both the workstation and server lanman parameters to the max\unlimited timeout setting.
Unfortuantley it didn't seem to make a difference.
- Paul
ASKER
Hi All,
I'm going to try and visit site this week so will keep you updated on my progress.
Regards,
- Paul
I'm going to try and visit site this week so will keep you updated on my progress.
Regards,
- Paul
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Thanks for the feedback.
For any anti-virus product, we routinely disable real time scanning of *.mdb and *.ldb files.
/gustav
For any anti-virus product, we routinely disable real time scanning of *.mdb and *.ldb files.
/gustav
Thanks for posting that back. One of those things that I'd routinely suggest turning off when talking about performance, but would have never thought it would have played a role in a situation like this.
Good work on figuring that out! And as aikimark said, make sure you accept your comment as the solution.
JimD.
Good work on figuring that out! And as aikimark said, make sure you accept your comment as the solution.
JimD.
ASKER
Hello,
I can't accept my own answer as the solution.. there is no "Accept as Solution" button underneth it. Could someone offer some guidance please :o)
- Paul
I can't accept my own answer as the solution.. there is no "Accept as Solution" button underneth it. Could someone offer some guidance please :o)
- Paul
ASKER
Just adding some supplementary information
At one of our clients (the previous new site I referred to earlier in the thread), they upgraded their ESET Anti-Virus to Version 4 (they were previously using 3) and their connectivity issues have stopped.
However, at the customer who was experiencing these problems (that this thread was originally about) - they are running v4 on their server and are still getting these issues.
We also have another client who has recently upgraded their network platform is now running on Windows Server Standard 2008 (SP2) 64bit with ESET Mail Security 4 for Microsoft Exchange on the server \ Eset Smart Security 4 on the workstations and our software has started to exhibit the same errors…
So unfortunately, given we have had 4 different clients now experiencing these problems – and the only common thing between them is ESET NOD32 \ Smart Security, we’re coming to the conclusion it’s definitely the culprit.
I now need to get back in touch with Eset and hit them with this so hopefully they can shed some light on why.
Will keep this thread updated with any other info \ updates.
At one of our clients (the previous new site I referred to earlier in the thread), they upgraded their ESET Anti-Virus to Version 4 (they were previously using 3) and their connectivity issues have stopped.
However, at the customer who was experiencing these problems (that this thread was originally about) - they are running v4 on their server and are still getting these issues.
We also have another client who has recently upgraded their network platform is now running on Windows Server Standard 2008 (SP2) 64bit with ESET Mail Security 4 for Microsoft Exchange on the server \ Eset Smart Security 4 on the workstations and our software has started to exhibit the same errors…
So unfortunately, given we have had 4 different clients now experiencing these problems – and the only common thing between them is ESET NOD32 \ Smart Security, we’re coming to the conclusion it’s definitely the culprit.
I now need to get back in touch with Eset and hit them with this so hopefully they can shed some light on why.
Will keep this thread updated with any other info \ updates.
Can't you specify ESET to exclude watching mdb files?
/gustav
/gustav
fwiw,
in the past programs written with delphi have been reported as virusses
unfortunately this is because some virusses were actually written with delphi
always 2 sides to a medal
probably why the NOD noted your programs as possible virusses
in the past programs written with delphi have been reported as virusses
unfortunately this is because some virusses were actually written with delphi
always 2 sides to a medal
probably why the NOD noted your programs as possible virusses
ASKER
Hi cactus_data,
We have tried excluding our program exes and the database to no avail.
Eset have been in touch, their reply is below:
So I've set up Process Monitor on one of the workstations at the customer and set it to log all activity to a log file on the HDD - just waiting till the error happens again now.
- Paul
We have tried excluding our program exes and the database to no avail.
Eset have been in touch, their reply is below:
Download and run the Microsoft Sysinterals Process Monitor application.
http://technet.microsoft.com/en-us/s ysinternal s/bb896645
Filter the output to show only ekrn.exe processes, this will show you
what exactly Eset is scanning, this should then allow you to see if
there is a file other than the database which is constantly being
scanned which could be affecting your software. Exclude these files or
locations.
Also try excluding the application as well as the database to see if
that helps.
So I've set up Process Monitor on one of the workstations at the customer and set it to log all activity to a log file on the HDD - just waiting till the error happens again now.
- Paul
ASKER
Hi All,
A quick update on the situation.
1. The Jet Engine problem has now spread to other sites - including sites where there is no trace of ESET software, so our theroy on ESET being the culprit appears to be blown out of the water.
2. We discovered it started happening on a site about a year ago (they never mentioned it as they didn't think it was our sofware at fault). This paticular site hasn't had a software upgrade\update for over 2 years... so our software hadn't changed at all - so something in the environment must be the cause.
3. A new potential lead - At the very first site this problem was encountered atl, I mentioned 3 of the workstations had never experienced the problem. Today one of those 3 has experienced a Jet Engine Error... following the installation of IE 8 onto the machine. IE 8 also caused some problems with some banking software - the bank said "IE8 changes some of the system settings which has an effect on our software...".
Will keep this thread updated with any new findings we have.
- Paul
A quick update on the situation.
1. The Jet Engine problem has now spread to other sites - including sites where there is no trace of ESET software, so our theroy on ESET being the culprit appears to be blown out of the water.
2. We discovered it started happening on a site about a year ago (they never mentioned it as they didn't think it was our sofware at fault). This paticular site hasn't had a software upgrade\update for over 2 years... so our software hadn't changed at all - so something in the environment must be the cause.
3. A new potential lead - At the very first site this problem was encountered atl, I mentioned 3 of the workstations had never experienced the problem. Today one of those 3 has experienced a Jet Engine Error... following the installation of IE 8 onto the machine. IE 8 also caused some problems with some banking software - the bank said "IE8 changes some of the system settings which has an effect on our software...".
Will keep this thread updated with any new findings we have.
- Paul
Paul,
Thanks for posting back.
JimD.
Thanks for posting back.
JimD.
Before you receive a bunch of advice on "upgrade to SQL Server" and similar, I can think of one area for you to investigate: you mention the three workstations have not experienced this error. This could indicate that the issue is somehow related to some configuration or the like of the remaining workstations. Thus, I would look for any difference between the two groups of workstations.
/gustav