The SqlServer Data Provider is the new provider supplied with SQL Server 2005 that exposes the server-side interface for SQL Server 2005, much in the same way that SqlClient provider did for client-based access. In fact, it seems the goal at Microsoft is to combine the two into a shared library of like functionality.
On initial thoughts this seems to make sense. The two models do provide shared functionality, interfaces and SqlTypes. Also, the objective of making the models so similar that switching between writing code for the server and client should surely reduce the effort in learning the differences between the two.
But do they? I am not entirely sure this is the case. There is sufficient difference between the code on the server and that on the client. This becomes more apparent when, as most conscientious data centric coders will do, you attempt to squeeze as much performance as possible out of the available objects.
Also, there are sufficient conceptual variations to indicate that there should be a distinction between the two. How you go about retrieving data for a typical client developer may involve utilising the DataReader. This is generally one of the most performing methods of retrieving data from SqlClient. However, this is not true for the server where the SqlContext should be harnessed and then further disparity when you factor in SqlMetaData and SqlDefinition. Note that there is a 20% performance improvement using the execution context.
I am not necessarily suggesting that the two models should be kept entirely separate and the interfaces within be defined differently than the current aim. I actually think that keeping the two closely linked a good idea. However, great care should be taken when embarking on unifying these two models so that the correct concepts are implemented during the development and there is no amalgamation of the two just because you can do something the same way on both the server and client; not necessarily a correct assumption.