Showing posts with label dsn. Show all posts
Showing posts with label dsn. Show all posts

Sunday, March 25, 2012

Connectivity Problems

hi
I could nt create a Sql Server ODBC with Norton autoprotect ON
when i disable Norton Autoprotect, the DSN Creation is successful.
why is this so?Originally posted by baburajv
hi

I could nt create a Sql Server ODBC with Norton autoprotect ON
when i disable Norton Autoprotect, the DSN Creation is successful.
why is this so?

Hi,

Some sort of antiviruses do not allow to connect/ creates problem in connectivity that is very comman problem by them..
try to install same version of antivirus on client pc, then try
hope this will work.

Thursday, March 8, 2012

Connection to ODBC without a DSN

Is it possible to connect to an ODBC driver (e.g. SQL Server or Oracle)
directly without having to create a DSN before hand.
This would be great as dumb users can't handle creating a DSN.
Would be nice if I could ask them SQL Server or Oracle, server name, user
name and password only and programmatically connect with that amount of
information.
Tony
You can use an OLEDB connection which is better anyway... see
http://www.aspfaq.com/2126 for samples that work in VB and ASP, and the
basic structure should work from any client language that supports it...
http://www.aspfaq.com/
(Reverse address to reply.)
"Tony" <tonyng2@.spacecommand.net> wrote in message
news:eRxayfHjEHA.1344@.TK2MSFTNGP11.phx.gbl...
> Is it possible to connect to an ODBC driver (e.g. SQL Server or Oracle)
> directly without having to create a DSN before hand.
> This would be great as dumb users can't handle creating a DSN.
> Would be nice if I could ask them SQL Server or Oracle, server name, user
> name and password only and programmatically connect with that amount of
> information.
> Tony
>
|||Nope, not an option, would require a total recode of my database layer.
I'm required to continue using ODBC.
Application is C++/MFC client server application.
Thanks,
Tony
P.S. I have heard that OLEDB runs slightly slower due to COM marshaling.
What makes it a better choice from a C++ perspective?
"Aaron [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
news:Of119iHjEHA.3608@.TK2MSFTNGP09.phx.gbl...[vbcol=seagreen]
> You can use an OLEDB connection which is better anyway... see
> http://www.aspfaq.com/2126 for samples that work in VB and ASP, and the
> basic structure should work from any client language that supports it...
> --
> http://www.aspfaq.com/
> (Reverse address to reply.)
>
>
> "Tony" <tonyng2@.spacecommand.net> wrote in message
> news:eRxayfHjEHA.1344@.TK2MSFTNGP11.phx.gbl...
user
>
|||You can use a dsn-less connection. Code the connection
string with the driver/provider you use in whatever syntax
is required for the data access api you are using with your
application.
OLE DB can provide more functionality and is generally
faster than ODBC.
-Sue
On Fri, 27 Aug 2004 16:17:36 -0500, "Tony"
<tonyng2@.spacecommand.net> wrote:

>Nope, not an option, would require a total recode of my database layer.
>I'm required to continue using ODBC.
>Application is C++/MFC client server application.
>Thanks,
>Tony
>P.S. I have heard that OLEDB runs slightly slower due to COM marshaling.
>What makes it a better choice from a C++ perspective?
>"Aaron [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
>news:Of119iHjEHA.3608@.TK2MSFTNGP09.phx.gbl...
>user
>
|||To be more specific, you use SQLDriverConnect instead of SQLConnect.
You can even leverage the driver to prompt for the login information.
Here's an example:
SQLCHAR* connectionString = (SQLCHAR*)"driver={SQL
Server};database=mydatabase";
SQLDriverConnect(hdbc, hwnd, connectionString, SQL_NTS, NULL, 0, NULL,
SQL_DRIVER_PROMPT);
SQL_DRIVER_PROMPT will cause the driver to display a dialog prompting the
user for the server name and uid/pwd information.
As far as ODBC vs. OLEDB is concerned, OLEDB is nice, it is a lot more
flexible than ODBC, but it's also a lot more difficult to use. If you're
accessing simple, relational data, just use ODBC. If you're already using
ODBC, and you dont need some specific feature of OLEDB, just continue to use
ODBC.
Brannon
"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
news:qp85j0pfp3pj7qgto5tt19arv0cp9ke86d@.4ax.com... [vbcol=seagreen]
> You can use a dsn-less connection. Code the connection
> string with the driver/provider you use in whatever syntax
> is required for the data access api you are using with your
> application.
> OLE DB can provide more functionality and is generally
> faster than ODBC.
> -Sue
> On Fri, 27 Aug 2004 16:17:36 -0500, "Tony"
> <tonyng2@.spacecommand.net> wrote:
it...[vbcol=seagreen]
Oracle)[vbcol=seagreen]
of
>
|||Thanks for the info.
I just need a way now to get the connection string used so I can save it for
next time.
Doesn't look like it gives it back to you.
Thanks,
Tony
"Brannon Jones" <brannonjNOSPAM@.gmail.com> wrote in message
news:uXeO4urjEHA.3624@.TK2MSFTNGP10.phx.gbl...
> To be more specific, you use SQLDriverConnect instead of SQLConnect.
> You can even leverage the driver to prompt for the login information.
> Here's an example:
> SQLCHAR* connectionString = (SQLCHAR*)"driver={SQL
> Server};database=mydatabase";
> SQLDriverConnect(hdbc, hwnd, connectionString, SQL_NTS, NULL, 0, NULL,
> SQL_DRIVER_PROMPT);
> SQL_DRIVER_PROMPT will cause the driver to display a dialog prompting the
> user for the server name and uid/pwd information.
> As far as ODBC vs. OLEDB is concerned, OLEDB is nice, it is a lot more
> flexible than ODBC, but it's also a lot more difficult to use. If you're
> accessing simple, relational data, just use ODBC. If you're already using
> ODBC, and you dont need some specific feature of OLEDB, just continue to
use[vbcol=seagreen]
> ODBC.
> Brannon
> "Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
> news:qp85j0pfp3pj7qgto5tt19arv0cp9ke86d@.4ax.com...
marshaling.[vbcol=seagreen]
the[vbcol=seagreen]
> it...
> Oracle)
name,[vbcol=seagreen]
amount
> of
>
|||Why doesn't it look like it gives it back to you?
My example is a basic example of how to use SQLDriverConnect().
There are parameters on SQLDriverConnect() that return the connection string
that was used to connect.
Brannon
"Tony" <tonyng2@.spacecommand.net> wrote in message
news:OaQO8iujEHA.2544@.TK2MSFTNGP10.phx.gbl...
> Thanks for the info.
> I just need a way now to get the connection string used so I can save it
for[vbcol=seagreen]
> next time.
> Doesn't look like it gives it back to you.
> Thanks,
> Tony
>
> "Brannon Jones" <brannonjNOSPAM@.gmail.com> wrote in message
> news:uXeO4urjEHA.3624@.TK2MSFTNGP10.phx.gbl...
the[vbcol=seagreen]
you're[vbcol=seagreen]
using[vbcol=seagreen]
> use
layer.
> marshaling.
> the
> name,
> amount
>
|||I guess I have brain damage today, my apologies. :-)
Thanks for the reply,
Tony
"Brannon Jones" <brannonjNOSPAM@.gmail.com> wrote in message
news:eeMEES6jEHA.3876@.TK2MSFTNGP15.phx.gbl...
> Why doesn't it look like it gives it back to you?
> My example is a basic example of how to use SQLDriverConnect().
> There are parameters on SQLDriverConnect() that return the connection
string[vbcol=seagreen]
> that was used to connect.
> Brannon
> "Tony" <tonyng2@.spacecommand.net> wrote in message
> news:OaQO8iujEHA.2544@.TK2MSFTNGP10.phx.gbl...
> for
> the
> you're
> using
to[vbcol=seagreen]
> layer.
and[vbcol=seagreen]
supports
>

Connection to ODBC without a DSN

Is it possible to connect to an ODBC driver (e.g. SQL Server or Oracle)
directly without having to create a DSN before hand.
This would be great as dumb users can't handle creating a DSN.
Would be nice if I could ask them SQL Server or Oracle, server name, user
name and password only and programmatically connect with that amount of
information.
TonyYou can use an OLEDB connection which is better anyway... see
http://www.aspfaq.com/2126 for samples that work in VB and ASP, and the
basic structure should work from any client language that supports it...
http://www.aspfaq.com/
(Reverse address to reply.)
"Tony" <tonyng2@.spacecommand.net> wrote in message
news:eRxayfHjEHA.1344@.TK2MSFTNGP11.phx.gbl...
> Is it possible to connect to an ODBC driver (e.g. SQL Server or Oracle)
> directly without having to create a DSN before hand.
> This would be great as dumb users can't handle creating a DSN.
> Would be nice if I could ask them SQL Server or Oracle, server name, user
> name and password only and programmatically connect with that amount of
> information.
> Tony
>|||Nope, not an option, would require a total recode of my database layer.
I'm required to continue using ODBC.
Application is C++/MFC client server application.
Thanks,
Tony
P.S. I have heard that OLEDB runs slightly slower due to COM marshaling.
What makes it a better choice from a C++ perspective?
"Aaron [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
news:Of119iHjEHA.3608@.TK2MSFTNGP09.phx.gbl...
> You can use an OLEDB connection which is better anyway... see
> http://www.aspfaq.com/2126 for samples that work in VB and ASP, and the
> basic structure should work from any client language that supports it...
> --
> http://www.aspfaq.com/
> (Reverse address to reply.)
>
>
> "Tony" <tonyng2@.spacecommand.net> wrote in message
> news:eRxayfHjEHA.1344@.TK2MSFTNGP11.phx.gbl...
user[vbcol=seagreen]
>|||You can use a dsn-less connection. Code the connection
string with the driver/provider you use in whatever syntax
is required for the data access api you are using with your
application.
OLE DB can provide more functionality and is generally
faster than ODBC.
-Sue
On Fri, 27 Aug 2004 16:17:36 -0500, "Tony"
<tonyng2@.spacecommand.net> wrote:

>Nope, not an option, would require a total recode of my database layer.
>I'm required to continue using ODBC.
>Application is C++/MFC client server application.
>Thanks,
>Tony
>P.S. I have heard that OLEDB runs slightly slower due to COM marshaling.
>What makes it a better choice from a C++ perspective?
>"Aaron [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
>news:Of119iHjEHA.3608@.TK2MSFTNGP09.phx.gbl...
>user
>|||To be more specific, you use SQLDriverConnect instead of SQLConnect.
You can even leverage the driver to prompt for the login information.
Here's an example:
SQLCHAR* connectionString = (SQLCHAR*)"driver={SQL
Server};database=mydatabase";
SQLDriverConnect(hdbc, hwnd, connectionString, SQL_NTS, NULL, 0, NULL,
SQL_DRIVER_PROMPT);
SQL_DRIVER_PROMPT will cause the driver to display a dialog prompting the
user for the server name and uid/pwd information.
As far as ODBC vs. OLEDB is concerned, OLEDB is nice, it is a lot more
flexible than ODBC, but it's also a lot more difficult to use. If you're
accessing simple, relational data, just use ODBC. If you're already using
ODBC, and you dont need some specific feature of OLEDB, just continue to use
ODBC.
Brannon
"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
news:qp85j0pfp3pj7qgto5tt19arv0cp9ke86d@.
4ax.com...
> You can use a dsn-less connection. Code the connection
> string with the driver/provider you use in whatever syntax
> is required for the data access api you are using with your
> application.
> OLE DB can provide more functionality and is generally
> faster than ODBC.
> -Sue
> On Fri, 27 Aug 2004 16:17:36 -0500, "Tony"
> <tonyng2@.spacecommand.net> wrote:
>
it...[vbcol=seagreen]
Oracle)[vbcol=seagreen]
of[vbcol=seagreen]
>|||Thanks for the info.
I just need a way now to get the connection string used so I can save it for
next time.
Doesn't look like it gives it back to you.
Thanks,
Tony
"Brannon Jones" <brannonjNOSPAM@.gmail.com> wrote in message
news:uXeO4urjEHA.3624@.TK2MSFTNGP10.phx.gbl...
> To be more specific, you use SQLDriverConnect instead of SQLConnect.
> You can even leverage the driver to prompt for the login information.
> Here's an example:
> SQLCHAR* connectionString = (SQLCHAR*)"driver={SQL
> Server};database=mydatabase";
> SQLDriverConnect(hdbc, hwnd, connectionString, SQL_NTS, NULL, 0, NULL,
> SQL_DRIVER_PROMPT);
> SQL_DRIVER_PROMPT will cause the driver to display a dialog prompting the
> user for the server name and uid/pwd information.
> As far as ODBC vs. OLEDB is concerned, OLEDB is nice, it is a lot more
> flexible than ODBC, but it's also a lot more difficult to use. If you're
> accessing simple, relational data, just use ODBC. If you're already using
> ODBC, and you dont need some specific feature of OLEDB, just continue to
use
> ODBC.
> Brannon
> "Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
> news:qp85j0pfp3pj7qgto5tt19arv0cp9ke86d@.
4ax.com...
marshaling.[vbcol=seagreen]
the[vbcol=seagreen]
> it...
> Oracle)
name,[vbcol=seagreen]
amount[vbcol=seagreen]
> of
>|||Why doesn't it look like it gives it back to you?
My example is a basic example of how to use SQLDriverConnect().
There are parameters on SQLDriverConnect() that return the connection string
that was used to connect.
Brannon
"Tony" <tonyng2@.spacecommand.net> wrote in message
news:OaQO8iujEHA.2544@.TK2MSFTNGP10.phx.gbl...
> Thanks for the info.
> I just need a way now to get the connection string used so I can save it
for
> next time.
> Doesn't look like it gives it back to you.
> Thanks,
> Tony
>
> "Brannon Jones" <brannonjNOSPAM@.gmail.com> wrote in message
> news:uXeO4urjEHA.3624@.TK2MSFTNGP10.phx.gbl...
the[vbcol=seagreen]
you're[vbcol=seagreen]
using[vbcol=seagreen]
> use
layer.[vbcol=seagreen]
> marshaling.
> the
> name,
> amount
>|||I guess I have brain damage today, my apologies. :-)
Thanks for the reply,
Tony
"Brannon Jones" <brannonjNOSPAM@.gmail.com> wrote in message
news:eeMEES6jEHA.3876@.TK2MSFTNGP15.phx.gbl...
> Why doesn't it look like it gives it back to you?
> My example is a basic example of how to use SQLDriverConnect().
> There are parameters on SQLDriverConnect() that return the connection
string
> that was used to connect.
> Brannon
> "Tony" <tonyng2@.spacecommand.net> wrote in message
> news:OaQO8iujEHA.2544@.TK2MSFTNGP10.phx.gbl...
> for
> the
> you're
> using
to[vbcol=seagreen]
> layer.
and[vbcol=seagreen]
supports[vbcol=seagreen]
>

Saturday, February 25, 2012

connection string with dsn

I want's to use following connection string

"dsn=MyDsn;uid=MyUser;pwd=MyPassword"

Can some how I use it with sqlconnection

I want's to get rid of odbconnection e.t.c

What will be the connection string for sql provider for above dsn information.

If anybody can explain the please help me ?

If you use a DSN, you will have to use ODBC to connect. Here are your options for connecting to SQL Server:http://www.connectionstrings.com/?carrier=sqlserver|||

Take a look here:http://www.connectionstrings.com

Hope this helps!

|||

Thanks mike then I have to use odbc.

By using dsn.I can hide the server name but for dsnless i have to provide the server name which i don't want's to provide.

|||

I put my connection string in webconfig. There is an option to encrypt this if you want. I haven't done it so I don't know what's involved. But I am sure a google search for "Encrypt connection string web config" will yield some useful info.

All I know is that one should steer clear of ODBC unless you can avoid it. It adds an extra layer of software to your data access which hampers scalability.

Friday, February 24, 2012

Connection String Options ...Urgent .. plz reply

Hi

In my project , we are using Dsn and DSN less connection, for certain functionality

we are providing users to select tables and views .

we don't want that all system tables and views are listed for selecting , how can we achieve this functionality?

Is there any options in the connection string for restricting system tables and views?

Any help is much appriciated

Thanks

Saurabh

Book mark the following site;

http://www.connectionstrings.com/

Sunday, February 12, 2012

Connection Problems to SQL 6.5

We connect to a SQL 6.5 server (IP for example 202.64.213.11) on WIN NT
using ODBC DSN and / or SQL Client (DB-LIB). Everthing was working fine then
the some XP client machines (192.168.0.1 and 192.168.0.3) started giving
problems. All TCP/IP connections go thru the WIN 2000 multihomed machine
(192.168.0.2 where its connecting fine). The error when creating ODBC DSN is
Connection failed:
SQLState: '01000'
SQL Server Error: 10054
[Microsoft][ODBC SQL Server][TCP/IP Sockets]ConnectionRead(recv()).
Connection failed:
SQLState: '08501'
SQL Server Error: 11
[Microsoft][ODBC SQL Server][TCP/IP Sockets]General network error. Check
your network documentation.
Sometimes there is no error but the Tests failed' and DSN is not created!
In the SQL Error log the messages are like "Unable to create Login
packet(s)"
With the SQL Enterprise manager running on the client machines I can connect
to the server (sometimes!) but it does not expand the databases etc or any
thing listed under the server. However now its not connecting and giving the
message
"A connection could not be established to 202.64.213.11 - [DB-Library]
Possible network error: Write to SQL Server Failed. General network error.
Check your documentation."
We've tried different things like creating user accounts on the multihomed
and client systems again. changing password to log on to Win XP etc.
Upgrading on one machine to MDAC 2.8 but there is no success etc.
It was working fine yesterday!
Any help would be appreciated."Mansoor Azam" <mansoorb@.shoa.net> wrote in message news:<c5oimj$44h14$1@.ID-31123.news.uni-berlin.de>...
> We connect to a SQL 6.5 server (IP for example 202.64.213.11) on WIN NT
> using ODBC DSN and / or SQL Client (DB-LIB). Everthing was working fine then
> the some XP client machines (192.168.0.1 and 192.168.0.3) started giving
> problems. All TCP/IP connections go thru the WIN 2000 multihomed machine
> (192.168.0.2 where its connecting fine). The error when creating ODBC DSN is
> Connection failed:
> SQLState: '01000'
> SQL Server Error: 10054
> [Microsoft][ODBC SQL Server][TCP/IP Sockets]ConnectionRead(recv()).
> Connection failed:
> SQLState: '08501'
> SQL Server Error: 11
> [Microsoft][ODBC SQL Server][TCP/IP Sockets]General network error. Check
> your network documentation.
> Sometimes there is no error but the Tests failed' and DSN is not created!
> In the SQL Error log the messages are like "Unable to create Login
> packet(s)"
> With the SQL Enterprise manager running on the client machines I can connect
> to the server (sometimes!) but it does not expand the databases etc or any
> thing listed under the server. However now its not connecting and giving the
> message
> "A connection could not be established to 202.64.213.11 - [DB-Library]
> Possible network error: Write to SQL Server Failed. General network error.
> Check your documentation."
> We've tried different things like creating user accounts on the multihomed
> and client systems again. changing password to log on to Win XP etc.
> Upgrading on one machine to MDAC 2.8 but there is no success etc.
> It was working fine yesterday!
> Any help would be appreciated.
Is it possible that the WinXp clients have somehow enabled IPV6
support and may be garbling the traffic to the server ?
Just a thought...|||Seems like we had client problems like this and it turned
out that the clients swicthed the connection properties in
ODBC to tcp/ip sockets when we were using named pipes on
the server side. This happened after the installation of
an application on the clients. Maybe try different
options in the client config options in odbc on the
clients?

Connection Problems to SQL 6.5

We connect to a SQL 6.5 server (IP for example 202.64.213.11) on WIN NT
using ODBC DSN and / or SQL Client (DB-LIB). Everthing was working fine then
the some XP client machines (192.168.0.1 and 192.168.0.3) started giving
problems. All TCP/IP connections go thru the WIN 2000 multihomed machine
(192.168.0.2 where its connecting fine). The error when creating ODBC DSN is

Connection failed:
SQLState: '01000'
SQL Server Error: 10054
[Microsoft][ODBC SQL Server][TCP/IP Sockets]ConnectionRead(recv()).
Connection failed:
SQLState: '08501'
SQL Server Error: 11
[Microsoft][ODBC SQL Server][TCP/IP Sockets]General network error. Check
your network documentation.

Sometimes there is no error but the Tests failed' and DSN is not created!

In the SQL Error log the messages are like "Unable to create Login
packet(s)"

With the SQL Enterprise manager running on the client machines I can connect
to the server (sometimes!) but it does not expand the databases etc or any
thing listed under the server. However now its not connecting and giving the
message

"A connection could not be established to 202.64.213.11 - [DB-Library]
Possible network error: Write to SQL Server Failed. General network error.
Check your documentation."

We've tried different things like creating user accounts on the multihomed
and client systems again. changing password to log on to Win XP etc.
Upgrading on one machine to MDAC 2.8 but there is no success etc.

It was working fine yesterday!
Any help would be appreciated."Mansoor Azam" <mansoorb@.shoa.net> wrote in message news:<c5oimj$44h14$1@.ID-31123.news.uni-berlin.de>...
> We connect to a SQL 6.5 server (IP for example 202.64.213.11) on WIN NT
> using ODBC DSN and / or SQL Client (DB-LIB). Everthing was working fine then
> the some XP client machines (192.168.0.1 and 192.168.0.3) started giving
> problems. All TCP/IP connections go thru the WIN 2000 multihomed machine
> (192.168.0.2 where its connecting fine). The error when creating ODBC DSN is
> Connection failed:
> SQLState: '01000'
> SQL Server Error: 10054
> [Microsoft][ODBC SQL Server][TCP/IP Sockets]ConnectionRead(recv()).
> Connection failed:
> SQLState: '08501'
> SQL Server Error: 11
> [Microsoft][ODBC SQL Server][TCP/IP Sockets]General network error. Check
> your network documentation.
> Sometimes there is no error but the Tests failed' and DSN is not created!
> In the SQL Error log the messages are like "Unable to create Login
> packet(s)"
> With the SQL Enterprise manager running on the client machines I can connect
> to the server (sometimes!) but it does not expand the databases etc or any
> thing listed under the server. However now its not connecting and giving the
> message
> "A connection could not be established to 202.64.213.11 - [DB-Library]
> Possible network error: Write to SQL Server Failed. General network error.
> Check your documentation."
> We've tried different things like creating user accounts on the multihomed
> and client systems again. changing password to log on to Win XP etc.
> Upgrading on one machine to MDAC 2.8 but there is no success etc.
> It was working fine yesterday!
> Any help would be appreciated.

Is it possible that the WinXp clients have somehow enabled IPV6
support and may be garbling the traffic to the server ?

Just a thought...

Connection Problems to SQL 6.5

We connect to a SQL 6.5 server (IP for example 202.64.213.11) on WIN NT
using ODBC DSN and / or SQL Client (DB-LIB). Everthing was working fine then
the some XP client machines (192.168.0.1 and 192.168.0.3) started giving
problems. All TCP/IP connections go thru the WIN 2000 multihomed machine
(192.168.0.2 where its connecting fine). The error when creating ODBC DSN is
Connection failed:
SQLState: '01000'
SQL Server Error: 10054
[Microsoft][ODBC SQL Server][TCP/IP Sockets]ConnectionRead(recv()).
Connection failed:
SQLState: '08501'
SQL Server Error: 11
[Microsoft][ODBC SQL Server][TCP/IP Sockets]General network error. Check
your network documentation.
Sometimes there is no error but the Tests failed' and DSN is not created!
In the SQL Error log the messages are like "Unable to create Login
packet(s)"
With the SQL Enterprise manager running on the client machines I can connect
to the server (sometimes!) but it does not expand the databases etc or any
thing listed under the server. However now its not connecting and giving the
message
"A connection could not be established to 202.64.213.11 - [DB-Library]
Possible network error: Write to SQL Server Failed. General network error.
Check your documentation."
We've tried different things like creating user accounts on the multihomed
and client systems again. changing password to log on to Win XP etc.
Upgrading on one machine to MDAC 2.8 but there is no success etc.
It was working fine yesterday!
Any help would be appreciated.
"Mansoor Azam" <mansoorb@.shoa.net> wrote in message news:<c5oimj$44h14$1@.ID-31123.news.uni-berlin.de>...
> We connect to a SQL 6.5 server (IP for example 202.64.213.11) on WIN NT
> using ODBC DSN and / or SQL Client (DB-LIB). Everthing was working fine then
> the some XP client machines (192.168.0.1 and 192.168.0.3) started giving
> problems. All TCP/IP connections go thru the WIN 2000 multihomed machine
> (192.168.0.2 where its connecting fine). The error when creating ODBC DSN is
> Connection failed:
> SQLState: '01000'
> SQL Server Error: 10054
> [Microsoft][ODBC SQL Server][TCP/IP Sockets]ConnectionRead(recv()).
> Connection failed:
> SQLState: '08501'
> SQL Server Error: 11
> [Microsoft][ODBC SQL Server][TCP/IP Sockets]General network error. Check
> your network documentation.
> Sometimes there is no error but the Tests failed' and DSN is not created!
> In the SQL Error log the messages are like "Unable to create Login
> packet(s)"
> With the SQL Enterprise manager running on the client machines I can connect
> to the server (sometimes!) but it does not expand the databases etc or any
> thing listed under the server. However now its not connecting and giving the
> message
> "A connection could not be established to 202.64.213.11 - [DB-Library]
> Possible network error: Write to SQL Server Failed. General network error.
> Check your documentation."
> We've tried different things like creating user accounts on the multihomed
> and client systems again. changing password to log on to Win XP etc.
> Upgrading on one machine to MDAC 2.8 but there is no success etc.
> It was working fine yesterday!
> Any help would be appreciated.
Is it possible that the WinXp clients have somehow enabled IPV6
support and may be garbling the traffic to the server ?
Just a thought...

Connection Problems to SQL 6.5

We connect to a SQL 6.5 server (IP for example 202.64.213.11) on WIN NT
using ODBC DSN and / or SQL Client (DB-LIB). Everthing was working fine then
the some XP client machines (192.168.0.1 and 192.168.0.3) started giving
problems. All TCP/IP connections go thru the WIN 2000 multihomed machine
(192.168.0.2 where its connecting fine). The error when creating ODBC DSN is
Connection failed:
SQLState: '01000'
SQL Server Error: 10054
[Microsoft][ODBC SQL Server][TCP/IP Sockets]ConnectionRead(recv()).
Connection failed:
SQLState: '08501'
SQL Server Error: 11
[Microsoft][ODBC SQL Server][TCP/IP Sockets]General network error. Check
your network documentation.
Sometimes there is no error but the Tests failed' and DSN is not created!
In the SQL Error log the messages are like "Unable to create Login
packet(s)"
With the SQL Enterprise manager running on the client machines I can connect
to the server (sometimes!) but it does not expand the databases etc or any
thing listed under the server. However now its not connecting and giving the
message
"A connection could not be established to 202.64.213.11 - [DB-Library]
Possible network error: Write to SQL Server Failed. General network error.
Check your documentation."
We've tried different things like creating user accounts on the multihomed
and client systems again. changing password to log on to Win XP etc.
Upgrading on one machine to MDAC 2.8 but there is no success etc.
It was working fine yesterday!
Any help would be appreciated.
"Mansoor Azam" <mansoorb@.shoa.net> wrote in message news:<c5oimj$44h14$1@.ID-31123.news.uni-berlin.de>...
> We connect to a SQL 6.5 server (IP for example 202.64.213.11) on WIN NT
> using ODBC DSN and / or SQL Client (DB-LIB). Everthing was working fine then
> the some XP client machines (192.168.0.1 and 192.168.0.3) started giving
> problems. All TCP/IP connections go thru the WIN 2000 multihomed machine
> (192.168.0.2 where its connecting fine). The error when creating ODBC DSN is
> Connection failed:
> SQLState: '01000'
> SQL Server Error: 10054
> [Microsoft][ODBC SQL Server][TCP/IP Sockets]ConnectionRead(recv()).
> Connection failed:
> SQLState: '08501'
> SQL Server Error: 11
> [Microsoft][ODBC SQL Server][TCP/IP Sockets]General network error. Check
> your network documentation.
> Sometimes there is no error but the Tests failed' and DSN is not created!
> In the SQL Error log the messages are like "Unable to create Login
> packet(s)"
> With the SQL Enterprise manager running on the client machines I can connect
> to the server (sometimes!) but it does not expand the databases etc or any
> thing listed under the server. However now its not connecting and giving the
> message
> "A connection could not be established to 202.64.213.11 - [DB-Library]
> Possible network error: Write to SQL Server Failed. General network error.
> Check your documentation."
> We've tried different things like creating user accounts on the multihomed
> and client systems again. changing password to log on to Win XP etc.
> Upgrading on one machine to MDAC 2.8 but there is no success etc.
> It was working fine yesterday!
> Any help would be appreciated.
Is it possible that the WinXp clients have somehow enabled IPV6
support and may be garbling the traffic to the server ?
Just a thought...

Connection Problems to SQL 6.5

We connect to a SQL 6.5 server (IP for example 202.64.213.11) on WIN NT
using ODBC DSN and / or SQL Client (DB-LIB). Everthing was working fine then
the some XP client machines (192.168.0.1 and 192.168.0.3) started giving
problems. All TCP/IP connections go thru the WIN 2000 multihomed machine
(192.168.0.2 where its connecting fine). The error when creating ODBC DSN is
Connection failed:
SQLState: '01000'
SQL Server Error: 10054
[Microsoft][ODBC SQL Server][TCP/IP Sockets]ConnectionRead(recv()).
Connection failed:
SQLState: '08501'
SQL Server Error: 11
[Microsoft][ODBC SQL Server][TCP/IP Sockets]General network error. Check
your network documentation.
Sometimes there is no error but the Tests failed' and DSN is not created!
In the SQL Error log the messages are like "Unable to create Login
packet(s)"
With the SQL Enterprise manager running on the client machines I can connect
to the server (sometimes!) but it does not expand the databases etc or any
thing listed under the server. However now its not connecting and giving the
message
"A connection could not be established to 202.64.213.11 - [DB-Library]
Possible network error: Write to SQL Server Failed. General network error.
Check your documentation."
We've tried different things like creating user accounts on the multihomed
and client systems again. changing password to log on to Win XP etc.
Upgrading on one machine to MDAC 2.8 but there is no success etc.
It was working fine yesterday!
Any help would be appreciated.
"Mansoor Azam" <mansoorb@.shoa.net> wrote in message news:<c5oimj$44h14$1@.ID-31123.news.uni-berlin.de>...
> We connect to a SQL 6.5 server (IP for example 202.64.213.11) on WIN NT
> using ODBC DSN and / or SQL Client (DB-LIB). Everthing was working fine then
> the some XP client machines (192.168.0.1 and 192.168.0.3) started giving
> problems. All TCP/IP connections go thru the WIN 2000 multihomed machine
> (192.168.0.2 where its connecting fine). The error when creating ODBC DSN is
> Connection failed:
> SQLState: '01000'
> SQL Server Error: 10054
> [Microsoft][ODBC SQL Server][TCP/IP Sockets]ConnectionRead(recv()).
> Connection failed:
> SQLState: '08501'
> SQL Server Error: 11
> [Microsoft][ODBC SQL Server][TCP/IP Sockets]General network error. Check
> your network documentation.
> Sometimes there is no error but the Tests failed' and DSN is not created!
> In the SQL Error log the messages are like "Unable to create Login
> packet(s)"
> With the SQL Enterprise manager running on the client machines I can connect
> to the server (sometimes!) but it does not expand the databases etc or any
> thing listed under the server. However now its not connecting and giving the
> message
> "A connection could not be established to 202.64.213.11 - [DB-Library]
> Possible network error: Write to SQL Server Failed. General network error.
> Check your documentation."
> We've tried different things like creating user accounts on the multihomed
> and client systems again. changing password to log on to Win XP etc.
> Upgrading on one machine to MDAC 2.8 but there is no success etc.
> It was working fine yesterday!
> Any help would be appreciated.
Is it possible that the WinXp clients have somehow enabled IPV6
support and may be garbling the traffic to the server ?
Just a thought...

Connection Problems to SQL 6.5

We connect to a SQL 6.5 server (IP for example 202.64.213.11) on WIN NT
using ODBC DSN and / or SQL Client (DB-LIB). Everthing was working fine then
the some XP client machines (192.168.0.1 and 192.168.0.3) started giving
problems. All TCP/IP connections go thru the WIN 2000 multihomed machine
(192.168.0.2 where its connecting fine). The error when creating ODBC DSN is
Connection failed:
SQLState: '01000'
SQL Server Error: 10054
[Microsoft][ODBC SQL Server][TCP/IP Sockets]ConnectionRead(recv(
)).
Connection failed:
SQLState: '08501'
SQL Server Error: 11
[Microsoft][ODBC SQL Server][TCP/IP Sockets]General network erro
r. Check
your network documentation.
Sometimes there is no error but the Tests failed' and DSN is not created!
In the SQL Error log the messages are like "Unable to create Login
packet(s)"
With the SQL Enterprise manager running on the client machines I can connect
to the server (sometimes!) but it does not expand the databases etc or any
thing listed under the server. However now its not connecting and giving the
message
"A connection could not be established to 202.64.213.11 - [DB-Library]
Possible network error: Write to SQL Server Failed. General network error.
Check your documentation."
We've tried different things like creating user accounts on the multihomed
and client systems again. changing password to log on to Win XP etc.
Upgrading on one machine to MDAC 2.8 but there is no success etc.
It was working fine yesterday!
Any help would be appreciated."Mansoor Azam" <mansoorb@.shoa.net> wrote in message news:<c5oimj$44h14$1@.ID-31123.news.uni-b
erlin.de>...
> We connect to a SQL 6.5 server (IP for example 202.64.213.11) on WIN NT
> using ODBC DSN and / or SQL Client (DB-LIB). Everthing was working fine th
en
> the some XP client machines (192.168.0.1 and 192.168.0.3) started giving
> problems. All TCP/IP connections go thru the WIN 2000 multihomed machine
> (192.168.0.2 where its connecting fine). The error when creating ODBC DSN
is
> Connection failed:
> SQLState: '01000'
> SQL Server Error: 10054
> [Microsoft][ODBC SQL Server][TCP/IP Sockets]ConnectionRead(rec
v()).
> Connection failed:
> SQLState: '08501'
> SQL Server Error: 11
> [Microsoft][ODBC SQL Server][TCP/IP Sockets]General network er
ror. Check
> your network documentation.
> Sometimes there is no error but the Tests failed' and DSN is not created!
> In the SQL Error log the messages are like "Unable to create Login
> packet(s)"
> With the SQL Enterprise manager running on the client machines I can conne
ct
> to the server (sometimes!) but it does not expand the databases etc or any
> thing listed under the server. However now its not connecting and giving t
he
> message
> "A connection could not be established to 202.64.213.11 - [DB-Library]
> Possible network error: Write to SQL Server Failed. General network error.
> Check your documentation."
> We've tried different things like creating user accounts on the multihomed
> and client systems again. changing password to log on to Win XP etc.
> Upgrading on one machine to MDAC 2.8 but there is no success etc.
> It was working fine yesterday!
> Any help would be appreciated.
Is it possible that the WinXp clients have somehow enabled IPV6
support and may be garbling the traffic to the server ?
Just a thought...

Friday, February 10, 2012

Connection problem to Informix from SQL Server 2005 with Unicode data

I have Informix 9.4TC6 and SQL Server 2005.
DB_LOCALE in Informix DB is en_US.utf8 (en_US.57372).

First, I created DSN to Informix. Then tried to get data with WinSql
tool and it works fine.
But when I created linked server in SQL Server 2005 I have problems
with languages other than English.
I get a string like:
' -|工 1/4 1/43/4

It seems to me that SQL Server splits 2-byte characters in 2 1-byte
characters.
If in options of linked server we set Collation Name to exact
language
we want --then string data will be correct (of course only of
language that we choose).

Do you have any suggestions???

P.S. I don't want to use SSIS (DTS) for extraction from Informix DB(denis.carabadjac@.gmail.com) writes:

Quote:

Originally Posted by

I have Informix 9.4TC6 and SQL Server 2005.
DB_LOCALE in Informix DB is en_US.utf8 (en_US.57372).
>
First, I created DSN to Informix. Then tried to get data with WinSql
tool and it works fine.
But when I created linked server in SQL Server 2005 I have problems
with languages other than English.
I get a string like:
' ?-|工 1/4 1/4?3/4
>
It seems to me that SQL Server splits 2-byte characters in 2 1-byte
characters.
If in options of linked server we set Collation Name to exact
language
we want --then string data will be correct (of course only of
language that we choose).
>
Do you have any suggestions???


This looks like a difficult case. SQL Server does not support UTF-8.
You can set a server option, "Collation name" as you found, but that
should be a collation that exists in SQL Server, but SQL Server does
not have any UTF-8 collations.

I have no experience with Informix, but it seems to me that either you
need to find a way to convert UTF-8 to UTF-16, or you will have to
go over the file system. The tool BCP as well as the command BULK INSERT
is able to handle files with UTF-8 data.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx