Re: SQL Native Client vs SQL Server Driver

Ah, now we are beginning to see a little clearer into your real problem. In
your original post, you have expressed the point that your main concern was
to only get the best performance possible in all cases; even if this was to
give you some extra complication in the setup process but now, you are
speaking more about the possibility of installation problems because of the
need to support hundreds of customers, with many different versions of
Windows and SPs.

On the blog for the SQL Native Client (SNAC), you will find a lot of useful
information about its differences with the other ODBC or OLEDB drivers for
SQL-Server and its support for various OS:

http://blogs.msdn.com/sqlnativeclient/

The problem with the SNAC is that you will probably have to distribute it
with your installation setup (or at least, provide the link to download it).
However, its biggest advantage is that unlike the MDAC, not only that you
will be sure to not have any problem because of a difference of version of
the installed MDAC but also, you can also be sure (up to 100%) that you
won't break anything on the user's machine; something that you cannot say if
you take the precaution (?) of installing the latest available version of
MDAC on the client's machines.

Probably that there are still a lot of clients around here with older
machines and versions of MDAC (I still have some clients with Access 97).
They won't be happy if you break something on their machine by installing
the most recent version of MDAC (or worse, an older version). However, by
installing the SNAC (if they don't have it), you can be sure - probably with
100% of certainty - that you won't mess anything on their machine and even
more, you can even garantee that to your clients.

It will also be easier to upgrade your application in the future with new
functionalities if you start by using the SNAC right now. If you start with
a mix of MDAC (many versions) and SNAC (version 9) from the beginning, it
won't be so easy.

My opinion: your application is a new application and whenever it's
possible, a new application should always use the lasted driver if it can do
so.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)


"John Bigbooty" <BOGUSevileye0702BOGUS@xxxxxxxxxxxxxxxxxx> wrote in message
news:480dad59.7866937@xxxxxxxxxxxxxxxxxxxxx
On Sun, 20 Apr 2008 18:38:08 -0400, "Sylvain Lafontaine" <sylvain aei
ca (fill the blanks, no spam please)> wrote:

You are over-thinking here. First, you should think about finishing your
application instead of trying to *optimize* it when it's not even
finished.

Second, trying to evaluate the relative performance of different drivers
is
a much more difficult task than you think. The results that you are now
getting could be totally different on another system or on the same system
but with a different level of load or of pattern of usage.

Third, even if you could evaluate some difference between their
performance,
there are things more important than that: first, the real load on a
sql-server is made by executing queries, not by returning the final result
to the client and second, the added functionality and security provided by
the latest driver if probably much more important than the possibility of
saving a few microseconds here and there.

Finally, if you absolutely want to save a few microseconds, add more
memory
or wait a few weeks before buying your next computer.

Was there some reason you felt compelled to reply and act like a total
ass? Before you go making blanket assumptions about me or my
application perhaps you should look in the mirror and ask yourself "am
I really as high and mighty as I think I am?"

First, my application is basically complete. We are just finishing the
final details and making sure we support both the SQL 2000 & 2005
platforms using the most efficient driver for client connections.

Second, although I'm concerned about server-side performance, that
wasn't the issue at hand. Since I need to support both 2000 and 2005
running mostly the same queries, I wanted to know what was the
recommended client side driver to use for an application that needs to
support both platforms.

Finally, we aren't talking about microseconds here. Our application
frequently runs complex queries against tables involving more than
10,000,000 rows. Adding memory or buying a new computer is not a
decision we make. We leave that up the hundreds of users purchasing
the software.

Mark
Atlanta GA




.

Relevant Pages

  • Re: Printer autocreation failing
    ... behaviour of a TS incompatible printer driver. ... MCSE, CCEA, Microsoft MVP - Terminal Server ... Tried installing that printer tray hotfix, ... Also tried updating the RDP client to the latest ...
    (microsoft.public.windows.terminal_services)
  • Re: Printer autocreation failing
    ... reinstall the driver onto the TS box). ... Check in Printers and Faxes - File - Server properties - ... Also tried updating the RDP client to the ... box and installing the print queue from the remote server ...
    (microsoft.public.windows.terminal_services)
  • Re: Printer autocreation failing
    ... redirection of the driver to the LJ4) and functional. ... Check in Printers and Faxes - File - Server properties - ... Also tried updating the RDP client to the ... box and installing the print queue from the remote server ...
    (microsoft.public.windows.terminal_services)
  • Re: Cant connect to Oracle using MSDAORA OLE DB provider
    ... the more recent MDAC releases, so I usually install MDAC 1.5 on new ... client computers in addition to MDAC 2.8. ... using the OraOLEDB provider, ... client so that the necessary driver files are copied to the client ...
    (comp.databases.oracle.misc)
  • Re: Windows 98/ME and MS Access
    ... you need MDAC 2.5 if the Jet driver/provider isn't already installed. ... then you run that on the target machine before installing your ... > Provider or ODBC driver, the Desktop Database ODBC Drivers, or the Visual ...
    (microsoft.public.dotnet.framework.adonet)