Does connection string need anything on system?

[gerryR]

I'm setting up a connection string to an excel file which will be stored in
the same location as the asp.net page (wwwroot)

Do I need to setup something on the system's Data Source Tool
(Administrative Tools-->Data Sources (ODBC)) to corrospond with that
connection string? If so what are the settings? (eg does it have to have
the exact same name as the connection string, or how do the two relate)

Thanks for any help, fairly new to all this!
gR

 

[gerryR]

Hi,

We're using older .xls files, will the method mentioned there support that?

Also, is a Data Source required to be setup on the client if using an ODBC
connection? Even if I don't go down that route I'd like to know, I'm
curious as to what the Data Source tool is used for.

Thanks
gR

 

[Scott M.]

You would only need to set up a Data Source Name (DSN) using the ODBC
Manager if you plan to use ODBC to connect to Excel. If you want to use a
DSN-less connection (where the provider is on the system already and you
just configure your connection string to use it), then setting up the
connection string will suffice.

-Scott

 

[gerryR]

How do you know what providers are all ready on the system?

Thanks
gR

 

[Gregory A. Beamer]

I'm setting up a connection string to an excel file which will be
stored in the same location as the asp.net page (wwwroot)

Do I need to setup something on the system's Data Source Tool
(Administrative Tools-->Data Sources (ODBC)) to corrospond with that
connection string? If so what are the settings? (eg does it have to
have the exact same name as the connection string, or how do the two
relate)

NO.

But you will most likely have to get the actual path to the file or use a
UNC to use it as a data source (not tested, but sound theory).

Peace and Grace,

 

[Gregory A. Beamer]

How do you know what providers are all ready on the system?

Run it and see if it breaks. ;-)

With .NET OLEDB, you will need the Jet drivers, which are not included with
the main install in most versions of .NET. You can download them from
Microsoft. Actually, the advice of putting the files out and seeing if they
break is valid, as it is the quickest way on a new web app install to see
if you need to install anything.

I would not use ODBC for Excel unless you absolutely have to, as it will be
slower for no reason.

Peace and Grace,

 

[Scott M.]

Open DataBase Connectivity (ODBC) is a Microsoft standard (albeit an old
one) that allowed a developer to set up a Data Source Name (DSN) within the
operating system. This DSN needed to be configured to know which database
driver was going to be needed and which actual data source was being used.
This is what the ODBC Manager tool in Control Panel > Admin Tools is
for...setting up a DSN. The DSN must then be set up on EACH machine where
the DSN would be called from executing code.

OLEDB Providers (a.k.a. DSN-less connections) superceded ODBC some time ago
and allow for you to take the middle man (the ODBC Mananger) and the
machine-specific DSN's created by it out of the picture. With OLEDB, you
code directly against the provider and, as long as the provider is present
on the target machine, the code can talk to it. This results in better
performance and is why OLEDB is preferred to ODBC.

Greg's advice to try it and see if it breaks (or the optimist's view: try it
and see if it works) is probably the easiest way to know if you have the
needed provider in an application that will run from a server (since you
don't want to be running around and checking every user's machine to see if
it breaks/works. If it works on your server (where the app is running),
you're all set! If not, you can contact the data source vendor (in this
case Microsoft) to obtain the necessary provider. Microsoft's various OS's
do come from the factory with many providers baked right it, but JET (which
is uesed in older MS products) is no longer a standard part of the MDAC
(Microsoft Data Access Controls) download. However, it can be found as a
standalone download from various sources.

-Scott

Hi,

We're using older .xls files, will the method mentioned there support
that?

Also, is a Data Source required to be setup on the client if using an ODBC
connection? Even if I don't go down that route I'd like to know, I'm
curious as to what the Data Source tool is used for.

Thanks
gR

 

[gerryR]

Thanks for the detailed explanation Scott.

Moving away from ODBC now.

Open DataBase Connectivity (ODBC) is a Microsoft standard (albeit an old
one) that allowed a developer to set up a Data Source Name (DSN) within
the operating system. This DSN needed to be configured to know which
database driver was going to be needed and which actual data source was
being used. This is what the ODBC Manager tool in Control Panel > Admin
Tools is for...setting up a DSN. The DSN must then be set up on EACH
machine where the DSN would be called from executing code.

OLEDB Providers (a.k.a. DSN-less connections) superceded ODBC some time
ago and allow for you to take the middle man (the ODBC Mananger) and the
machine-specific DSN's created by it out of the picture. With OLEDB, you
code directly against the provider and, as long as the provider is present
on the target machine, the code can talk to it. This results in better
performance and is why OLEDB is preferred to ODBC.

Greg's advice to try it and see if it breaks (or the optimist's view: try
it and see if it works) is probably the easiest way to know if you have
the needed provider in an application that will run from a server (since
you don't want to be running around and checking every user's machine to
see if it breaks/works. If it works on your server (where the app is
running), you're all set! If not, you can contact the data source vendor
(in this case Microsoft) to obtain the necessary provider. Microsoft's
various OS's do come from the factory with many providers baked right it,
but JET (which is uesed in older MS products) is no longer a standard part
of the MDAC (Microsoft Data Access Controls) download. However, it can be
found as a standalone download from various sources.

-Scott

 

[gerryR]

Run it and see if it breaks. ;-)

I'll give it a go so, only problem with this method is I'm new to this so if
it doesn't work it's could be down to something else I've done

Thanks
gR

 

[gerryR]

No. Once again, there is no reason to use ODBC when OleDb is available...

Thanks, I'll have a go with that connection string.

 

[Gregory A. Beamer]

I'll give it a go so, only problem with this method is I'm new to this
so if it doesn't work it's could be down to something else I've done

Ulatimately, the way we learn best is through our mistakes. Groups like
this help us reduce them, certainly, but we have to mull through some
things to cement knowledge. And, no, it does not stop being difficult when
you get more experienced, you just get better at finding answers. ;-)

Good luck!

Peace and Grace,