Does connection string need anything on system?

  • Thread starter Thread starter gerryR
  • Start date Start date
G

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
 
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
 
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
 
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)
Click to expand...

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
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

My vacation and childhood cancer awareness site:
http://www.crazycancertour.com

*******************************************
| Think outside the box! |
*******************************************
 
How do you know what providers are all ready on the system?
Click to expand...

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,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

My vacation and childhood cancer awareness site:
http://www.crazycancertour.com

*******************************************
| Think outside the box! |
*******************************************
 
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 said:
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
Click to expand...
 
Thanks for the detailed explanation Scott.

Moving away from ODBC now.

Scott M. said:
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
Click to expand...
 
Gregory A. Beamer said:
Run it and see if it breaks. ;-)
Click to expand...

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
 
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
:)
Click to expand...

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,


--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

My vacation and childhood cancer awareness site:
http://www.crazycancertour.com

*******************************************
| Think outside the box! |
*******************************************
 
Back
Top