How can we help you today? How can we help you today?
Andras B
Tim@NextMedium wrote: Greetings - We're using Red Gate SQL Data Compare 5 to compare data on two databases. Both servers sit in different network locations and subnets - therefore it's taking a while to compare them with each other. I do get the following error when using /v (verbose mode): Red Gate SQL Data Compare Command Line Utility V5.3.0.81 ============================================================================== Copyright c Red Gate Software Ltd 2004-2006 Serial Number:505-001-056087-E889 Loading synchronization parameters from project file: Masterdata_Login_BigBang.sdc <snapshot file - works when I open it with Sql.data.compare.gui OK Comparing database Database1(redacted) with database Database2(redacted)... Registering databases Error: Comparison of Database1(redacted) and Database2(redacted): Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. Can you shed some light, please? Many thanks, Tim Hi Tim, Is this happening consistently? Can you reproduce it in SQL Compare (not Data Compare) UI, and can you compare the two schemata? Also, is this related to particular databases/servers? Are there any unusual things about these databases, like running on a fixed custom port, being behind a firewall, ... If it is consistent, could you check the query that is being executed on the database too? Regards, Andras / comments
Tim@NextMedium wrote: Greetings - We're using Red Gate SQL Data Compare 5 to compare data on two databases. Both servers sit in different network locations and subnets - therefore it's taking a...
0 votes
Oleg wrote: Hi Andras, I'd like to add: SQL compare 5 is working good in my case but SQLCompare 6 is not. Are useful catched queries? Regards, Oleg. Oleg, I'll send you a patched version in a few days. Regards, Andras / comments
Oleg wrote: Hi Andras, I'd like to add: SQL compare 5 is working good in my case but SQLCompare 6 is not. Are useful catched queries? Regards, Oleg. Oleg, I'll send you a patched version in a ...
0 votes
Oleg wrote: I compare 2 the same databases. SQL Compare 6 1. Using Windows Auth. for both db SQL Compare aborting, Registering databases SQL-SRV1.db87-Reading constraints, Unable to cast object of type 'System.DBNull' to type 'System.String' 2. Using SQL Server auth. for both db, user sa (!) SQL Compare aborting, Registering databases SQL-SRV1.db87-Reading object text, Object reference not set to an instance of an object. SQL Compare 5 1. Using Windows Auth. for both db SQL Compare aborting, Registering databases SQL-SRV1.db87-Reading constraints, Specified cast is not valid. 2. Using SQL Server auth. for both db, user sa (!) All ok, dbs compared successfully. (!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!) Note. Windows user is not an admin on the sql server machine. Regards, Oleg. Hi Oleg, there is a bug in SQL Server that does not allow non dbowners to explore the full schema. (not even datareader) This is especially a problem with UDTs. One can see this if he executes the SQL Statement on which SQL Compare falls over using both of the users (the admin and nonadmin). The result will be different [image] , very likely an important schema information, like a UDT owner, is returned as null due to the lack of permissions. If you could send this info to me (what object, maybe what column is null) I'll try to find an alternative way to retrieve the schema. Regards, Andras / comments
Oleg wrote: I compare 2 the same databases. SQL Compare 6 1. Using Windows Auth. for both db SQL Compare aborting, Registering databases SQL-SRV1.db87-Reading constraints, Unable to cast object ...
0 votes
rdobrich wrote: Hi, I just run into very strange problem. I have two stored that have two empty lines at the end on destination server. I have only one empty line on production server. In sync script I don't have empty row, but in newly created stored I have one row. That ever I try I get one extra line on destination server. (but just for that two stored). Of cousse, when I check ignore white space, the stored are the same in SQL compare (but the one on destination have one empty line). Can't reproduce error on other stored procedures, only on some. Is I can see the sql compare script are fine (have exactly empty rows), but SQL server 2005 Apply one more (on some very long ~600 lines) stores. I think this is SQL server problem, but just point here at the problem . (end of sync script loos fine, after applying script have one extra line) ... return 0 error_spG_IzlazQueryArtikl: exec sp_xml_removedocument @hDoc Select '<errors><error code="'+cast(@nErr as varchar(10)) + '" description="' + @sError + '" /></errors>' RAISERROR ('Greska u sp %s ! Razlog: %s ' , 16, 1,'error_spG_IzlazQueryArtikl',@sError) return 1 GO You are right, and SQL Server does have an inconsistent whitespace handling at the ends of some textual objects. This behavior also seems to differ on SQL Server 2000 and SQL Server 2005. At the moment the only workaround is to use the ignore whitespace option. Regards, Andras / comments
rdobrich wrote: Hi, I just run into very strange problem. I have two stored that have two empty lines at the end on destination server. I have only one empty line on production server. In sync s...
0 votes
rgribble wrote: When dealing with a large number of projects, it can always be an issue to make sure that they all have the correct options set. I have a standard set of options that all projects should use, and i have a standard empty project (called --DEFAULT--) with these options set, purely for the purposes of "cloning" when i want a new project. It would be great if there was a) a way to set the application default settings, that when a new project is created it should have these options set. b) a column in the project list which could indicate whether each project has the default options, or whether they are different. b) would be especially useful for me, as it means i could easily identify that one saved project that i had set "ignore permissions" or "ignore FILLFACTORS" on temporarily, and forgotten to set them back to how i normally want them. At the moment i have to check each projects options manually before running a compare, just to make sure that they are how they should be. A "Default Options" column in the project selection list with a tick/cross or some such indicator to tell me whether it has the default options or not would be great! I think a high percentage of users are probably dealing with more than one database, and would often be using the same default set of options on most projects. I think both of these suggestions would save time and increase usability! We are including saving "default" defaults in the final release. As you mention, many customers have asked for this, we just could not squeeze this feature into the beta. We will have a look at b) and b2) as well. Many thanks, Andras / comments
rgribble wrote: When dealing with a large number of projects, it can always be an issue to make sure that they all have the correct options set. I have a standard set of options that all projec...
0 votes