SQlHelper vs SqlClient

[Ken Getz]

I have never used SqlHelper. But since more than 3 years I am using
SqlClient to communicate with database.

I want to know the advantage of SqlHelper over SqlClient.
Also I want to know the disadvantage of SqlHelper over SqlClient.

Ken

 

[Mark Rae]

I have never used SqlHelper. But since more than 3 years I am using
SqlClient to communicate with database.

I want to know the advantage of SqlHelper over SqlClient.
Also I want to know the disadvantage of SqlHelper over SqlClient.

Ken Getz? What, as in "the" Ken Getz who wrote all those Access books for
Sibex...?

 

[Ken Getz]

I don't know any "Ken Getz" but me. And I did not write any books.

Ken

 

[Mark Rae]

I don't know any "Ken Getz" but me. And I did not write any books.

Ah...
http://www.amazon.com/exec/obidos/s...e=books/ref=xs_ap_l_xgl14/104-7045848-3615145

 

[Mythran]

I have never used SqlHelper. But since more than 3 years I am using
SqlClient to communicate with database.

I want to know the advantage of SqlHelper over SqlClient.
Also I want to know the disadvantage of SqlHelper over SqlClient.

Ken

SqlHelper is a library that uses the SqlClient namespace classes to
communicate with the SQL Server DBMS. It makes it so that you don't have to
write your own dbms libraries for quicker data access. The SqlHelper
library has been replaced with the Enterprice Library Database Access
Application Block
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/entlib.asp).
This application block extends the databases supported by including Db2 and
Oracle databases and provides the components to create your own database
support block.

Check out the link to see more about the Enterprise Library

HTH,


Mythran

 

[ken.getz]

Just wanted to add to this thread. I am amazed that there's ANOTHER
"Ken Getz" in this same namespace -- that is, a developer using
Microsoft tools. Who would'a thunk? In any case, just to clear things
up -- I'm the Ken Getz who wrote the books (and many, many articles in
various places, many about ADO.NET). So I guess there are two of us!
Ken2, where are you from? -- Ken

 

[ken.getz]

Just wanted to add to this thread. I am amazed that there's ANOTHER
"Ken Getz" in this same namespace -- that is, a developer using
Microsoft tools. Who would'a thunk? In any case, just to clear things
up -- I'm the Ken Getz who wrote the books (and many, many articles in
various places, many about ADO.NET). So I guess there are two of us!
Ken2, where are you from? -- Ken

 

[Sahil Malik [MVP]]

No this is a different Ken.

SM

Ken Getz? What, as in "the" Ken Getz who wrote all those Access books for
Sibex...?

 

[Sahil Malik [MVP]]

SqlHelper is an example of a data layer. It is a good idea to have a data
layer in your application. SqlClient on the other hand is a .NET data
provider.

SqlHelper uses SqlClient to do it's work.

- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx

 

[Mark Rae]

I'm the Ken Getz who wrote the books

Massive respect - the Access Developers' Handbooks you wrote with Lutwin,
Reddick et al remain some of the best technical reference works I've ever
used.

 

[W.G. Ryan - MVP]

I was amazed too. Being that you are one of the people that taught me to
develop - I was pretty stoked that I might have been able to answer a
question for you ;-). But figured that it was a different Ken.

 

[W.G. Ryan - MVP]

SqlHelper isn't a replacement for SqlClient - it actually uses it. All it
is is an implementaton of a data access layer. The Enterprise Library has
other ones for other providers as well. Overall it's a pretty easy to use
Design and can simplify development b/c it wraps a lot of the tedious and
redundant tasks that you typically perform with SqlClient - over and over
again. It has some nice features that allow you to pass in an object array
for your parameters for a sql statement or stored proc, and it creates the
parameters for you. It ensures that connections that are opened are always
closed. These are probably two of the most convenient features it provides.
Plus you have the benefit of having your data access code in one central
location so that you don't have to worry about some new developer (or
experienced one who just happens to make a mistake) not closing a connection
he/she opened and leaking connections everhwere. And the really nice thing
is that you have the source code so you can implement whatever you please on
it. So if you want to add Asynch call support, transaction support.,
centralized encryption of your connection strings etc.

 

[ken.getz]

Thanks. We're contemplating updating for Access 12, if we can find the
market... -- Ken

 

[Mark Rae]

Thanks. We're contemplating updating for Access 12, if we can find the
market... -- Ken

Hmm - things have certainly moved on - it comes to something when even Scott
Barker's latest books are about C# and InfoPath... ;-)