FogBugz Technical Support

A forum for technical support discussion related to Fogbugz.
The current FogBugz Knowledge Base can be found at

Posts by Fog Creek Employees are marked:

Release Notes
Network Status

Sql Server setup

Hi, I was trying to create some reports against our FogBugz database (Sql Server) and I noticed that when it was setup the owner of the table structure was the Windows account it was created with rather than dbo.  Everything runs fine from the FogBugz client side but when I run queries from Query Analyzer against the database, I run into problems even when fully qualifying the name.  My question is if I change these tables to dbo ownership should I expect any problems on the FogBugz client side?  (From other posts I've seen out here on the board it appears that the standard installation does use dbo for setup; is that correct?)
d. hendricks Send private email
Thursday, January 26, 2006
You can change the owner to dbo.  That will work fine...
Michael H. Pryor Send private email
Thursday, January 26, 2006
sp_changeobjectowner 'FogBugz.tablename', 'dbo'
Michael H. Pryor Send private email
Thursday, January 26, 2006
This is the top issue that I get asked about with regards to connecting CaseDetective for FogBugz to a SQL Server database.

A generous person called "bmschkerke" wrote a nice post to the CaseDetective forums about how to automate the changing of the table owner to dbo for the entire database. The post at includes links to the original source of the script.

Here's the link and script:

SELECT 'EXEC(''sp_changeobjectowner @objname = '''''+
  ltrim( + '.' + ltrim( + ''''''
  + ', @newowner = dbo'')'
FROM  sysobjects s,
      sysusers u
WHERE s.uid = u.uid
AND <> 'dbo'
AND  xtype in ('V', 'P', 'U')
order by

It's a single sql command that generates an EXEC command for each object in the database that needs changing.

I just ran it in SQL Query Analyzer on one of my test FogBugz databases that had a couple of tables not owned by dbo and it worked fine.

I copied the results back up into the SQL editor and ran them (after checking them over), when I flipped back to Enterprise Manager and refreshed the table list, both tables had been updated correctly.

I'm sure it goes without saying (but I'm going to) that you should test this script and it's results on a non-production copy before running for real, it worked for me but that's no guarantee it'll work for you.
Ian M. Jones (CaseDetective) Send private email
Friday, January 27, 2006
The tables should really be owned by dbo.  Somehow this got lost on some upgrade code, but I'm going to fix it for the next release.
Michael H. Pryor Send private email
Friday, January 27, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz Bug Tracking and Evidence-Based Scheduling.