Exception throw by db reader

raoulteeuwen

Hi. Just installed the RedGate tool set and trying to get it to work. I'm trying to compare 2 databases (1 on a 2000 server, 1 on a 2005-server). I'v connected to the 2 servers where the databases reside, picked a few tables (to test the tools), configured the key fields in each table (wish there was an easier option for that: do i really need to tell Data Compare for each table what the key field(s) is (are)?).

When i press compare, i get a green tag next to Registering databases and Mapping, but when at 'Comparing databases', i get "Exception throw by db reader 2".

I've searched for the error, but could not find any other related message on the forum. Found http://www.red-gate.com/supportcenter/C ... wledgebase\SQL_Data_Compare\KB200903000364.htm . I'm using version 7. But i am simply selecting tables to compare. I'm not adding where-clauses.

Any ideas? Am i doing something wrong?

Thanks!

raoulteeuwen

The user i was using to connect to 1 of the machines, had (only) Public as rol on the database. I've just added Data Reader, and it now seems to do the compare (slow, but that will probably be our infra ;-)).

Leaves me one question for now: is there no simpler way to have Data Compare understand what keys it can use :-)? (apparantly it is not specified on SQL-table-level, so the RedGate tool can't use that info) No way it can autodetect/propose the key from sampling the table :-)?

Chris Auckland

Thanks for your post.

I'm glad you managed to figure out the 'error in db reader' was permission related. We understand that in this situation the error returned isn't particularly helpful in troubleshooting the problem, so we will be returning a better error message in future. Hopefully in SQL Data Compare 8.0 (I haven't checked).

SQL Data compare needs the same minimum permissions as SQL Compare needs to interrogate the schema. You can find out those details here:

With regards to the comparison keys, SQL Data Compare can only automatically set them if the table has a Primary key, unique index or unique constraint. Otherwise it doesn't know what to use as the comparison key. We don't think it would be right to guess at the next best key as this could probably cause some strange results. We prefer to leave these objects 'not set' and then the user can decide on the best key to match on.

I hope this helps.