Object Reference not set to an instance of an Object
Brian Donahue
Posts: 6,590 Bronze 1
Hello Hambledon,
This doesn't seem right -- SQL Compare should completely ignore Extended Properties applied to system tables. I even double-checked by adding a column comment to dtproperties and running SQL Compare against the database and it didn't appear in the migration SQL.
Is it possible that somehow, your dtproperties had got changed from a System-type table to a User-type table?
This doesn't seem right -- SQL Compare should completely ignore Extended Properties applied to system tables. I even double-checked by adding a column comment to dtproperties and running SQL Compare against the database and it didn't appear in the migration SQL.
Is it possible that somehow, your dtproperties had got changed from a System-type table to a User-type table?
This discussion has been closed.
Comments
Can you check the xtype of the object in the sysobjects table? It should be S for system.
This is another way to identify a system object as well as using OBJECTPROPERTY.
Regards
Dan
Red Gate Software Ltd
You're right: dtproperties has a designation of U for some reason. Maybe because this table contains database diagram information. I'd guess that SQL Compare would filter this table by name only.
Is the owner of the table still [dbo], or perhaps the ownership has changed, causing SQL Compare to pick up on the table anyway?
I'll give it a try and see what happens!
I think we know what the problem is now! I can add an extended property to any trigger in any table in my database except for dtproperties.
This is what's happening:
SQL Compare detects all of the extended properties in the database. Then it tries to link the EP to a database object so that it will appear as part of SQL Compare's internal representation of the table.
As you've pointed out, the way to filter out all system tables is by excluding all of the ones with an xtype of 'S' AND dtproperties (by name).
So when SQL Compare tries to resolve the extended property to a table -- it can't -- because SQL Compare had not registered the dtproperties table!
That explains the null-reference error.
Now, we have to figure out how to drop the extended property. SQL Compare will not provide the information because it errors out. We'll need to query sysobjects to find it.
Result:
EP Trigger
MS_Description trgdtproperties
This will tell you what arguments to supply to sp_dropextendedproperty to drop the extended property:
I hope this helps!
This error message is a very generic error. Most errors are 'trapped' by the software and return a 'user-friendly' error message.
Noll-reference exceptions like this one usually indicate a database problem due to a database inconsistency.
For instance, IDENTITY columns that have a SEED or INCREMENT value of NULL will cause this error, because these values should never, ever be NULL, or your database will be in really bad shape.
Likewise, with the above, SQL Compare filters out the system tables, so any attempt to resolve an extended property to a system table will result in an error. We'll trap and fix this condition in a future release, but as a rule, people shouldn't be making modifications to MS-Shipped tables!
If you'd provide us with some more information, such as exactly where the error occurs (during database registration, comparing databases, etc), then we can try to figure out where the problem lies.
I have two snapshot for the databases that I can't compare.
I get error after registrate the databases, during the comparation.
My version if SQLCompare is 3.1.9.4
(with trial version everithing works fine).
Please send me an e_mail so I can send you snapshot of that databases.
Radovan
You might try running SQL Profiler against the server while running Red-Gate. That will give you the last query that ran before the wreck, and that is how I found out that it was an extended property issue.
It appears that SQL Compare doesn't compare extended properties on View Columns - is that correct?
Thanks!
SQL Compare does not properly script extended properties on a view, a problem which will be fixed in a future version.
This will not cause the software to throw a NULL reference exception, however.
One of your user-defined functions has no text (DDL) associated with it. The function may work in the database because it's been compiled, but SQL Compare looks at the database's syscomments table to find the DDL, and since it found nothing in syscomments for that function, SQL Compare throws a null-reference error.
Today I update new version (3.1.9.12) and works fine.
Glad that snepshot helps
Radovan
I've read the thread but nothing seems to solve the error on my database.
I get this error while trying to compare a specific database to a snapshot or to another database. Trying to compare a snapshow of the database results to the same error.
I'm using SQLCompare 3.1.9.12
Is there a way to see where the error occurs in SQLCompare?
I'm currently stuck and can not make a release!
Please hurry.
A database with a table function and a non-english comment in it will raise the error, making SQLCompare fail to compare it with any other database or image.
Example - The following function created to an empty database will fail SQLCompare:
Same function exactly with english remark works fine!
This happens with the latest version 3.1.9.12 and did not in earlier versions! :evil:
Following is the callstack when simply trying to display the changes on this function:
I need a quick fix - my release is delayed because I was stupid to update SQLCompare before it.
Red-Gate people - please respond.
Thank you.
There is a new issue that has been highlighted by the new version.
I will email you directly, or can you send me further information to support(at)red-gate.com .
Regards
Dan
Red Gate Software Ltd
If you have any problems with the update, feel free to write support -at- red-gate.com.