Hello,
I'm running SQL7 on a Win2K server. I was in the midst of
restoring a database when I lost connectivity to the
network and the job failed.
Now if I try to view the database within Enterprise
Manager, I get the following error:
---
A connection could not be established to <servername>.
Cannot open user default database '<ID>. Using master
database instead. Please varify SQL Server is running and
check your SQL Server registration properties (by right-
clicking on the <servername> node) and try again.
---
I checked and SQL is running and the registration
properties are correct.
Any help would be appreciated.Seems like the database is "lost", as you terminated the restore, and the
logins that your EM registration login is using has that database as the
default database. I suggest you login using ISQL.EXE and change default
database using sp_defaultdb.
--
Tibor Karaszi, SQL Server MVP
Archive at:
http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"Jimbo" <anonymous@.discussions.microsoft.com> wrote in message
news:0c6201c3df7b$ee9a7fe0$a101280a@.phx.gbl...
> Hello,
> I'm running SQL7 on a Win2K server. I was in the midst of
> restoring a database when I lost connectivity to the
> network and the job failed.
> Now if I try to view the database within Enterprise
> Manager, I get the following error:
> ---
> A connection could not be established to <servername>.
> Cannot open user default database '<ID>. Using master
> database instead. Please varify SQL Server is running and
> check your SQL Server registration properties (by right-
> clicking on the <servername> node) and try again.
> ---
> I checked and SQL is running and the registration
> properties are correct.
> Any help would be appreciated.
>|||Thanks Tibor - I tried that as outlined in MS KB 196076,
but I still get a the same error.(?)
>--Original Message--
>Seems like the database is "lost", as you terminated the
restore, and the
>logins that your EM registration login is using has that
database as the
>default database. I suggest you login using ISQL.EXE and
change default
>database using sp_defaultdb.
>--
>Tibor Karaszi, SQL Server MVP
>Archive at:
>http://groups.google.com/groups?
oi=djq&as_ugroup=microsoft.public.sqlserver
>
>"Jimbo" <anonymous@.discussions.microsoft.com> wrote in
message
>news:0c6201c3df7b$ee9a7fe0$a101280a@.phx.gbl...
>> Hello,
>> I'm running SQL7 on a Win2K server. I was in the midst
of
>> restoring a database when I lost connectivity to the
>> network and the job failed.
>> Now if I try to view the database within Enterprise
>> Manager, I get the following error:
>> ---
>> A connection could not be established to <servername>.
>> Cannot open user default database '<ID>. Using master
>> database instead. Please varify SQL Server is running
and
>> check your SQL Server registration properties (by right-
>> clicking on the <servername> node) and try again.
>> ---
>> I checked and SQL is running and the registration
>> properties are correct.
>> Any help would be appreciated.
>>
>
>.
>|||Tibor Karaszi wrote:
> Seems like the database is "lost", as you terminated the restore, and the
> logins that your EM registration login is using has that database as the
> default database. I suggest you login using ISQL.EXE and change default
> database using sp_defaultdb.
>
Thanks for the information. That seems to have fixed the lost db server
issue in the drop down. Still can't get the damn app server to
connect to the db server though. Will keep searching.|||> Thanks for the information. That seems to have fixed the lost db server
> issue in the drop down. Still can't get the damn app server to connect
> to the db server though. Will keep searching.
Everyone may ignore my last post.
Showing posts with label connectivity. Show all posts
Showing posts with label connectivity. Show all posts
Thursday, March 22, 2012
A connection could not be established...Cannot open user default database...
Hello,
I'm running SQL7 on a Win2K server. I was in the midst of
restoring a database when I lost connectivity to the
network and the job failed.
Now if I try to view the database within Enterprise
Manager, I get the following error:
---
A connection could not be established to <servername>.
Cannot open user default database '<ID>. Using master
database instead. Please varify SQL Server is running and
check your SQL Server registration properties (by right-
clicking on the <servername> node) and try again.
---
I checked and SQL is running and the registration
properties are correct.
Any help would be appreciated.Seems like the database is "lost", as you terminated the restore, and the
logins that your EM registration login is using has that database as the
default database. I suggest you login using ISQL.EXE and change default
database using sp_defaultdb.
Tibor Karaszi, SQL Server MVP
Archive at:
http://groups.google.com/groups?oi=...ublic.sqlserver
"Jimbo" <anonymous@.discussions.microsoft.com> wrote in message
news:0c6201c3df7b$ee9a7fe0$a101280a@.phx.gbl...
but I still get a the same error.(?)
restore, and the
database as the
change default
oi=djq&as_ugroup=microsoft.public.sqlserver
message
I'm running SQL7 on a Win2K server. I was in the midst of
restoring a database when I lost connectivity to the
network and the job failed.
Now if I try to view the database within Enterprise
Manager, I get the following error:
---
A connection could not be established to <servername>.
Cannot open user default database '<ID>. Using master
database instead. Please varify SQL Server is running and
check your SQL Server registration properties (by right-
clicking on the <servername> node) and try again.
---
I checked and SQL is running and the registration
properties are correct.
Any help would be appreciated.Seems like the database is "lost", as you terminated the restore, and the
logins that your EM registration login is using has that database as the
default database. I suggest you login using ISQL.EXE and change default
database using sp_defaultdb.
Tibor Karaszi, SQL Server MVP
Archive at:
http://groups.google.com/groups?oi=...ublic.sqlserver
"Jimbo" <anonymous@.discussions.microsoft.com> wrote in message
news:0c6201c3df7b$ee9a7fe0$a101280a@.phx.gbl...
quote:|||Thanks Tibor - I tried that as outlined in MS KB 196076,
> Hello,
> I'm running SQL7 on a Win2K server. I was in the midst of
> restoring a database when I lost connectivity to the
> network and the job failed.
> Now if I try to view the database within Enterprise
> Manager, I get the following error:
> ---
> A connection could not be established to <servername>.
> Cannot open user default database '<ID>. Using master
> database instead. Please varify SQL Server is running and
> check your SQL Server registration properties (by right-
> clicking on the <servername> node) and try again.
> ---
> I checked and SQL is running and the registration
> properties are correct.
> Any help would be appreciated.
>
but I still get a the same error.(?)
quote:
>--Original Message--
>Seems like the database is "lost", as you terminated the
restore, and the
quote:
>logins that your EM registration login is using has that
database as the
quote:
>default database. I suggest you login using ISQL.EXE and
change default
quote:
>database using sp_defaultdb.
>--
>Tibor Karaszi, SQL Server MVP
>Archive at:
>http://groups.google.com/groups?
oi=djq&as_ugroup=microsoft.public.sqlserver
quote:
>
>"Jimbo" <anonymous@.discussions.microsoft.com> wrote in
message
quote:
>news:0c6201c3df7b$ee9a7fe0$a101280a@.phx.gbl...
of[QUOTE]
and[QUOTE]
>
>.
>
Tuesday, March 6, 2012
64bit to 32bit connectivity
Main Point: Views I have on my 64bit server will UNION ALL to my 32bit server
to gather core data. The 32bit server view needs some staic data
(CountryCode) so it INNER JOINs back to the 64bit server to get the staic
data. This is extremely slow. On my 32bit => 32bit server it works fine, but
on this new 64bit => 32bit server it's dog slow.
Details:
My 32bit server has SP3a and the InstCat.sql from the 64bit
\SETUP\IA64\Install directory, I can now call my stored procedures that use
distributed views.
My previous server setup was:
Primary = OS Window Advanced Server 2000 32bit; 32bit SQL Server Enterprise
Secondary = OS Window Advanced Server 2000 32bit; 32bit SQL Server Enterprise
32bit Server (Primary;One Year of Data) + 32bit Server (Secondary; Seven
Years of Data)
My new server setup is:
Primary = OS Window Advanced Server 2000 64bit; 64bit SQL Server Enterprise
Secondary = OS Window Advanced Server 2000 32bit; 32bit SQL Server Enterprise
64bit Server (Primary;One Year of Data) + 32bit Server (Secondary; Seven
Years of Data)
The big problem: The views on the 64bit machine (64Views) UNION ALL to the
views on the 32bit machine (32Views) to allow me to retrieve data from both
machines. The concept of distributed views won't be discussed here for
brevity. These work fine.
But, as soon as I add to the 32Views, the SQL code that will INNER JOIN to
the CountryCodes static table on the 64bit machine it takes "forever"; 28
minutes to return a handful of records (162 to be exact). The reason for
doing this because I only want one location to store CountryCode details and
the 64bit machine is the primary machine to update these. I do have them on
the 32bit machine and I could change all my production machine databases to
look there, but I don't want to have to deal with this.
Tests:
On my previous setup of 32Views => 32Views => 32CountryCode, it works fine.
On a test of 64Views => 32Views, it works fine
Now, on the new setup of 64Views => 32Views => 64CountryCode, it is DOG SLOW.
Anyone help me. If you need some code I can probably put together a small
sample (instead of my big view sets). I will plan on that, but thought I
would at least get the question out into the newsgroup.
--
dbArchitect
Greg L. Wright"dbArchitect" <dbArchitect@.discussions.microsoft.com> wrote in message
news:EE5AFA0D-BE0C-43F6-B4AE-37D52498A6B2@.microsoft.com...
> Main Point: Views I have on my 64bit server will UNION ALL to my 32bit
> server
> to gather core data. The 32bit server view needs some staic data
> (CountryCode) so it INNER JOINs back to the 64bit server to get the staic
> data. This is extremely slow. On my 32bit => 32bit server it works fine,
> but
> on this new 64bit => 32bit server it's dog slow.
>
Apart from figuring out why this is slow (or figuring out how on earth it
was ever _not_ slow), this seems like a case for replicating the static data
to the 32bit servers. You could use one of the built-in Replication types
or just schedule a job that runs
insert into CountryCode
select * from 64bitServer.MyDB.CountryCode
David
to gather core data. The 32bit server view needs some staic data
(CountryCode) so it INNER JOINs back to the 64bit server to get the staic
data. This is extremely slow. On my 32bit => 32bit server it works fine, but
on this new 64bit => 32bit server it's dog slow.
Details:
My 32bit server has SP3a and the InstCat.sql from the 64bit
\SETUP\IA64\Install directory, I can now call my stored procedures that use
distributed views.
My previous server setup was:
Primary = OS Window Advanced Server 2000 32bit; 32bit SQL Server Enterprise
Secondary = OS Window Advanced Server 2000 32bit; 32bit SQL Server Enterprise
32bit Server (Primary;One Year of Data) + 32bit Server (Secondary; Seven
Years of Data)
My new server setup is:
Primary = OS Window Advanced Server 2000 64bit; 64bit SQL Server Enterprise
Secondary = OS Window Advanced Server 2000 32bit; 32bit SQL Server Enterprise
64bit Server (Primary;One Year of Data) + 32bit Server (Secondary; Seven
Years of Data)
The big problem: The views on the 64bit machine (64Views) UNION ALL to the
views on the 32bit machine (32Views) to allow me to retrieve data from both
machines. The concept of distributed views won't be discussed here for
brevity. These work fine.
But, as soon as I add to the 32Views, the SQL code that will INNER JOIN to
the CountryCodes static table on the 64bit machine it takes "forever"; 28
minutes to return a handful of records (162 to be exact). The reason for
doing this because I only want one location to store CountryCode details and
the 64bit machine is the primary machine to update these. I do have them on
the 32bit machine and I could change all my production machine databases to
look there, but I don't want to have to deal with this.
Tests:
On my previous setup of 32Views => 32Views => 32CountryCode, it works fine.
On a test of 64Views => 32Views, it works fine
Now, on the new setup of 64Views => 32Views => 64CountryCode, it is DOG SLOW.
Anyone help me. If you need some code I can probably put together a small
sample (instead of my big view sets). I will plan on that, but thought I
would at least get the question out into the newsgroup.
--
dbArchitect
Greg L. Wright"dbArchitect" <dbArchitect@.discussions.microsoft.com> wrote in message
news:EE5AFA0D-BE0C-43F6-B4AE-37D52498A6B2@.microsoft.com...
> Main Point: Views I have on my 64bit server will UNION ALL to my 32bit
> server
> to gather core data. The 32bit server view needs some staic data
> (CountryCode) so it INNER JOINs back to the 64bit server to get the staic
> data. This is extremely slow. On my 32bit => 32bit server it works fine,
> but
> on this new 64bit => 32bit server it's dog slow.
>
Apart from figuring out why this is slow (or figuring out how on earth it
was ever _not_ slow), this seems like a case for replicating the static data
to the 32bit servers. You could use one of the built-in Replication types
or just schedule a job that runs
insert into CountryCode
select * from 64bitServer.MyDB.CountryCode
David
64bit to 32bit connectivity
Main Point: Views I have on my 64bit server will UNION ALL to my 32bit serve
r
to gather core data. The 32bit server view needs some staic data
(CountryCode) so it INNER JOINs back to the 64bit server to get the staic
data. This is extremely slow. On my 32bit => 32bit server it works fine, but
on this new 64bit => 32bit server it's dog slow.
Details:
My 32bit server has SP3a and the InstCat.sql from the 64bit
\SETUP\IA64\Install directory, I can now call my stored procedures that use
distributed views.
My previous server setup was:
Primary = OS Window Advanced Server 2000 32bit; 32bit SQL Server Enterprise
Secondary = OS Window Advanced Server 2000 32bit; 32bit SQL Server Enterpris
e
32bit Server (Primary;One Year of Data) + 32bit Server (Secondary; Seven
Years of Data)
My new server setup is:
Primary = OS Window Advanced Server 2000 64bit; 64bit SQL Server Enterprise
Secondary = OS Window Advanced Server 2000 32bit; 32bit SQL Server Enterpris
e
64bit Server (Primary;One Year of Data) + 32bit Server (Secondary; Seven
Years of Data)
The big problem: The views on the 64bit machine (64Views) UNION ALL to the
views on the 32bit machine (32Views) to allow me to retrieve data from both
machines. The concept of distributed views won't be discussed here for
brevity. These work fine.
But, as soon as I add to the 32Views, the SQL code that will INNER JOIN to
the CountryCodes static table on the 64bit machine it takes "forever"; 28
minutes to return a handful of records (162 to be exact). The reason for
doing this because I only want one location to store CountryCode details and
the 64bit machine is the primary machine to update these. I do have them on
the 32bit machine and I could change all my production machine databases to
look there, but I don't want to have to deal with this.
Tests:
On my previous setup of 32Views => 32Views => 32CountryCode, it works fine.
On a test of 64Views => 32Views, it works fine
Now, on the new setup of 64Views => 32Views => 64CountryCode, it is DOG SLOW
.
Anyone help me. If you need some code I can probably put together a small
sample (instead of my big view sets). I will plan on that, but thought I
would at least get the question out into the newsgroup.
dbArchitect
Greg L. Wright"dbArchitect" <dbArchitect@.discussions.microsoft.com> wrote in message
news:EE5AFA0D-BE0C-43F6-B4AE-37D52498A6B2@.microsoft.com...
> Main Point: Views I have on my 64bit server will UNION ALL to my 32bit
> server
> to gather core data. The 32bit server view needs some staic data
> (CountryCode) so it INNER JOINs back to the 64bit server to get the staic
> data. This is extremely slow. On my 32bit => 32bit server it works fine,
> but
> on this new 64bit => 32bit server it's dog slow.
>
Apart from figuring out why this is slow (or figuring out how on earth it
was ever _not_ slow), this seems like a case for replicating the static data
to the 32bit servers. You could use one of the built-in Replication types
or just schedule a job that runs
insert into CountryCode
select * from 64bitServer.MyDB.CountryCode
David
r
to gather core data. The 32bit server view needs some staic data
(CountryCode) so it INNER JOINs back to the 64bit server to get the staic
data. This is extremely slow. On my 32bit => 32bit server it works fine, but
on this new 64bit => 32bit server it's dog slow.
Details:
My 32bit server has SP3a and the InstCat.sql from the 64bit
\SETUP\IA64\Install directory, I can now call my stored procedures that use
distributed views.
My previous server setup was:
Primary = OS Window Advanced Server 2000 32bit; 32bit SQL Server Enterprise
Secondary = OS Window Advanced Server 2000 32bit; 32bit SQL Server Enterpris
e
32bit Server (Primary;One Year of Data) + 32bit Server (Secondary; Seven
Years of Data)
My new server setup is:
Primary = OS Window Advanced Server 2000 64bit; 64bit SQL Server Enterprise
Secondary = OS Window Advanced Server 2000 32bit; 32bit SQL Server Enterpris
e
64bit Server (Primary;One Year of Data) + 32bit Server (Secondary; Seven
Years of Data)
The big problem: The views on the 64bit machine (64Views) UNION ALL to the
views on the 32bit machine (32Views) to allow me to retrieve data from both
machines. The concept of distributed views won't be discussed here for
brevity. These work fine.
But, as soon as I add to the 32Views, the SQL code that will INNER JOIN to
the CountryCodes static table on the 64bit machine it takes "forever"; 28
minutes to return a handful of records (162 to be exact). The reason for
doing this because I only want one location to store CountryCode details and
the 64bit machine is the primary machine to update these. I do have them on
the 32bit machine and I could change all my production machine databases to
look there, but I don't want to have to deal with this.
Tests:
On my previous setup of 32Views => 32Views => 32CountryCode, it works fine.
On a test of 64Views => 32Views, it works fine
Now, on the new setup of 64Views => 32Views => 64CountryCode, it is DOG SLOW
.
Anyone help me. If you need some code I can probably put together a small
sample (instead of my big view sets). I will plan on that, but thought I
would at least get the question out into the newsgroup.
dbArchitect
Greg L. Wright"dbArchitect" <dbArchitect@.discussions.microsoft.com> wrote in message
news:EE5AFA0D-BE0C-43F6-B4AE-37D52498A6B2@.microsoft.com...
> Main Point: Views I have on my 64bit server will UNION ALL to my 32bit
> server
> to gather core data. The 32bit server view needs some staic data
> (CountryCode) so it INNER JOINs back to the 64bit server to get the staic
> data. This is extremely slow. On my 32bit => 32bit server it works fine,
> but
> on this new 64bit => 32bit server it's dog slow.
>
Apart from figuring out why this is slow (or figuring out how on earth it
was ever _not_ slow), this seems like a case for replicating the static data
to the 32bit servers. You could use one of the built-in Replication types
or just schedule a job that runs
insert into CountryCode
select * from 64bitServer.MyDB.CountryCode
David
Saturday, February 25, 2012
64-Bit Connectivity Issues
We are migrating from a botched 64-bit SQL Server setup to a new 64-bit SQL Server Setup (One instance versus 2). Things that worked on the first server, don't work on the new. My speculation is that the AS400 drivers installation is botched, but asking for feedback.
Am running a scheduled job that simply executes an SSIS package. There is a package configuration for the connection strings to AS400 and SQL Server. The package runs fine when you run it from DTEXECUI (obviously adding configuration file to run). The job is setup exactly the same as on the original server but gets the following errors:
Side question: Why does the job history errors conflict with the SQL Server logging from the package? Very frustrating.
Job History Error (I found these to be very inaccurate in the past):
Executed as user: bfusa\mfgsql. ...rsion 9.00.3042.00 for 64-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 9:45:06 AM Error: 2007-04-11 09:45:06.76 Code: 0xC0016016 Source: Description: Failed to decrypt protected XML node "DTS
assword" with error 0x80070002 "The system cannot find the file specified.". You may not be authorized to access this information. This error occurs when there is a cryptographic error. Verify that the correct key is available. End Error Error: 2007-04-11 09:45:06.78 Code: 0xC0016016 Source: Description: Failed to decrypt protected XML node "DTS
SQL Server Package Logging:
System.InvalidOperationException: The 'IBMDA400.DataSource.1' provider is not registered on the local machine.
BTW, I tried using a cmdexec step to force it run in 32-bit mode, and still received errors. If it is in fact a driver error, why does it run fine in DTEXECUI? I know that always runs in 32-bit mode, but I tried to force a 32-bit mode also.
This might not be the answer but for that error "The system cannot find the file specified." on 64-bit I've opened the package, recompiled all my scripts, saved and ran again and it fixed it. This seems to happen less often in SP2 (or at least in SP2 you will get a warning in 32-bit mode that it is missing a binary for a script).
Based on the rest of your error message its probably not the correct answer but it can't hurt
Two issues here.
1. 32 bit vs. 64 bit package execution
The job history pasted in the message shows that the job is /was running under 64 bit. But even when that is fixed to run under 32 bit (as you apparently did in a cmdexec step) , the execution would still not initiate because of the Package Protection level property setting, which is the second issue. As to the 32 vs 64 bit package execution via dtexec, here's what is displayed when running the two versions of dtexec.exe on the x64 platform (and you can see that the job history shows a 64 bit execution attempt).
"%ProgramFiles(x86)%\Microsoft SQL Server\90\DTS\Binn\dtexec.exe"
Microsoft (R) SQL Server Execute Package Utility
Version 9.00.3042.00 for 32-bit
Copyright (C) Microsoft Corp 1984-2005. All rights reserved.
At least one of the DTS, SQL, or File options must be specified.
"%ProgramFiles%\Microsoft SQL Server\90\DTS\Binn\dtexec.exe"
Microsoft (R) SQL Server Execute Package Utility
Version 9.00.3042.00 for 64-bit
Copyright (C) Microsoft Corp 1984-2005. All rights reserved.
At least one of the DTS, SQL, or File options must be specified.
That history shows it is running under 64 bit.
2. Package protection level
Even though you modified it to run in 32 bit mode, there are still errors. These have nothing to do with that platform, but rather, the PackageProtectionLevel. This issue is discussed ( with resolutions) in the following article: http://support.microsoft.com/kb/918760
|||A reinstallation of the DB2 drivers was done and this fixed the issue.64-Bit Connectivity Issues
We are migrating from a botched 64-bit SQL Server setup to a new 64-bit SQL Server Setup (One instance versus 2). Things that worked on the first server, don't work on the new. My speculation is that the AS400 drivers installation is botched, but asking for feedback.
Am running a scheduled job that simply executes an SSIS package. There is a package configuration for the connection strings to AS400 and SQL Server. The package runs fine when you run it from DTEXECUI (obviously adding configuration file to run). The job is setup exactly the same as on the original server but gets the following errors:
Side question: Why does the job history errors conflict with the SQL Server logging from the package? Very frustrating.
Job History Error (I found these to be very inaccurate in the past):
Executed as user: bfusa\mfgsql. ...rsion 9.00.3042.00 for 64-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 9:45:06 AM Error: 2007-04-11 09:45:06.76 Code: 0xC0016016 Source: Description: Failed to decrypt protected XML node "DTS
SQL Server Package Logging:
System.InvalidOperationException: The 'IBMDA400.DataSource.1' provider is not registered on the local machine.
BTW, I tried using a cmdexec step to force it run in 32-bit mode, and still received errors. If it is in fact a driver error, why does it run fine in DTEXECUI? I know that always runs in 32-bit mode, but I tried to force a 32-bit mode also.
This might not be the answer but for that error "The system cannot find the file specified." on 64-bit I've opened the package, recompiled all my scripts, saved and ran again and it fixed it. This seems to happen less often in SP2 (or at least in SP2 you will get a warning in 32-bit mode that it is missing a binary for a script).
Based on the rest of your error message its probably not the correct answer but it can't hurt
Two issues here.
1. 32 bit vs. 64 bit package execution
The job history pasted in the message shows that the job is /was running under 64 bit. But even when that is fixed to run under 32 bit (as you apparently did in a cmdexec step) , the execution would still not initiate because of the Package Protection level property setting, which is the second issue. As to the 32 vs 64 bit package execution via dtexec, here's what is displayed when running the two versions of dtexec.exe on the x64 platform (and you can see that the job history shows a 64 bit execution attempt).
"%ProgramFiles(x86)%\Microsoft SQL Server\90\DTS\Binn\dtexec.exe"
Microsoft (R) SQL Server Execute Package Utility
Version 9.00.3042.00 for 32-bit
Copyright (C) Microsoft Corp 1984-2005. All rights reserved.
At least one of the DTS, SQL, or File options must be specified.
"%ProgramFiles%\Microsoft SQL Server\90\DTS\Binn\dtexec.exe"
Microsoft (R) SQL Server Execute Package Utility
Version 9.00.3042.00 for 64-bit
Copyright (C) Microsoft Corp 1984-2005. All rights reserved.
At least one of the DTS, SQL, or File options must be specified.
That history shows it is running under 64 bit.
2. Package protection level
Even though you modified it to run in 32 bit mode, there are still errors. These have nothing to do with that platform, but rather, the PackageProtectionLevel. This issue is discussed ( with resolutions) in the following article: http://support.microsoft.com/kb/918760
|||A reinstallation of the DB2 drivers was done and this fixed the issue.
Sunday, February 19, 2012
6.5 connectivity to 2000
Is it safe to use 6.5 connectivity on a 95 machine to
connect to a SQL 2000 installation on Win 2K?Hi,
No issues. You can execute all commands. Only demerit is that you wont get
the GUI facilities available in SQL 2000 client.
FYI, You cant use SQL 6.5 enterprise manager to connect to SQL 2000. Only
ISQLW can be used .
Hari
"Mark Walker" <anonymous@.discussions.microsoft.com> wrote in message
news:254101c3fc6a$25446c80$a101280a@.phx.gbl...
> Is it safe to use 6.5 connectivity on a 95 machine to
> connect to a SQL 2000 installation on Win 2K?|||... and since 6.5 ISQL.EXE and ISQLW.EXE uses DbLibrary, some of the new
stuff in 7.0/2000 will not be available. Such includes longer strings than
255 characters, Unicode, uniqueidentifier etc.
--
Tibor Karaszi, SQL Server MVP
Archive at:
http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"Hari" <hari_prasad_k@.hotmail.com> wrote in message
news:%2387UBvG$DHA.2520@.TK2MSFTNGP11.phx.gbl...
> Hi,
> No issues. You can execute all commands. Only demerit is that you wont get
> the GUI facilities available in SQL 2000 client.
> FYI, You cant use SQL 6.5 enterprise manager to connect to SQL 2000. Only
> ISQLW can be used .
>
> Hari
> "Mark Walker" <anonymous@.discussions.microsoft.com> wrote in message
> news:254101c3fc6a$25446c80$a101280a@.phx.gbl...
> > Is it safe to use 6.5 connectivity on a 95 machine to
> > connect to a SQL 2000 installation on Win 2K?
>
connect to a SQL 2000 installation on Win 2K?Hi,
No issues. You can execute all commands. Only demerit is that you wont get
the GUI facilities available in SQL 2000 client.
FYI, You cant use SQL 6.5 enterprise manager to connect to SQL 2000. Only
ISQLW can be used .
Hari
"Mark Walker" <anonymous@.discussions.microsoft.com> wrote in message
news:254101c3fc6a$25446c80$a101280a@.phx.gbl...
> Is it safe to use 6.5 connectivity on a 95 machine to
> connect to a SQL 2000 installation on Win 2K?|||... and since 6.5 ISQL.EXE and ISQLW.EXE uses DbLibrary, some of the new
stuff in 7.0/2000 will not be available. Such includes longer strings than
255 characters, Unicode, uniqueidentifier etc.
--
Tibor Karaszi, SQL Server MVP
Archive at:
http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"Hari" <hari_prasad_k@.hotmail.com> wrote in message
news:%2387UBvG$DHA.2520@.TK2MSFTNGP11.phx.gbl...
> Hi,
> No issues. You can execute all commands. Only demerit is that you wont get
> the GUI facilities available in SQL 2000 client.
> FYI, You cant use SQL 6.5 enterprise manager to connect to SQL 2000. Only
> ISQLW can be used .
>
> Hari
> "Mark Walker" <anonymous@.discussions.microsoft.com> wrote in message
> news:254101c3fc6a$25446c80$a101280a@.phx.gbl...
> > Is it safe to use 6.5 connectivity on a 95 machine to
> > connect to a SQL 2000 installation on Win 2K?
>
6.5 connectivity to 2000
Is it safe to use 6.5 connectivity on a 95 machine to
connect to a SQL 2000 installation on Win 2K?Hi,
No issues. You can execute all commands. Only demerit is that you wont get
the GUI facilities available in SQL 2000 client.
FYI, You cant use SQL 6.5 enterprise manager to connect to SQL 2000. Only
ISQLW can be used .
Hari
"Mark Walker" <anonymous@.discussions.microsoft.com> wrote in message
news:254101c3fc6a$25446c80$a101280a@.phx.gbl...
> Is it safe to use 6.5 connectivity on a 95 machine to
> connect to a SQL 2000 installation on Win 2K?|||... and since 6.5 ISQL.EXE and ISQLW.EXE uses DbLibrary, some of the new
stuff in 7.0/2000 will not be available. Such includes longer strings than
255 characters, Unicode, uniqueidentifier etc.
Tibor Karaszi, SQL Server MVP
Archive at:
http://groups.google.com/groups?oi=...ublic.sqlserver
"Hari" <hari_prasad_k@.hotmail.com> wrote in message
news:%2387UBvG$DHA.2520@.TK2MSFTNGP11.phx.gbl...
> Hi,
> No issues. You can execute all commands. Only demerit is that you wont get
> the GUI facilities available in SQL 2000 client.
> FYI, You cant use SQL 6.5 enterprise manager to connect to SQL 2000. Only
> ISQLW can be used .
>
> Hari
> "Mark Walker" <anonymous@.discussions.microsoft.com> wrote in message
> news:254101c3fc6a$25446c80$a101280a@.phx.gbl...
>
connect to a SQL 2000 installation on Win 2K?Hi,
No issues. You can execute all commands. Only demerit is that you wont get
the GUI facilities available in SQL 2000 client.
FYI, You cant use SQL 6.5 enterprise manager to connect to SQL 2000. Only
ISQLW can be used .
Hari
"Mark Walker" <anonymous@.discussions.microsoft.com> wrote in message
news:254101c3fc6a$25446c80$a101280a@.phx.gbl...
> Is it safe to use 6.5 connectivity on a 95 machine to
> connect to a SQL 2000 installation on Win 2K?|||... and since 6.5 ISQL.EXE and ISQLW.EXE uses DbLibrary, some of the new
stuff in 7.0/2000 will not be available. Such includes longer strings than
255 characters, Unicode, uniqueidentifier etc.
Tibor Karaszi, SQL Server MVP
Archive at:
http://groups.google.com/groups?oi=...ublic.sqlserver
"Hari" <hari_prasad_k@.hotmail.com> wrote in message
news:%2387UBvG$DHA.2520@.TK2MSFTNGP11.phx.gbl...
> Hi,
> No issues. You can execute all commands. Only demerit is that you wont get
> the GUI facilities available in SQL 2000 client.
> FYI, You cant use SQL 6.5 enterprise manager to connect to SQL 2000. Only
> ISQLW can be used .
>
> Hari
> "Mark Walker" <anonymous@.discussions.microsoft.com> wrote in message
> news:254101c3fc6a$25446c80$a101280a@.phx.gbl...
>
Subscribe to:
Posts (Atom)