3.1.0.5208 (and greater) Logging and Database Connections..

sillv0r

I'm using the dedicated model and it appears that 3.1.0.5208 (and greater) takes on the order of hours to complete an initial link. The database is large, but version 3.1.0.4829 would complete the initial link within the hour if not before 30 minutes.

[Logging]
One thing I've been able to notice different is 3.1.0.5208 logs the entire contents of every database object full details of stored procedures, views, tables, etc. and is only able to complete a single object in just over a second. While, 3.1.0.4829 merely logs the name of the database objects and can chew through several objects within the same second.

[Database Connections]
One other behavior difference I've noticed is that 3.1.0.4829 appears to hold onto a database connection and reuse it. While 3.1.0.5208 and greater (so far) appears to chew through database connections. Looking at Resource Monitor I see SSMS.exe chewing through source ports while the initial link is going on.

Any ideas? I'm staying on 3.1.0.4829 for now.

Regards.

Brian Donahue

You have already got a support call open with Red Gate via email, reference number F0069027.

Personally I can't say what the problem is. I don't know what you mean by "chewing connections", though. SQL Source Control I believe is like other Red Gate SQL Tools in that it uses the default settings of the .NET ADO client and therefore will pull connections out of a pool and re-use them, thus saving it the expense of always having to make a fresh connection for every operation. My opinion is you're probably barking up the wrong tree, reverse-engineering wise.

HoofHearted

Brian,
I believe you owe sillv0r an apology. I just downloaded the update made available today and looked in the release notes and found the following:
"Drastically reduced the number of connections made to the SQL Server instance hosting a linked database. This also reduces the number of queries against those databases"

Not only did you dismiss a customer's valid complaint ("barking up the wrong tree", indeed!!), but Red Gate has listed this as a feature instead of a bug fix.

What a slap in the face!! Nice customer service.

Brian Donahue

I did not answer this post comprehensively because this customer already had a support call open with us via email and he has been notified.

Sorry you're dissatisfied.

Chris George

HoofHearted wrote:

Brian,
I believe you owe sillv0r an apology. I just downloaded the update made available today and looked in the release notes and found the following:
"Drastically reduced the number of connections made to the SQL Server instance hosting a linked database. This also reduces the number of queries against those databases"

Not only did you dismiss a customer's valid complaint ("barking up the wrong tree", indeed!!), but Red Gate has listed this as a feature instead of a bug fix.

What a slap in the face!! Nice customer service.

Hi there,

I work on the SQL Source Control project, and I would like to apologise for any misunderstanding surrounding the release notes for the recent update.

Listing the connections issue under Features was an error on our part, and is something I have now corrected.

We hope that you find the new release to be a bit faster than the previous few, and look forward to hearing more feedback from you.

Regards
Chris

sillv0r

Just a follow up.

SQL Source Control release 3.1.4.72 resolved my issues.

You have already got a support call open with Red Gate via email, reference number F0069027.

The only reason I posted in the forums was I had not heard any updates on said support ticket in over a week.

My opinion is you're probably barking up the wrong tree, reverse-engineering wise.

I do not believe that watching Resource Monitor is considered reverse engineering.

Thanks.

Chris George

Hi sillv0r

It's great to hear that the latest release has solved your issue!

Kind Regards

Chris