![SoftTree Technologies](templates/GreenTech/images/logo.gif) |
SoftTree Technologies
Technical Support Forums
|
|
Author |
Message |
rnewburn
Joined: 02 Jun 2007 Posts: 3
|
|
Sql Server and respository |
|
We had to uninstall the db audit package from SqlServer to perform for database upgrades (the db_audit tables were causing the upgrade script to fail). We tried to remove the triggers first, but to no avail. We un-installed the package and dropped the offending tables.
When we went to re-install it, it now asks for a repository but indicates we must have the alert center loaded to proceed. We didn't before. So why now?
Also, just before this notice is shown, a message dialog displays that there are two (or three at one time) installs on the machine. After the uninstall, I removed all registry, schema and user object related to db_audit. This cleared the error message but still indicates the need for a repository.
Sox auditors due in soon.. HELP!
Thanks in advance.
|
|
Sat Jun 02, 2007 11:33 am |
|
![](templates/GreenTech/images/spacer.gif) |
SysOp
Site Admin
Joined: 26 Nov 2006 Posts: 7849
|
|
|
|
I'm having hard time understanding what you are doing. When you install the auditing in SQL Server, it should prompt you to select a database where to store the local audit trail tables. Let's call it a local repository database. That's fine. Just pick a database where you had them before.
Hope you are not confusing local repository database with a central repository server, which is not the same thing.
If you still have difficulties, please post the complete message or attach a screenshot demonstration the issue to help us understand what you are doing and what you are getting.
|
|
Sat Jun 02, 2007 12:01 pm |
|
![](templates/GreenTech/images/spacer.gif) |
rnewburn
Joined: 02 Jun 2007 Posts: 3
|
|
|
|
Thanks for the response! When we did the upgrade, the db_audit tables were wiped - and its underlying schema. When the software is re-installed, that schema is not being re-created. I have attached some screen shots to clarify. I could likely re-create the schema myself however, I would fully expect that the auditing software should do it on its own. Let me know what else I need to do.
Thanks.
![](http://upload8.postimage.org/639161/unresolved.jpg)
|
|
Sat Jun 02, 2007 3:58 pm |
|
![](templates/GreenTech/images/spacer.gif) |
SysOp
Site Admin
Joined: 26 Nov 2006 Posts: 7849
|
|
|
|
Thanks for the detailed description. It is now clear what is going on.
Well, I see several problems there.
1. You broke the DB Audit setup without correct uninstall and now you expect it somehow to recover. The solution: uninstall everything that's named "db_audit" including the login. You can still use Tools\Uninstall repository menu to let DB Audit to clean it all for you.
2. You have a system wide problem - system stored procedure sp_helpdb returns no results - I suspect some databases have missing db_owner settings as a result of upgrade or incomplete restore from a backup from a different server. The solution: fix database owners and ensure sp_helpdb returns valid results, you can try running it in SQL Analyzer as "exec sp_helpdb" without parameters.
3. Registry is not cleaned completely - the list of databases is not available, yet somehow you get to the point where it lets you pull the tables for auditing. Perhaps fixing problem #2 can resolve this issue too.
4. This is not an issue, but... For the installation, if you use the system auditing you should logon to the database using Trusted Connection option, for which you should pick "MSS Microsoft SQL Server" driver or "OLE Microsoft SQL Server Driver" which support this option (I personally recommend the first option as more reliable). Non trusted connections can be used after the installation to run reports.
Hope this tips will help you to get going. If anything else turns up wrong, please let us know.
|
|
Sat Jun 02, 2007 5:48 pm |
|
![](templates/GreenTech/images/spacer.gif) |
rnewburn
Joined: 02 Jun 2007 Posts: 3
|
|
|
|
I ressigned the database owners and that took care of the issue.
From the start the uninstall process was followed (tools\uninstalll) in addition to the software itself being uninstalled through the MSI package. However, not before that the vendor scripts for the underlying database had been run. I suspect (in retrospect) that some of the tables used in the audit no longer existed or their column datatypes had been changed. I just didn't connect the two at the time. (and the upgrade script errors implied as much too)
On item #3, the databases would enum and show the tables, etc. because the ODBC connection was fine. Only when the routine to populate the database list for selection showed the problem - which was the database owner issue you pointed out.
All is well once again! Thanks for your help.
|
|
Sun Jun 03, 2007 6:23 pm |
|
![](templates/GreenTech/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|