May 10, 2002 at 12:41 pm
Has anyone run into any problems with using the Enterprise Manager for SQL Server 2000 to make changes on SQL Server 7.0?
One probelm I have found is that if I create or modify a DTS package using the Enterprise Manager for SQL Server 2000 then I can't view it nor schedule it using the Enerprise Manager for SQL Server 7.0. However, if I schedule it using the EM for SQL Server 2000 and then execute the job it works fine.
We are planning to add some SQL Server 2000's to our network and will be using them alongside SQL Server 7.0. Some of the 7.0 servers will have to interact with the 2000 servers and vica versa and we are trying to find out if there are any tasks that will fail or give us problems.
Specifically related to DTS packages, stored procedures, and replication.
Your experiences with mixing the two versions on the same network will be useful.
Robert Marda
Robert W. Marda
Billing and OSS Specialist - SQL Programmer
MCL Systems
May 10, 2002 at 2:12 pm
It is a known issue they addressed in SP3 for SQL 7 I do believe. And if I remeber correctly it is related to the way they encrypt the packages, it changed between versions. Here is the vague details of it from MS KB http://support.microsoft.com/default.aspx?scid=kb;en-us;Q280807 .
"Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)
May 10, 2002 at 2:49 pm
Also, does anyone know can we install the EM for SQL Server 2000 on a SQL Server 7 without upgrading the server to 2000 and without installing an instance of 2000 on that server.
The reason for wanting to do this is so that if we need to modify a DTS package (that can't be opened using EM for SQL Server 7) while logged onto the server we would be able to.
Robert Marda
Robert W. Marda
Billing and OSS Specialist - SQL Programmer
MCL Systems
May 10, 2002 at 2:58 pm
I have seen a problem with profiler but nothing with em.
May 10, 2002 at 3:00 pm
I believe that you can install the client tools, however the problem is that if that 7.0 server is less that SP3 then the DTS versions you are creating are not valid to be run by the 7.0 box. So, I would upgrade to SP3 unless you can't for some reason.
As for 2000 and 7.0 co-existing, we have a mixed bag here, about a 50 / 50 split and all is well. I have upgraded all my 7.0 servers to SP3 though as I do a lot of DTS dev work on all boxes and switching between 7.0 and 2000 tools is not an option.
Hope this helps.
David
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
May 10, 2002 at 7:30 pm
Yes your comments help. Thanks!
I have a few more questions. What kind of profiler problems did you, cjlane, encounter? We don't use it a lot, but on ocassion it is handy.
All our SQL Server 7.0's have SP3 so this should be under control. Do you, DavidB, know what happens if I use one of the tasks or connections new to SQL Server 2000 in a DTS package saved on SQL Server 7.0. Will that task run? Will anything in the DTS package run?
Robert Marda
Robert W. Marda
Billing and OSS Specialist - SQL Programmer
MCL Systems
May 10, 2002 at 9:26 pm
The package will run if it is run from a machine with the SQL2000 tools. The client tool DLLs are the ones that have these tasks. If you save the DTS package to a v7 server, it will not work because the v.7 DLLs do not have these tasks.
Steve Jones
May 11, 2002 at 10:39 am
Any features that were not available in SQL 7 DTS that were added in 2000 will not execute on SQL 7. In addition I would personally not install the 2000 client on a production SQL 7 box as you have no visual reference then to what limitations you are under and may cause yourself a headache. Altough doing elsewhere I deem just fine, IMHO, if something is an issue you should be able to go to that server and using the EM for SQL 7 be able to solve it better than you can with the 2000 client which may be the root of the issue.
"Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)
May 11, 2002 at 1:37 pm
Thanks for the suggestions. Let me explain a bit further. The SQL Server 7.0 that we want to put the EM from SQL Server 2000 on is dedicated to DTS packages used for importing and exporting data. That is the only purpose for this production server.
Robert Marda
Robert W. Marda
Billing and OSS Specialist - SQL Programmer
MCL Systems
May 11, 2002 at 7:24 pm
I understand, you may do this but I do suggest make sure you have a 7 EM running some where to check without version conflicts in the way when you have issues. As for 2000 EM I really don't see a need for this on the 7 server as it makes no enhancements to what the server can do, and the data connectors are and MDAC item unassociated with EM, but it is your choice just be sure you have a way to test without version differences in the loop is all I wanted to point out. Plus lastly unless you are real carefull about keeping in mind the incompatible items between 7 and 2000 I always suggest use a 7 EM to build DTS packages to be sure you don't spend more time than needed troubleshooting simple problems due to incompatible differences.
"Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)
May 17, 2002 at 7:30 am
Thanks Antares! I finally went and read the MS article you first recommended. I didn't read it at first because I thought it would be something similar to the article about the problems between SP2 and SP3.
I have now tested this and SQL Server 7.0 with SP3 can open a DTS Package created or modified by SQL Server 2000. So now we won't need to load EM for SQL Server on a SQL Server 7.0 server.
Robert Marda
Robert W. Marda
Billing and OSS Specialist - SQL Programmer
MCL Systems
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply