Comments
Sort by recent activity
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...
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...
On XP, you'll find theme here:
C:\Documents and Settings\<loginName>\Local Settings\Application Data\Red Gate\SQL Source Control 3\WorkingBases
The WC folder names bear no relation to the project names but you can map them from here:
C:\Documents and Settings\<loginName>\Local Settings\Application Data\Red Gate\SQL Source Control 3\LinkedDatabases.xml
There may be a better approach than this.
I have considered re-pointing the paths in LinkedDatabases.xml to a regular working copy and although that does work, I do not know what the impact would be if changes were made in that WC as well as the dev database itself. / comments
On XP, you'll find theme here:
C:\Documents and Settings\<loginName>\Local Settings\Application Data\Red Gate\SQL Source Control 3\WorkingBases
The WC folder names bear no relation to the project n...
kenbroz wrote:
why has been answered, I would like to know the answer because it has a similar problem.
The latest version of tSQLt (the framework that underpins RedGate's SQL Test) now has an ApplyTrigger method which used in conjunction with FakeTable should allow you to do test your trigger. Not sure of this version is packaged up with SQL test yet though.
I have successfully used SQL Test with a more recent build of tSQLt (based on the SQL script download via tsqlt.org) but YMMV. / comments
kenbroz wrote:
why has been answered, I would like to know the answer because it has a similar problem.
The latest version of tSQLt (the framework that underpins RedGate's SQL Test) now has an...
SQLCop has a number of standard checks - things like SELECT * out of the box and I believe is open source.
IIRC, RedGate's SQL Test can incorporate the standard SQL Cop validations in their own unit test class which can then be run within the tSQLt/SQL Test framework. As these tests are all written in SQL - it would be easy to extend.
Another option might be to look at the work Dave Ballantyne has done one a powershell based code parser to look for the same dort of code smells / comments
SQLCop has a number of standard checks - things like SELECT * out of the box and I believe is open source.
IIRC, RedGate's SQL Test can incorporate the standard SQL Cop validations in their own uni...
You could always try and win a free copy from my blog.
All you have to do is practice some test-driven database development using a code kata in T-SQL then add a comment to the post explaining how you got on. The five best responses will get a free licence for SQL Test kindly donated by Red Gate.[/url] / comments
You could always try and win a free copy from my blog.
All you have to do is practice some test-driven database development using a code kata in T-SQL then add a comment to the post explaining how ...
Okay, let’s try leaving SSC out of the mix for a moment.
In the “shared†model, all database developers write their code against the same database. Hopefully they connect to this database with their own dedicated login (whether Windows or SQL Server) rather than some global dev user account. There is a single dev database and everyone develops in that.
In the "dedicated" model, each developer makes their changes against their own dedicated database. This could be multiple databases on the same SQL Server instance: PubsTom, PubsDick, PubsHarry etc but it is more likely to be set up so that each developer has their own dedicated SQL Server instance. This might be a VM or named instance on a shared physical server or SQL Server Developer edition (or even SQL Express) installed on each developer’s desktop.
User is what you think it is – a Windows or SQL Server login.
“Sandbox†is just a term used to describe a dedicated development environment where a developer can “play†without impacting on anyone else. It is a physical thing and you can only have a sandbox if operating the “dedicated†model as a shared database cannot, by definition, be a sandbox - unless everyone else has gone home for the night maybe [image]
So the question in SQL Source Control when you bring a database under source control relates to whether all your database developers work in one shared database or whether they each develop in their own dedicated database. As far as I know, it is not possible to combine both approaches in SSC.
I am not sure how SSC would work if all your developers use a single global user account like “sa†to develop. / comments
Okay, let’s try leaving SSC out of the mix for a moment.
In the “shared†model, all database developers write their code against the same database. Hopefully they connect to this database wit...
Yes that is exactly what I'm saying. A function (of any type) is just like any other module - if you re-name and re-populate a referenced table (using FakeTable) - the function will use the data you supply from the renamed table(s).
simonjmartin wrote:
Are you saying that if I fake the tables that TVF_PROMsGetUploadedScorecardsFilteredByHeaders references then when it runs it would query the data I've loaded as part of the test. So I could set up those tables to return data that matches what's being expected?
/ comments
Yes that is exactly what I'm saying. A function (of any type) is just like any other module - if you re-name and re-populate a referenced table (using FakeTable) - the function will use the data y...