Connection to SQL2005 Database Engine

On one server I connect to I always get this message when I try to launch object explorer.
TITLE: Microsoft SQL Server Management Studio
An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)
Insert Error :column name or number of supplied values doesn't match.. Error:213.

Sometimes I can run refresh, and it will eventually connect.

Is the version of sql server you're connecting to the same as the one that was installed where you're launching SSMS? If not, and depending on the versions, underlying procs that SSMS depend on may be different between the two versions.
|||The server is SQL Standard Sept. release, and I installed the same version, workstation only on my station. I eventually get the browser to work. Other server is a June release std and it doesn't do this. I reinstalled every workstation component, and now I have SSIS working but still getting the browser error looking at objects on this server. BTW this server has been installed a couple of times .|||I found out that I had some possible old components in the install dir, so I started over again with fresh Sept install. When I did that , I noticed again my SQL2000 Ent Mgr quit working as I uninstalled. Prev. I had repatched SQL sp4 then reran setup of 2005. This time I left it alone , finished up install, and lo and behold the object browser works AND SQL 2000 Ent. MGr. What I am trying to deduce is the sqldmo dll might be involved . Does SQL2005 install replace that in the Windows directory , and it happens to have backwards compatibility so the 2000 still can use it ? Here is a link to the article. All is right for the moment, I shall cherish it at least the SQL2005 world a bit better.

http://www.aspfaq.com/sql2005/show.asp?id=4

Connection problem from Access front end application to SQL Desktop Engine backend

Hi there,

I sincerely hope that someone out there can help. I have two
instances of the SQL 2000 Desktop Engine running. One is on my local
machine for development and the other is on another machine on our
network which is the production environment. I have built an Access
2003 front end application which connects to this database. This
works fine locally, as you would expect. I successfully installed the
database on the production machine and am able to connect to it via
Access 2003 (using the Data Link Properties window) and from third
party database manager software (similar to Enterprise Manager). I am
not able to to connect to the database via my application.

I am using the "sa" account with a strong password. This is my
connection string:

strConnection = "Provider=sqloledb;DataSource=server02;User
Id=sa;Password=strong;Initial Catalog=Test"

The error I'm getting is:

"Connection cannot be used to perform this operation. It is either
closed or invalid in this context."

The connection string is the only thing that changes in my code when I
switch from my local to my production database. Is there some reason
that I can't use the "sa" account in this fashion that I'm not aware
of? I'd rather not use integrated security for simplicity's sake as
this is a small, internal application. Also, I would have thought
that if that was the issue, I couldn't use "sa" at all, even locally.

I'm going to post to the Access group as well but thought someone here
might have some advice to offer as well.

Thanks,

BarbHi

You may want to try connecting from your client using osql. It is not clear
if the manager software is on your client. If not then there seems to be a
network problem. Did you install it with the DISABLENETWORKPROTOCOLS
option?
http://support.microsoft.com/defaul...121120121120120
to enable them see
http://support.microsoft.com/defaul...kb;en-us;827204

John

"Barb" <funkybarb@.gmail.com> wrote in message
news:2ea50a4d.0504131151.43b8dbda@.posting.google.c om...
> Hi there,
> I sincerely hope that someone out there can help. I have two
> instances of the SQL 2000 Desktop Engine running. One is on my local
> machine for development and the other is on another machine on our
> network which is the production environment. I have built an Access
> 2003 front end application which connects to this database. This
> works fine locally, as you would expect. I successfully installed the
> database on the production machine and am able to connect to it via
> Access 2003 (using the Data Link Properties window) and from third
> party database manager software (similar to Enterprise Manager). I am
> not able to to connect to the database via my application.
> I am using the "sa" account with a strong password. This is my
> connection string:
> strConnection = "Provider=sqloledb;DataSource=server02;User
> Id=sa;Password=strong;Initial Catalog=Test"
> The error I'm getting is:
> "Connection cannot be used to perform this operation. It is either
> closed or invalid in this context."
> The connection string is the only thing that changes in my code when I
> switch from my local to my production database. Is there some reason
> that I can't use the "sa" account in this fashion that I'm not aware
> of? I'd rather not use integrated security for simplicity's sake as
> this is a small, internal application. Also, I would have thought
> that if that was the issue, I couldn't use "sa" at all, even locally.
> I'm going to post to the Access group as well but thought someone here
> might have some advice to offer as well.
> Thanks,
> Barb|||Hi John,

Thanks for your response. Since I posted my query, I did manage to
connect to my remote database using integrated security instead of the
"sa" account. I added my user account to a SQL server group that I
created and then gave that group login rights to the database. That
works fine from my development machine but not if I package up Access
with the Access runtime and try to run on another machine that doesn't
have Access 2003 installed. So, I've solved one problem but now have
another. I've posted again to the Access group to see if anyone can
help me there.

Barb

John Bell wrote:
> Hi
> You may want to try connecting from your client using osql. It is not
clear
> if the manager software is on your client. If not then there seems to
be a
> network problem. Did you install it with the DISABLENETWORKPROTOCOLS
> option?
http://support.microsoft.com/defaul...121120121120120

> to enable them see
> http://support.microsoft.com/defaul...kb;en-us;827204
> John
>
> "Barb" <funkybarb@.gmail.com> wrote in message
> news:2ea50a4d.0504131151.43b8dbda@.posting.google.c om...
> > Hi there,
> > I sincerely hope that someone out there can help. I have two
> > instances of the SQL 2000 Desktop Engine running. One is on my
local
> > machine for development and the other is on another machine on our
> > network which is the production environment. I have built an
Access
> > 2003 front end application which connects to this database. This
> > works fine locally, as you would expect. I successfully installed
the
> > database on the production machine and am able to connect to it via
> > Access 2003 (using the Data Link Properties window) and from third
> > party database manager software (similar to Enterprise Manager). I
am
> > not able to to connect to the database via my application.
> > I am using the "sa" account with a strong password. This is my
> > connection string:
> > strConnection = "Provider=sqloledb;DataSource=server02;User
> > Id=sa;Password=strong;Initial Catalog=Test"
> > The error I'm getting is:
> > "Connection cannot be used to perform this operation. It is either
> > closed or invalid in this context."
> > The connection string is the only thing that changes in my code
when I
> > switch from my local to my production database. Is there some
reason
> > that I can't use the "sa" account in this fashion that I'm not
aware
> > of? I'd rather not use integrated security for simplicity's sake
as
> > this is a small, internal application. Also, I would have thought
> > that if that was the issue, I couldn't use "sa" at all, even
locally.
> > I'm going to post to the Access group as well but thought someone
here
> > might have some advice to offer as well.
> > Thanks,
> > Barb