Saturday, June 22, 2013

[MS SQL Server] SQLCLR assemblies - how can I find out .NET version of each?

[MS SQL Server] SQLCLR assemblies - how can I find out .NET version of each?

SQLCLR assemblies - how can I find out .NET version of each?

Posted: 22 Jun 2013 02:55 AM PDT

I'm trying to find out with which .NET version each of the CLR assemblies in my SQL-2012 instance were built, but I am unable to find this info.For example, were the deployed assemblies built with .NET 2, 3 or 4?Views, such as [i]sys.assemblies[/i], [i]sys.dm_clr_appdomains[/i], [i]sys.dm_clr_loaded_assemblies [/i]do not seem to give me this info.My CLR is on version 4.0 (SQL 2012):[code="sql"]select * from sys.dm_clr_properties[/code]name value------------------------------------------------------------directory C:\Windows\Microsoft.NET\Framework64\v4.0.30319\version v4.0.30319state CLR is initializedThank you for any responses.

SQL Server Automated Deployment - Development to Prod

Posted: 21 Jun 2013 07:23 AM PDT

Hi Folks I work for a up and coming Dotcom. We are looking at automated deployment of T-SQL from Dev then Route To Live then Pre-Prod and then Production. There is testing at each stage - technical and business. Our aim is to provide continuous delivery mechanism to our web application (500Gb of Prod Data , partitioned tables , decent physical boxes)Some of our dev's have proposed Entity Framework Migrations Libraries within .Net. I like their idea's in principle but being a DBA of some years I'm wondering what numerous pitfalls await. Does anyone have experience of a solid continuous delivery mechanism for SQL Server 2008 and beyond for deploying across environments. We have agreed downtime so the concurrency aspect is not a concern. My concern would be roll back and forth of database versions based on an external software i.e .net framework. I guess if you understood the dependencies between objects and data this would be ok but I'm unsure. I'm unsure if the framework would be able to handle anything beyond very basic DML.... (what about SQL Agent jobs ? etc )My personal thoughts are ok for most aspects that have no direct underlying data i.e rebuilt ok for stored procs without dropping plans and rebuild of views. These account for 70% of changes anyway. Also deployment of any new table objects + indexes would be ok. My gut feeling is, that automating within .net schema changes for tables with 200,000,000 plus rows (across partitions) is not wise. Then again if testing is adequate and backups\backouts in place then why not? Any feedback most welcome Thanks Alan
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)

Search This Blog