dbo.GPS_CHAR cannot be dropped because it is bound to one or more columns

Came up against this problem when upgrading a customers existing Dynamics GP 10 to GP2010. First I had to apply Service Pack 5 against the existing GP10 install. Easy peasy running Utilities for 49 company databases – but Utilities failed when updating one company. Created a DexSql.log and re-ran utilities against that one company again until it failed - the following error was recorded in the DexSql.log –  ‘dbo.GPS_CHAR’ cannot be dropped because it is bound to one or more columns.

In this case the issue was to do with the Company Database version numbers. I compared the ‘Bad’ company database to a ‘Good’ company database in the DB_Upgrade table on DYNAMICS. Simply ran the following SQL Query:

SELECT * FROM DB_Upgrade WHERE PRODID = ’0′ and DB_NAME = ‘BAD COMPANY’
SELECT * FROM DB_Upgrade WHERE PRODID = ’0′ and DB_NAME = ‘GOOD COMPANY’

What I found was this: The db_verOldMajor and db_verOldBuild fields for the Bad Company were set to ’0′ (Zero). I set these to be ’10′ and ’903′ respectively (as you would expect for a database that was still on service pack 1).

UPDATE DB_Upgrade SET db_verOldMajor = ’10′ WHERE PRODID = ’0′ and DB_NAME = ‘BAD COMPANY’
UPDATE DB_Upgrade SET db_verOldBuild = ’903′  WHERE PRODID = ’0′ and DB_NAME = ‘BAD COMPANY’
Ran Utilities again, and selected to update the Bad Database – Update ran to completion, and I was then able to upgrade all databases to GP2010 SP1.

I’ve no idea what caused this. I was called in to clean up the GP Implementation and get the databases on to GP2010 (No…we didn’t do any of the original work!). There were lots of other issues with the install, like being on MSSQL 2008 RTM with just GP 10 SP1 installed – (anyone needs help with that one – give me a call) – so I suspect that there was some ‘manual’ intervention at some stage when previous upgrades / transfers to new servers etc. didn’t go to plan.

As always, the above is what I did to get around a problem that I couldn’t sort any other way. If you come across the same issue, remember – Backup, Backup and Backup again..and test till you’re blue in the face before you do this in production.