anchor.diff:  
   * Because result types are auto-generated, FSharp.Data.SqlClient doesn't support so-called [multi-mapping](http://stackoverflow.com/a/6001902/862313)
   * As FSharp.Data.SqlClient is based on features specific for Sql Server 2012; Dapper provides better range of supported scenarios, including Mono
  -* Other side of this is that FSharp.Data.SqlClient fully supports SqlServer-specific types like [hierarchyId](http://technet.microsoft.com/en-us/library/bb677173.aspx) and 
  +* Other side of this is that FSharp.Data.SqlClient fully supports SqlServer-specific types like [hierarchyId](http://technet.microsoft.com/en-us/library/bb677173.aspx) and
   [spatial types](http://blogs.msdn.com/b/adonet/archive/2013/12/09/microsoft-sqlserver-types-nuget-package-spatial-on-azure.aspx), which Dapper does not
  -* FSharp.Data.SqlClient fully supports User-Defined Table Types for input parameters with no additional coding required, 
  +* FSharp.Data.SqlClient fully supports User-Defined Table Types for input parameters with no additional coding required,
   [as opposed to Dapper](http://stackoverflow.com/questions/6232978/does-dapper-support-sql-2008-table-valued-parameters)
  -* Dapper intentionally  has no support for `SqlConnection` management; FSharp.Data.SqlClient encapsulates `SqlConnection` 
  +* Dapper intentionally  has no support for `SqlConnection` management; FSharp.Data.SqlClient encapsulates `SqlConnection`
   life-cycle including asynchronous scenarios while optionally accepting external `SqlTransaction`.
   
   Following FSharp.Data.SqlClient features are unique:
   
   * Reasonable auto-generated result type definition so there is no need to define it in code
   * This type also comes with `IDictionary<string,obj>` and `DynamicObject` implementation
  -* Sql command is just a string for other ORMs, while FSHarp.Data.SqlClient verifies it and figures out input parameters and output types 
  +* Sql command is just a string for other ORMs, while FSHarp.Data.SqlClient verifies it and figures out input parameters and output types
   so design-time experience is simply unparalleled
  -* Design-time verification means less run-time tests, less yak shaving synchronizing database schema with code definitions, and earliest possible 
  +* Design-time verification means less run-time tests, less yak shaving synchronizing database schema with code definitions, and earliest possible
   identification of bugs and mismatches
   * `SqlProgrammabilityProvider` lets user to explore stored procedures and user-defined functions right from the code with IntelliSense
   
   
  -It is my believe that FSharp.Data.SqlClient comes closest to the mission of micro-ORM - to make conversion between data stored in database and .Net run-time types as painless as possible 
  +It is my believe that FSharp.Data.SqlClient comes closest to the mission of micro-ORM - to make conversion between data stored in database and .Net run-time types as painless as possible
   while keeping away from [object-relational impedance mismatch](http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch)
   as described in famous blog [The Vietnam of Computer Science](http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx) by Ted Neward.
   
   [Generating strongly typed DataSets](http://msdn.microsoft.com/en-us/library/wha85tzb.aspx)
   -----------------------------------------
   
  -Using strongly typed DataSets requires creation of XSD schema which then used to generate C# code. Dubious pleasure of hand-crafting XSD aside, 
  +Using strongly typed DataSets requires creation of XSD schema which then used to generate C# code. Dubious pleasure of hand-crafting XSD aside,
   this traditional technique suffers from the same limitation as Entity Framework and such when compared to FSharp.Data.SqlClient:
   no design-time interaction with model database - it is up to a user to keep definitions and database schema in sync.
   
  
positive.code: 
  Not so good:
  
  - Generates EF-models on background
  - Not dynamic
  - Doesn't scale to large databases
  - FSharp/LINQ query-syntax is a learning curve
  
negative.code: - FSharp/LINQ query-syntax is a learning curve
  - Doesn't generate domain model for work with C#
  - Most LINQ-operations supported, but not yet complex group-by scenarios
  - Updates in complex scenarios can be a pain
  
  ### SqlDataConnection
  
  