OSQL SA Password Restrictions involving # & ^ symbols

Is anyone aware of such a restriction? All my SQL Jobs etc run fine with my
SA account & password that includes both a # and a ^, but when I try to run
jobs from OSQL the job fails with a bad password error. Naturally, I have
double checked the password entry. I have also tried running a simple oqsl
job under an account that uses just plain aplhanumeric characters in the
password & that runs fine.
Thanks,
Nick.
use double quotation marks (")... osql -S<server> -U<user> -P <"password">
"Nick" wrote:

> Is anyone aware of such a restriction? All my SQL Jobs etc run fine with my
> SA account & password that includes both a # and a ^, but when I try to run
> jobs from OSQL the job fails with a bad password error. Naturally, I have
> double checked the password entry. I have also tried running a simple oqsl
> job under an account that uses just plain aplhanumeric characters in the
> password & that runs fine.
> Thanks,
> Nick.

OSQL SA Password Restrictions involving # & ^ symbols

Is anyone aware of such a restriction? All my SQL Jobs etc run fine with my
SA account & password that includes both a # and a ^, but when I try to run
jobs from OSQL the job fails with a bad password error. Naturally, I have
double checked the password entry. I have also tried running a simple oqsl
job under an account that uses just plain aplhanumeric characters in the
password & that runs fine.
Thanks,
Nick.use double quotation marks (")... osql -S<server> -U<user> -P <"password">
"Nick" wrote:

> Is anyone aware of such a restriction? All my SQL Jobs etc run fine with m
y
> SA account & password that includes both a # and a ^, but when I try to r
un
> jobs from OSQL the job fails with a bad password error. Naturally, I have
> double checked the password entry. I have also tried running a simple oqsl
> job under an account that uses just plain aplhanumeric characters in the
> password & that runs fine.
> Thanks,
> Nick.

OSQL SA Password Restrictions involving # & ^ symbols

Is anyone aware of such a restriction? All my SQL Jobs etc run fine with my
SA account & password that includes both a # and a ^, but when I try to run
jobs from OSQL the job fails with a bad password error. Naturally, I have
double checked the password entry. I have also tried running a simple oqsl
job under an account that uses just plain aplhanumeric characters in the
password & that runs fine.
Thanks,
Nick.use double quotation marks (")... osql -S<server> -U<user> -P <"password">
"Nick" wrote:
> Is anyone aware of such a restriction? All my SQL Jobs etc run fine with my
> SA account & password that includes both a # and a ^, but when I try to run
> jobs from OSQL the job fails with a bad password error. Naturally, I have
> double checked the password entry. I have also tried running a simple oqsl
> job under an account that uses just plain aplhanumeric characters in the
> password & that runs fine.
> Thanks,
> Nick.

OSQL and SQL 2005 Express

Hi All... I'm trying to upgrade one of our MSDE-based products to SQL 2005 Express. The installation of the product includes the use of a bat file that makes several OSQL calls. This bat file runs on the machine that has SQL 2005 Express installed and is failing - times out trying to connect. I've gotten away from the bat file and am now just trying to run OSQL against the db from a dos prompt. I'm getting the following:

C:\Documents and Settings\cdehaven>osql -E
[SQL Native Client]Named Pipes Provider: Could not open a connection to SQLServer [2].
[SQL Native Client]Login timeout expired
[SQL Native Client]An error has occurred while establishing a connection to
the server. When connecting to SQL Server 2005, this failure may be caused by
the fact that under the default settings SQL Server does not allow remote
connections.

Any thoughts? Thanks much!!

Curt

Answered my own question! I added a switch to the OSQL command line:

-S.\sqlexpress

This specifies the server and i suppose instance of sql server to connect to. I never needed to do this with MSDE, but I guess we need to now...

Curt

|||

MSDE installed as a default instance by default, SQL Server 2005 does not, it installs the Express instance by default in Machine\SQLExpress. if you are using a named instance you will either have to provide the following syntax (or use a SQLAlias on the machines)

1. Machine\InstanceName
2 Machinename,Portnumber (Which will redirect to the named instance, be aware that this is impratical for SQL Server Express named instances by default as the port is dynamically choosenupon startup of the service)

Jens K. Suessmeyer

http://www.sqlserver2005.de