User profile for datacentricity

RedGateDatabaseInfo.xml corruption

We use SQL Source Control to manage static data in TFS - as expected this adds the affected tables to RedGateDatabaseInfo.xml. However, it seems that SQL Compare 12 overwrites this file removing th...

1 follower 1 comment 0 votes

Eddie, Thank you for this. I have downloaded and installed the updated version. I will keep it open in SSMS for the next few days and then report back on whether this solves any of the issues. Regards / comments

Eddie, Thank you for this. I have downloaded and installed the updated version. I will keep it open in SSMS for the next few days and then report back on whether this solves any of the issues. Re...

0 votes

I will take a look at the event log but should also note that when ever we see the out of memory exception, the amount of memory being utilised by SSMS is usually no more that 500MB and I have never seen it higher than 840MB / comments

I will take a look at the event log but should also note that when ever we see the out of memory exception, the amount of memory being utilised by SSMS is usually no more that 500MB and I have neve...

0 votes

Thanks for the quick response and I understand the reason behind this behaviour. However, having the TFS (or other repo) revision/changset number recorded in the database can be a really useful overall indicator of what version of the code has already been deployed to the target database. I know that it is not an absolute indicator but it can be very helpful. Can I ask that this feature be retained (even if it is an optional setting in SQL Compare) as I'm sure we are not the only team to find this extended property useful. Many thanks, / comments

Thanks for the quick response and I understand the reason behind this behaviour. However, having the TFS (or other repo) revision/changset number recorded in the database can be a really useful ove...

0 votes

SQLSourceControl Database Revision not set with v5 migration

We are running SQL Compare v11.6.3.1926 and I have noticed that if the resulting deployment script includes one or more v5 migrations then the block of code that sets the extended property for "SQL...

2 followers 2 comments 0 votes

SQL Test Performance (out of memory exception)

Is there a practical limit to the number of tests supported by the SQL Test UI? It has always been somewhat slow but as the number of tests across our platform have increased it has reached the poi...

2 followers 4 comments 0 votes

I've been experiencing the same issue, our setup is as follows: SQL Source Control 5.1.1.2694 SQL Compare 11.6.3.1926 TFS 2015 source control We have just moved over to SOC v5 and on the first attempt to deploy changes (including three new v5-style migration scripts DDL - DML - DDL), SQL Compare did not find any migration scripts and, more to the point, the resulting deployment scripts did NOT include them either. These were the things I checked/tried: 1) Check that the value for "SQLSourceControl Database Revision" in the target database was less than the earliest change set number of any expected migration script 2) Check that the value for "SQLSourceControl Scripts Location" was pointing to the correct URL for our TFS repo 3) Check that there was no extended property called "SQLSourceControl Migration Scripts Location" 4) Reconnected SQL Compare to the correct source folder location in TFS This was the first time that we had tried deploying changes with the new v5 migrations so [RedGateLocal].[DeploymentMetadata] did not yet exist in the target database. All to no avail - still no migration scripts. Possible Fix: Finally, I found the behaviour option "Ignore migration scripts for databases", This was unchecked. On a "running out of ideas, pulling my hair out" hunch I tried checking this option, saving the project closing and re-opening SQL Compare then unchecking that option again. It may have been simple coincidence rather than my hunch but the next time I tried building a deployment script, the expected migration scripts were included in the final script (although still not visible in the pre-deploy steps). I think that the change to SOC v5 migrations is a really good thing but I am really disappointed to discover that I have to dig around in a forum to discover that SQL Compare will (eventually) include those new-style migration scripts even though it tells me there are none. I accept that SQL Compare may not yet be able to list the individual migrations or the objects they affect (the way it did for v1) but it should still indicate to the user that such scripts will still be included in the final deployment script. As it is right now, when building a deployment script, in the Deploy dialog, in the list of steps we see ""2. Review Migration Scripts > No migration scripts". This is really misleading and I have come to expect better from Red-Gate. When will support for SOC v5 migrations be fully implemented for SQL Compare and in the meantime can we have a frequent updates release that at least highlights the fact that migrations are not listed but will be included in the final script? Many thanks for an otherwise great product range. / comments

I've been experiencing the same issue, our setup is as follows: SQL Source Control 5.1.1.2694 SQL Compare 11.6.3.1926 TFS 2015 source control We have just moved over to SOC v5 and on the first atte...

0 votes

Thanks for the response: Interestingly, my machine on which SP3 is installed has the following DLL versions including the one that has a problem but does not exhibit this error: Microsoft.SqlServer.Types Version: 10.0.0.0 File version: 2009.100.2500.0 Product Version: 10.50.2500.0 Microsoft.SqlServer.Types Version: 11.0.0.0 File version: 2011.110.6020.0 Product Version: 11.0.6020.0 Microsoft.SqlServer.Types Version: 12.0.0.0 File version: 2014.120.2000.8 Product Version: 12.0.2000.8 More weirdness... Both the colleagues who have this error were not actually able to install SP3 (obviously not a Red-Gate issue) - when they tried they just got "this product has nothing to update" or some such message. So either some of the DLLs were still deployed during that process, or something else deployed them previously (VS2012 or SSDT/BI updates perhaps?) leading the SP3 installer to believe that SP3 was already present. My colleagues eventually resolved their problem by rolling back to an earlier service pack so thank you for your help. This is clearly nothing to do with RedGate. Looks like we'll stick with SP2 for now. / comments

Thanks for the response: Interestingly, my machine on which SP3 is installed has the following DLL versions including the one that has a problem but does not exhibit this error: Microsoft.SqlServer...

0 votes

.Net Framework "geography" error on get latest/commit

Two out of three developers on my team are experiencing the following error when attempting a get latest or /(identify changes to) commit. A .NET Framework error occurred during execution of user-d...

2 followers 3 comments 0 votes

FWIW, I have been encountering a lot of this error recently. I have a suspecian (but haven't proved it) that this may be caused when I use Visual Studio's TFS Explorer to move large numbers of sql scripts between folders (actually tSQLt unit test which we store in a separate folder structure with the main source folder). Anyway, after reading this post, I identified the working base location then in TFS Explorer used the Workspace drop down to switch the to working base location. When I did a get latest, I noted a shed load of changes so obviously the weoking base hadn't been updated properly by SSC. Then when I tried to commit again, I got a write lock failure but after closing TFS Explorer and restarting SSMS it worked OK. So for the guys at RedGate this seems to be a bug with how SSC interacts with TFS (at least in my case). Specifically, when I use SSC to commit new changes including tSQLt tests, the test procedures end up in the $/Source/Stored Procedures/ folder which with over 1000 tests just gets in the way of the production sprocs. So I then use TFS explorer to move those to a different folder $/Source/Tests/Unit Tests/ and commit my changes. I think the problem occurs because although the folder path for some sprocs has changed, there are no material changes to the DB so get latest produces no changes (as you would expect). However the next time I try and commit I'm seeing the "the list of changes to commit was out of date" error / comments

FWIW, I have been encountering a lot of this error recently. I have a suspecian (but haven't proved it) that this may be caused when I use Visual Studio's TFS Explorer to move large numbers of sql...

0 votes

How can we help you today?

datacentricity

Activity overview