March 5, 2016 at 1:46 am
Comments posted to this topic are about the item Testing times with SMO
Best wishes,
Phil Factor
March 5, 2016 at 2:22 am
I have every sympathy for the developers of SMO: it is an ambitious system that supports SSMS with great aplomb.
Sort of off-topic but I love the way Microsoft develops their platforms where, as a byproduct of building each layer of a product, the APIs underpinning that layer are offered as a core piece of the product offering. SMO gives admins and developers the opportunity to automate things and develop tools with a high-level of certainty that those tasks will be carried out the same as if someone went into SSMS and Windows Server and carried out the necessary clicks. I rely on SMO, PowerShell and WMI daily for things like configuring AlwaysOn AGs, backups & restores, checking disk space, checking hardware configurations and lots of other mundane or tedious DB and Sys admin things. In fact, I am not sure what I would do without PowerShell, SMO and WMI at this point; certainly I would find another way not to have to point and click my day away inside SSMS and Windows RDP sessions. I'd probably be doing endless string manipulation to get traditional cmd-line tools to play well together which is an existence I am not sure I could stomach.
To your main point...
I hesitate to criticize SMO in any way, as I rely on it daily. Once you get a script to work, it generally stays working. I mention it only as an illustration of what happens when you rely on automated testing. It always makes me flinch to read of applications that claim to have 'automated all their test'. The real world just isn't like that.
The pendulum is headed towards "automate all testing" in the dev and DB teams I support and am a member of but that is tempered by the level of effort to not only stand up the amount of testing code necessary to get to 100% code-coverage but also to maintain it through every new sprint. Even if 100% code coverage is achieved the level of QA testing expertise and limitations of tools like CodedUI simply won't allow the team to achieve 100% automated UI coverage. If it were possible it is still important to have qualified testers lay their eyes on a system and attempt to use it to complement the rigid set of assertions offered by automated testing tools. Testing cannot only be about pure function. Good testing means taking into account the intent of a system and I haven't seen an automated tool that is good at recognizing those types of deficiencies.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
March 6, 2016 at 1:31 am
Thank you for this excellent post but I am thinking that you have missed several points about SMO.
1) SMO appeared with SQL Server 2005 and this version was not good . The main drawback was the execution time : 90 seconds for a T-SQL script in SSMS or in an application using VC# with the System.Data.SqlClient class ) and up to 9 minutes with the SMO 2005 classes. It was better with SMO 2008 ( 6 minutes ) and SMO 2008 R2 ( between 3 and 4 minutes ). With SMO 2012 , only less 3 minutes ( no test with SMO 2014 ).
2) Another drawback was the complexity of the SMO namespaces combined with a poor documentation. Now , it is always complex but the documentation is clearer. I want to signal that it is thank 2 MSFT Michael Worries and Jens Suessmeyer who accepted to loose a tremendous time on the Technet/MSDN SMO forum to help posters and to create articles on their own ( or Microsoft ) blogs. If I am now a moderator on this forum , it is only thank all the pieces of code and advices they gave me. I was forgetting David Dye , Arnie Rowlands , Jonathan Kehayias ( sorry for the others but the list is too long ).
3) Another drawback for SMO is that the namespaces/classes are relying on the .Net Framework 3.5 ( RTM or SP1 ) which is not including the new features related to Windows 8.1 or 10 . Worst , it is impossible ( or maybe I have not found how to do ) to mix up .Net 3.5 and 4.6 in the same Visual Studio project. In 2012 , I met MSFT in the SQL Server Days and I learnt that it was not sure that SMO could be supported in the future...
4) Inside many companies , there is a war between DBA and Windows teams. Recently , I discovered a thread in the MSDN SMO forum asking how to create an application aiming to manage ( start/stop ) SQL Server services without using SMO ( only with the ServiceProcess namespace ). I replied that SMO is the best way as it is done to manage the SQL Server services. No news since 2 months even if I provided the link towards a forum about this topic. The original poster was asking for VB code ( the link was giving VC# code ) . I think that the OP was unpleasantly surprised by the complexity of the code ( I eliminate the problem VB wanted versus VC# provided , I don't like VB but when VB is asked , I write in VC# and translate in VB ). I recognize that the use of the Assert method is difficult and tricky , moreover , no processing of exceptions ( maybe the VC# code creator has had no time to take care about it ). There is a little war between VB and VC# programmers : VC# ones accept to translate VB ==> VC# but VB ones wait for the translation...
I am stopping here as I am knowing that I have a poor written English language , I am using intensively my old Harrap's dictionary ( which is exhausting as next year I will be 70 ... ). I am hoping that you will excuse me for my poor English writing.
March 6, 2016 at 6:59 am
patricklambin (3/6/2016)
1)...The main drawback was the execution time : 90 seconds for a T-SQL script in SSMS or in an application using VC# with the System.Data.SqlClient class ) and up to 9 minutes with the SMO 2005 classes. It was better with SMO 2008 ( 6 minutes ) and SMO 2008 R2 ( between 3 and 4 minutes ). With SMO 2012 , only less 3 minutes ( no test with SMO 2014 ).
Can you explain what you mean? I have no issues with the speed of scripting objects using SMO. Are you scripting some massive test system for this?
3) Another drawback for SMO is that the namespaces/classes are relying on the .Net Framework 3.5 ( RTM or SP1 ) which is not including the new features related to Windows 8.1 or 10 . Worst , it is impossible ( or maybe I have not found how to do ) to mix up .Net 3.5 and 4.6 in the same Visual Studio project. In 2012 , I met MSFT in the SQL Server Days and I learnt that it was not sure that SMO could be supported in the future...
Again, not sure what you mean? I have used SMO in a .Net 4.6 project in Visual Studio 2015 on Windows 10 for an Add-in for SSMS 2016 without any problems.
your English is amazing by the way!
MM
select geometry::STGeomFromWKB(0x0106000000020000000103000000010000000B0000001000000000000840000000000000003DD8CCCCCCCCCC0840000000000000003DD8CCCCCCCCCC08408014AE47E17AFC3F040000000000104000CDCCCCCCCCEC3F9C999999999913408014AE47E17AFC3F9C99999999991340000000000000003D0000000000001440000000000000003D000000000000144000000000000000400400000000001040000000000000F03F100000000000084000000000000000401000000000000840000000000000003D0103000000010000000B000000000000000000143D000000000000003D009E99999999B93F000000000000003D009E99999999B93F8014AE47E17AFC3F400000000000F03F00CDCCCCCCCCEC3FA06666666666FE3F8014AE47E17AFC3FA06666666666FE3F000000000000003D1800000000000040000000000000003D18000000000000400000000000000040400000000000F03F000000000000F03F000000000000143D0000000000000040000000000000143D000000000000003D, 0);March 7, 2016 at 1:23 am
I totally agree that automation testing can only take us so far. It is the exploratory testing that roots out the more nuanced defects. As a developer I have a great admiration for the excellent testers out there and, whilst I always aim then fail to produce defect free software, I attempt to ensure that the software I provide to test does not contain the simplest of defects as these should be caught in unit and integration testing and is a waste of their precious time.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply