DB Audit client High CPU 4.0

We installed your 4.0 DBAudit product. I created a new repository db and new definitions. I did this on mulitple clients pointing to local and network SQL Servers. After a trigger is created the application goes high CPU. The triggers and definitons are created. When you come back on and re-log in the table is not recognized as having triggers created for it. Please advise...

Patrick

Weird... By application going high CPU, which application do you mean? DB Audit or your business application?
If you have system auditing also enabled, can you see in the system audit reports/logs what the application is doing?

Anything turning up in the data-change audit-trail?

Are you using any audit-time filters? If yes, which filters?

Which version of SQL Server? Which version/build of DB Audit (see Help/About box)?

I am still looking for some resolution for this. I don't know if you want me to download your latest version from the web site or if you have the ability to test what CD was shipped to us.

Please answer questions asked in the previous post

My mistake....the DB Audit client is going high CPU. System Auditing is not enabled. I will see if the audting actually would work for updates but I can tell you that DBAudit does not recognize the prevously defiened tables. We are using SQL Server 2005 and 4.015 of DB Audit. I tried to download your latest version from the site, but I received HTTP errors trying to do the download.

This should be a lot easier to troubleshoot. My first guess, you have selected some bad driver for the connection.

Let's start here.
1. If you have SQL 2000 client installed, switch to MSS driver - this is most reliable. If you don't have it and you picked OLE/ADO switch to ODBC. OLE/ADO is the worst choice and should be used if no other methods are available.

2. If the above doesn't help, check if in DB Audit directory you got db_audit.err file. If yes, take a look what kind of errors are reported in that file. If errors are database based, than driver is likely cause. If not, email the entire file to the support email (see Help/About box for details)

3. If none of the above, please let us know too. I will provide instructions on how to turn on and use tracing options to troubleshoot this issue.

By the way, the most recent version is 4.0.17. It can be downloaded and installed on top of the existing installation; this takes only a few seconds to do.

I tried all of your drivers and nothing worked. With your 3.21 verison, the ADO driver method did work. I do not see a .err file in your program folder. What is the next way to proceed? Thanks...

To the best of my knowledge there are no differences for ADO driver usage between versions 3.2 and 4.0. What could happen is that you could have some Microsoft MDAC/ADO/NET update installed or let the system installed it automatically that affected the behavior.

But before we talk about that, let's find out what is going on. In the driver field on the Connect to Database dialog insert word TRACE in the beginning, for example for ODBC, it should look like TRACE ODBC, for OLE/ADO it should look like TRACE OLE. Connect to the database and install the auditing on one or 2 tables. Please send the resulting pbtrace.log file to our support account

Trace Sent.........

Thank you.

I downloaded the latest version and problem fixed.....

Great. Thanks for the status update.