Showing posts with label windows. Show all posts
Showing posts with label windows. Show all posts

Friday, March 30, 2012

Mirroring dedicated traffic

We are using the following configuration:

2 stand alone Windows 2003 servers 64 bit.

Each have two Gig Network cards configured with different IP addresses.

Each running multiple instances of SQL Server 64.

I am trying to set up a mirror where mirroring traffic between servers will be dedicated to a secondary IP address on the second NIC.

I am also trying to avoid Windows authentication.

Interesting enough: Security Configuration screen suggesting you to use fully qualified TCP addresses and, at the same time, does not give you such an option...

Would someone please point me in the right direction?

Thank you.

Use certificate authentication. Look up "database mirroring [SQL Server], certificates" in Books Online.|||

Thank you very much for your response.

That is definetely a lot of information.

As about "database mirroring, certificates" - there is no such a topic in BOL. There is a "Setting Up database mirroring using certificates (Transact SQL)". That is a great topic! However, I thought that my question was specific? Sorry if not. I asked about dedicating NIC No.2 to a traffic generated by mirroring process. Unfortunately, topic mentioned by you does not have anything about TCP/IP; adding port numbers and/or netowrk cards to the mirror. (Actually, it is roughly covering even the main topic since witness installation totally skipped).

And if we will go here: http://www.microsoft.com/technet/prodtechnol/sql/2005/dbmirfaq.mspx and go down to the networking section we will read a great article:

Q.

How do I specify a specific network adapter/network just for mirroring?

A.

Use multiple network adapters in the server. For the network adapter that you want to dedicate to mirroring, associate a specific IP address to that adapter. Then, associate a particular name to that IP address. Use that particular name when you set up database mirroring.

I can' believe that nobody didn't get to the point where he will have several NICs on the server? Is it such an exclusive installation?

|||

Thank you for all your help.

Resolved.

|||Is another way to do this just to change the hosts file on the Servers to point to the other network address as opposed changing the name?|||

You can simply bind the mirroring endpoint to listen only on the dedicated NIC's IP. This will apply to outgoing traffic as well as incomming.

alter endpoint [endpointname] as TCP (listener_ip = (<4 part ip of dedicated NIC>));

|||

Mark,

simple 'on surface' type of decision is not always a correct one. What is the sense in certificate based security and ecryption if you are exposing your DB network structure ? Wouldn't it be a security risk?

|||

Sorry, Remus.

I marked your response as an answer. It is incorrect though. (I am novice here and do not know how to reverse it).

There is one endpoint per instance. Then all traffic: 1. Database requests from a client application and 2. mirroring traffic are going through the same endpoint. As such altering endpoint will redirect all the traffic. Question was; how to separate the mirroring traffic through a separate NIC?

And solution is:

ALTER DATABASE [DB] SET PARTNER = 'TCP://<4part.IP.address>:<port_number>'

repeating this statement on both partners (principle and mirror) and then submitting

ALTER DATABASE SET [DB] WITNESS= 'TCP://<4part.IP.address>:<port_number>'

on principle or on mirror.

|||

I though you want to separate mirroring traffic from user connections traffic (TDS). Separting witness traffic from partner traffic is somehow unusual considering that connectivity with the witness is just as important as connectivity with the partner, otherwise why have a witness in the first place?

HTH,
~ Remus

|||

Glen Sidelnikov wrote:

There is one endpoint per instance. Then all traffic: 1. Database requests from a client application and 2. mirroring traffic are going through the same endpoint. As such altering endpoint will redirect all the traffic.

There are many enpoints in an instance: user connection endpoints (shared memory, named pipes, TCP), mirroring endpoint, service broker endpoint, HTTP enpoints. The settings for mirroring endpoint and user endpoints are distinct, therefore you can set the user endpoints (TDS listenning port) on one NIC and the mirroring endpoint on another NIC.

Another way to achieve this is to listen on all NICs, but rely on underlying IP to choose the appropiate NIC. That is, set the partner/witness names to a name that is only reachable through the desired NIC.

HTH,
~ Remus

sql

Mirroring dedicated traffic

We are using the following configuration:

2 stand alone Windows 2003 servers 64 bit.

Each have two Gig Network cards configured with different IP addresses.

Each running multiple instances of SQL Server 64.

I am trying to set up a mirror where mirroring traffic between servers will be dedicated to a secondary IP address on the second NIC.

I am also trying to avoid Windows authentication.

Interesting enough: Security Configuration screen suggesting you to use fully qualified TCP addresses and, at the same time, does not give you such an option...

Would someone please point me in the right direction?

Thank you.

Use certificate authentication. Look up "database mirroring [SQL Server], certificates" in Books Online.|||

Thank you very much for your response.

That is definetely a lot of information.

As about "database mirroring, certificates" - there is no such a topic in BOL. There is a "Setting Up database mirroring using certificates (Transact SQL)". That is a great topic! However, I thought that my question was specific? Sorry if not. I asked about dedicating NIC No.2 to a traffic generated by mirroring process. Unfortunately, topic mentioned by you does not have anything about TCP/IP; adding port numbers and/or netowrk cards to the mirror. (Actually, it is roughly covering even the main topic since witness installation totally skipped).

And if we will go here: http://www.microsoft.com/technet/prodtechnol/sql/2005/dbmirfaq.mspx and go down to the networking section we will read a great article:

Q.

How do I specify a specific network adapter/network just for mirroring?

A.

Use multiple network adapters in the server. For the network adapter that you want to dedicate to mirroring, associate a specific IP address to that adapter. Then, associate a particular name to that IP address. Use that particular name when you set up database mirroring.

I can' believe that nobody didn't get to the point where he will have several NICs on the server? Is it such an exclusive installation?

|||

Thank you for all your help.

Resolved.

|||Is another way to do this just to change the hosts file on the Servers to point to the other network address as opposed changing the name?|||

You can simply bind the mirroring endpoint to listen only on the dedicated NIC's IP. This will apply to outgoing traffic as well as incomming.

alter endpoint [endpointname] as TCP (listener_ip = (<4 part ip of dedicated NIC>));

|||

Mark,

simple 'on surface' type of decision is not always a correct one. What is the sense in certificate based security and ecryption if you are exposing your DB network structure ? Wouldn't it be a security risk?

|||

Sorry, Remus.

I marked your response as an answer. It is incorrect though. (I am novice here and do not know how to reverse it).

There is one endpoint per instance. Then all traffic: 1. Database requests from a client application and 2. mirroring traffic are going through the same endpoint. As such altering endpoint will redirect all the traffic. Question was; how to separate the mirroring traffic through a separate NIC?

And solution is:

ALTER DATABASE [DB] SET PARTNER = 'TCP://<4part.IP.address>:<port_number>'

repeating this statement on both partners (principle and mirror) and then submitting

ALTER DATABASE SET [DB] WITNESS= 'TCP://<4part.IP.address>:<port_number>'

on principle or on mirror.

|||

I though you want to separate mirroring traffic from user connections traffic (TDS). Separting witness traffic from partner traffic is somehow unusual considering that connectivity with the witness is just as important as connectivity with the partner, otherwise why have a witness in the first place?

HTH,
~ Remus

|||

Glen Sidelnikov wrote:

There is one endpoint per instance. Then all traffic: 1. Database requests from a client application and 2. mirroring traffic are going through the same endpoint. As such altering endpoint will redirect all the traffic.

There are many enpoints in an instance: user connection endpoints (shared memory, named pipes, TCP), mirroring endpoint, service broker endpoint, HTTP enpoints. The settings for mirroring endpoint and user endpoints are distinct, therefore you can set the user endpoints (TDS listenning port) on one NIC and the mirroring endpoint on another NIC.

Another way to achieve this is to listen on all NICs, but rely on underlying IP to choose the appropiate NIC. That is, set the partner/witness names to a name that is only reachable through the desired NIC.

HTH,
~ Remus

Wednesday, March 21, 2012

Minimium persmissions needed to Restore a DB

Hi,
I'm trying to set a domain group who connect using Windows authentication,
so that they can restore a database, i have read books online and do not
want to add them to the sysadmin and dbcreator fixed server roles.
I can see that the dbcreator fixed server role has a permission 'RESTORE
DATABASE', is it possible to grant this permission on a single database on
the server alone ?
Thanks in advance
PatNo...you can't assign this for a single database.
-Sue
On Tue, 23 Sep 2003 09:04:42 +0100, "pmcg"
<pat@.nospam.nospam.com> wrote:
>Hi,
>I'm trying to set a domain group who connect using Windows authentication,
>so that they can restore a database, i have read books online and do not
>want to add them to the sysadmin and dbcreator fixed server roles.
>I can see that the dbcreator fixed server role has a permission 'RESTORE
>DATABASE', is it possible to grant this permission on a single database on
>the server alone ?
>
>Thanks in advance
>Pat
>

Monday, March 12, 2012

Mimic SQL Server environment

I have SQL Server 2000 installed on Windows 2003 server. SQL Server
environment was set up about a year ago. I would like to known all of the
items I need to look at on SQL Server to mimic this environment. I have
started with SQL Server configuration (sp_Configure).
What items am I missing to mimic SQL Server?
Thanks,
Depends on what you mean by mimic...
You might wish to ensure the IO subsystems are the same.
You might wish to ensure each database is set up similary in physical
structure as well as attributes ( sp_dboption)
You might with to ensure the logins match. ( look in books on line for log
shipping and there is a document about how to make the warm standby the
production server. It includes a section on making the logins and users
match.)
Think about whether replication needs to be matched.
Think about sql agent jobs, etc ( included in msdb).
Hope this helps...
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Mark T." <Mark T.@.discussions.microsoft.com> wrote in message
news:D76C7697-5336-494A-ADA5-ABC75B7AB421@.microsoft.com...
> I have SQL Server 2000 installed on Windows 2003 server. SQL Server
> environment was set up about a year ago. I would like to known all of the
> items I need to look at on SQL Server to mimic this environment. I have
> started with SQL Server configuration (sp_Configure).
> What items am I missing to mimic SQL Server?
> Thanks,

Mimic SQL Server environment

I have SQL Server 2000 installed on Windows 2003 server. SQL Server
environment was set up about a year ago. I would like to known all of the
items I need to look at on SQL Server to mimic this environment. I have
started with SQL Server configuration (sp_Configure).
What items am I missing to mimic SQL Server?
Thanks,Depends on what you mean by mimic...
You might wish to ensure the IO subsystems are the same.
You might wish to ensure each database is set up similary in physical
structure as well as attributes ( sp_dboption)
You might with to ensure the logins match. ( look in books on line for log
shipping and there is a document about how to make the warm standby the
production server. It includes a section on making the logins and users
match.)
Think about whether replication needs to be matched.
Think about sql agent jobs, etc ( included in msdb).
Hope this helps...
--
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Mark T." <Mark T.@.discussions.microsoft.com> wrote in message
news:D76C7697-5336-494A-ADA5-ABC75B7AB421@.microsoft.com...
> I have SQL Server 2000 installed on Windows 2003 server. SQL Server
> environment was set up about a year ago. I would like to known all of the
> items I need to look at on SQL Server to mimic this environment. I have
> started with SQL Server configuration (sp_Configure).
> What items am I missing to mimic SQL Server?
> Thanks,

Mimic SQL Server environment

I have SQL Server 2000 installed on Windows 2003 server. SQL Server
environment was set up about a year ago. I would like to known all of the
items I need to look at on SQL Server to mimic this environment. I have
started with SQL Server configuration (sp_Configure).
What items am I missing to mimic SQL Server?
Thanks,Depends on what you mean by mimic...
You might wish to ensure the IO subsystems are the same.
You might wish to ensure each database is set up similary in physical
structure as well as attributes ( sp_dboption)
You might with to ensure the logins match. ( look in books on line for log
shipping and there is a document about how to make the warm standby the
production server. It includes a section on making the logins and users
match.)
Think about whether replication needs to be matched.
Think about sql agent jobs, etc ( included in msdb).
Hope this helps...
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Mark T." <Mark T.@.discussions.microsoft.com> wrote in message
news:D76C7697-5336-494A-ADA5-ABC75B7AB421@.microsoft.com...
> I have SQL Server 2000 installed on Windows 2003 server. SQL Server
> environment was set up about a year ago. I would like to known all of the
> items I need to look at on SQL Server to mimic this environment. I have
> started with SQL Server configuration (sp_Configure).
> What items am I missing to mimic SQL Server?
> Thanks,

Friday, March 9, 2012

Migration to MySQL?

From a "price point of view" migrating from the actual platform (2 node
cluster Windows server 2003 with SQL Server 2000 Enterprise Edition)to MySQL
can be very attractive.
In fact our management starts to think that way...
My question is related to the faisability of this operation in a critical
production cluster server.
Is it recommanded?
Pros and Cons?
Why yes and why no.
Please advise.
Franco
It is difficult to answer this type of questions rigorously in a newsgroup
forum. I'd suggest that you invole all the stakeholders and conduct a
comparative risk analysis on the migration. The compartive risk analysis
should cover the key risk factors that are important to your organizaton.
Note that cost factors are but one category among many others.
Some of risk factors to consider include reliability and resilience (e.g.
high availability, stability of the DBMS, proven platform, etc), scalability
and performance (e.g. scalability in terms of database size, # of processors,
memory size, partitioning, index maintenance, etc), manageability (e.g. ease
of backup/restore), operations issus (e.g. need for consistency checks,
availability of expetise, monitoring tools, etc), portfolio impact (e.g. what
is the mix of your installed DBMS and apps using various DBMS, dependencies
among the databases, etc), and supportability (e.g. vendor support, user
community, etc). Obviously, you would have to rate these and other factors
per their relative importance to your apps and organization.
Linchi
"Franco" wrote:

> From a "price point of view" migrating from the actual platform (2 node
> cluster Windows server 2003 with SQL Server 2000 Enterprise Edition)to MySQL
> can be very attractive.
> In fact our management starts to think that way...
> My question is related to the faisability of this operation in a critical
> production cluster server.
> Is it recommanded?
> Pros and Cons?
> Why yes and why no.
> Please advise.
> --
> Franco

Migration of SQLServer user databases to another SQLServer

Guys,
I would like to migrate a number of user databases from one SQLSERVER (name:
LECOMMS02 - Windows NT - 5.0(2195), SQLServer 8.00.534(SP2)) to another (na
me: LEPIV01 - Windows NT - 5.0(2195), SQLServer 8.00.780(SP3)).
Please can you outline the steps involved and any pitfalls I should watch fo
r? I am new to SQLServer and this is live data. This needs completing today
as well!!
TIA, KenKen,
Have a look at:
INF: Moving SQL Server databases to a new location with Detach/Attach
http://support.microsoft.com/defaul...kb;EN-US;224071
Mark Allison, SQL Server MVP
Ken Jones wrote:

> Guys,
> I would like to migrate a number of user databases from one SQLSERVER (nam
e: LECOMMS02 - Windows NT - 5.0(2195), SQLServer 8.00.534(SP2)) to another (
name: LEPIV01 - Windows NT - 5.0(2195), SQLServer 8.00.780(SP3)).
> Please can you outline the steps involved and any pitfalls I should watch
for? I am new to SQLServer and this is live data. This needs completing toda
y as well!!
> TIA, Ken
>
Mark Allison, SQL Server MVP
http://www.allisonmitchell.com|||Hi,
Since you need to upgrade only the user databases you can do one of the
folowing
1. Detach and Attach databases
2. Backup and Restore the databases
1. Detach and Attach
a. Use SP_DETACH_DB to detach the MDF and LDF files
b. Copy the files to Destination server
c. Use SP_ATTACH_DB to attach the databases
(Refer books online for information)
2. Backup and Restore
a. Backup the source databases using BACKUP DATABASE command
b. Copy the .BAK files to destination
c. Restore the database using RESTORE DATABASE command
After this steps you may need to move the logins from source server to
destination server.
Have a look into the below link for information.
http://www.databasejournal.com/feat...cle.php/2228611
Thanks
Hari
MCDBA
"Ken Jones" <anonymous@.discussions.microsoft.com> wrote in message
news:1442724A-12BF-4AF2-8A02-B558DCA60658@.microsoft.com...
> Guys,
> I would like to migrate a number of user databases from one SQLSERVER
(name: LECOMMS02 - Windows NT - 5.0(2195), SQLServer 8.00.534(SP2)) to
another (name: LEPIV01 - Windows NT - 5.0(2195), SQLServer 8.00.780(SP3)).
> Please can you outline the steps involved and any pitfalls I should watch
for? I am new to SQLServer and this is live data. This needs completing
today as well!!
> TIA, Ken
>|||Mark,
So I can detach (using sp_detach) from the source database, ftp to new serve
r and then attach (using sp_attach)'
Is that all there is to it? Will the sp_attach alert master as to the appear
ance of x number of new user databases as I am moving from one SQLServer (li
ve) to a completely different, functioning SQLServer(live)?
TIA, Ken.|||Thanks for your swift replies - WOW!!|||Hi Hari,
Some of my files are .DAT files. Will this affect the detach and attach proc
ess?
TIA, Ken|||DAT files could mean they are 6.5 database files. You can't move such across
to 7.0/2000. You need to have those databases available in a 6.5 install and
use the upgrade wizard from there.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Ken Jones" <anonymous@.discussions.microsoft.com> wrote in message
news:40772738-BE5B-4C98-86D9-DE1DB7959FFB@.microsoft.com...
> Hi Hari,
> Some of my files are .DAT files. Will this affect the detach and attach
process?
> TIA, Ken|||"I would like to migrate a number of user databases from one SQLSERVER (name
: LECOMMS02 - Windows NT - 5.0(2195), SQLServer 8.00.534(SP2)) to another (n
ame: LEPIV01 - Windows NT - 5.0(2195), SQLServer 8.00.780(SP3))."
Both are SQLServer8 servers. I am going to try the sp_detach_db and sp_attac
h_db by ftp'ing the LDF and MDF files. I'll see if this works.
Ken|||OK I just mentioned the 6.5 stuff because in 6.5 DAT were the default
extension for both database and backup files.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Ken Jones" <anonymous@.discussions.microsoft.com> wrote in message
news:63CF9224-D4BF-4550-AF7E-4B139C9C1E69@.microsoft.com...
> "I would like to migrate a number of user databases from one SQLSERVER
(name: LECOMMS02 - Windows NT - 5.0(2195), SQLServer 8.00.534(SP2)) to
another (name: LEPIV01 - Windows NT - 5.0(2195), SQLServer 8.00.780(SP3))."
> Both are SQLServer8 servers. I am going to try the sp_detach_db and
sp_attach_db by ftp'ing the LDF and MDF files. I'll see if this works.
> Ken

Migration of Sql Server 7

Hi All,
Greetings,

We have
sql server 7
Sqlserver ServicePack SP3
Sort Order = 32
BuildNumber 7.00.961

on Windows NT,Now we are planning to upgrade operating system from win NT machine to windows 2000.
Please let me know what and all precausion do i need to take what and what all backup should be done apart from user database.
How do i take care of the users,logins,roles, DTS Job and Replication.

Please help me in this and also any links if u have on this topic

Waiting for reply
TIA
AdilWill you also be upgrading to SQL 2000 ?

When I moved to a new machine, we shut down SQL Server on both boxes, copied the database files to the new server and then started SQL Server. Because you are moving master you get all the login id's, etc. Just make sure you are running the same version of SQL server, otherwise it can get complicated.|||yes we are running the same version of SQL server.
pls suggest how do i go about it.

Thanks for ur reply

TIA
Adil

Wednesday, March 7, 2012

Migration from SQL7 to SQL2000

Hi, here is my delema, I have SQL 7 running on a NT4 box and I want to move
my databases over to a SQL 2000 Windows 2003 server. What is the best metho
d. These are two different boxes. Any help is greatly appreciated.
Scott KeeganHave a look here:
http://msdn.microsoft.com/SQL/sqlmi...ta/default.aspx
Andrew J. Kelly SQL MVP
"Scott Keegan" <Scott Keegan@.discussions.microsoft.com> wrote in message
news:3097FD7A-8F81-4BB9-A161-DE24A2FD40F6@.microsoft.com...
> Hi, here is my delema, I have SQL 7 running on a NT4 box and I want to
move my databases over to a SQL 2000 Windows 2003 server. What is the best
method. These are two different boxes. Any help is greatly appreciated.
> Scott Keegan|||Scott
Install SQL Server on Widows 2003 and perfom RESTORE all users databases.
It might be a collation conflict but since SQL Server 2000 you can change it
even per column.
"Scott Keegan" <Scott Keegan@.discussions.microsoft.com> wrote in message
news:3097FD7A-8F81-4BB9-A161-DE24A2FD40F6@.microsoft.com...
> Hi, here is my delema, I have SQL 7 running on a NT4 box and I want to
move my databases over to a SQL 2000 Windows 2003 server. What is the best
method. These are two different boxes. Any help is greatly appreciated.
> Scott Keegan|||Hi,
Migration from SQl 7 to SQl 2000 is straight forward, you can BACKUP and
RESTORE or use
sp_detach_db and sp_attach_db.
You could also probably also use the upgrade wizard .
Look into the below KB articles related to migration:
move the data via backup and restore
http://support.microsoft.com/defaul...b;en-us;Q304692
sp_detach_db and sp_attach_db
http://support.microsoft.com/suppor...s/q224/0/71.asp
one more option -- the copy database wizard
http://support.microsoft.com/defaul...b;en-us;Q274463
PRB: User Logon and/or Permission Errors After Restoring Dump (Q168001)
http://support.microsoft.com/defaul...b;en-us;Q168001
Thanks
Hari
MCDBA
"Scott Keegan" <Scott Keegan@.discussions.microsoft.com> wrote in message
news:3097FD7A-8F81-4BB9-A161-DE24A2FD40F6@.microsoft.com...
> Hi, here is my delema, I have SQL 7 running on a NT4 box and I want to
move my databases over to a SQL 2000 Windows 2003 server. What is the best
method. These are two different boxes. Any help is greatly appreciated.
> Scott Keegan

Migration from SQL7 to SQL2000

Hi, here is my delema, I have SQL 7 running on a NT4 box and I want to move my databases over to a SQL 2000 Windows 2003 server. What is the best method. These are two different boxes. Any help is greatly appreciated.
Scott Keegan
Have a look here:
http://msdn.microsoft.com/SQL/sqlmig...a/default.aspx
Andrew J. Kelly SQL MVP
"Scott Keegan" <Scott Keegan@.discussions.microsoft.com> wrote in message
news:3097FD7A-8F81-4BB9-A161-DE24A2FD40F6@.microsoft.com...
> Hi, here is my delema, I have SQL 7 running on a NT4 box and I want to
move my databases over to a SQL 2000 Windows 2003 server. What is the best
method. These are two different boxes. Any help is greatly appreciated.
> Scott Keegan
|||Scott
Install SQL Server on Widows 2003 and perfom RESTORE all users databases.
It might be a collation conflict but since SQL Server 2000 you can change it
even per column.
"Scott Keegan" <Scott Keegan@.discussions.microsoft.com> wrote in message
news:3097FD7A-8F81-4BB9-A161-DE24A2FD40F6@.microsoft.com...
> Hi, here is my delema, I have SQL 7 running on a NT4 box and I want to
move my databases over to a SQL 2000 Windows 2003 server. What is the best
method. These are two different boxes. Any help is greatly appreciated.
> Scott Keegan
|||Hi,
Migration from SQl 7 to SQl 2000 is straight forward, you can BACKUP and
RESTORE or use
sp_detach_db and sp_attach_db.
You could also probably also use the upgrade wizard .
Look into the below KB articles related to migration:
move the data via backup and restore
http://support.microsoft.com/default...;en-us;Q304692
sp_detach_db and sp_attach_db
http://support.microsoft.com/support.../q224/0/71.asp
one more option -- the copy database wizard
http://support.microsoft.com/default...;en-us;Q274463
PRB: User Logon and/or Permission Errors After Restoring Dump (Q168001)
http://support.microsoft.com/default...;en-us;Q168001
Thanks
Hari
MCDBA
"Scott Keegan" <Scott Keegan@.discussions.microsoft.com> wrote in message
news:3097FD7A-8F81-4BB9-A161-DE24A2FD40F6@.microsoft.com...
> Hi, here is my delema, I have SQL 7 running on a NT4 box and I want to
move my databases over to a SQL 2000 Windows 2003 server. What is the best
method. These are two different boxes. Any help is greatly appreciated.
> Scott Keegan

Migration from SQL7 to SQL2000

Hi, here is my delema, I have SQL 7 running on a NT4 box and I want to move my databases over to a SQL 2000 Windows 2003 server. What is the best method. These are two different boxes. Any help is greatly appreciated.
Scott KeeganHave a look here:
http://msdn.microsoft.com/SQL/sqlmigratingdata/default.aspx
--
Andrew J. Kelly SQL MVP
"Scott Keegan" <Scott Keegan@.discussions.microsoft.com> wrote in message
news:3097FD7A-8F81-4BB9-A161-DE24A2FD40F6@.microsoft.com...
> Hi, here is my delema, I have SQL 7 running on a NT4 box and I want to
move my databases over to a SQL 2000 Windows 2003 server. What is the best
method. These are two different boxes. Any help is greatly appreciated.
> Scott Keegan|||Scott
Install SQL Server on Widows 2003 and perfom RESTORE all users databases.
It might be a collation conflict but since SQL Server 2000 you can change it
even per column.
"Scott Keegan" <Scott Keegan@.discussions.microsoft.com> wrote in message
news:3097FD7A-8F81-4BB9-A161-DE24A2FD40F6@.microsoft.com...
> Hi, here is my delema, I have SQL 7 running on a NT4 box and I want to
move my databases over to a SQL 2000 Windows 2003 server. What is the best
method. These are two different boxes. Any help is greatly appreciated.
> Scott Keegan|||Hi,
Migration from SQl 7 to SQl 2000 is straight forward, you can BACKUP and
RESTORE or use
sp_detach_db and sp_attach_db.
You could also probably also use the upgrade wizard .
Look into the below KB articles related to migration:
move the data via backup and restore
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q304692
sp_detach_db and sp_attach_db
http://support.microsoft.com/support/kb/articles/q224/0/71.asp
one more option -- the copy database wizard
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q274463
PRB: User Logon and/or Permission Errors After Restoring Dump (Q168001)
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q168001
Thanks
Hari
MCDBA
"Scott Keegan" <Scott Keegan@.discussions.microsoft.com> wrote in message
news:3097FD7A-8F81-4BB9-A161-DE24A2FD40F6@.microsoft.com...
> Hi, here is my delema, I have SQL 7 running on a NT4 box and I want to
move my databases over to a SQL 2000 Windows 2003 server. What is the best
method. These are two different boxes. Any help is greatly appreciated.
> Scott Keegan|||Is there a priority order on a where clause? Or does SQL check all of the
where clause conditions all of the time? I have a case where I can,
sometimes, hit non-numeric data in a column (caused by some bad
conversions). Right now we have the following where clause:
WHERE convert(integer, ?) BETWEEN convert(integer, low_street_num) AND
convert(integer, high_street_num)
AND (street_name = ? OR street_alias_name = ?)
AND city = ?
AND state_cd = ?
AND zip_cd LIKE ?
AND (juris_cd = ? OR juris_cd IS NULL)
AND (side = ? OR side = 'B')
AND status_cd = 'A'
AND (side = ? OR side = 'B')
AND status_cd = 'A'
I am wondering if we were to change to put the status_cd = 'A' first would
the query skip all entries whose status_cd is not 'A' and not even try to do
the convert(integer) statement at all? Or is it going to try to do the
convert(integer) regardless and my only solution is to make some routine to
fix the non-numeric data or adjust this sql to ensure the data is numeric
before trying to do the convert?
Edward Fultz
Sr. Software Engineer
Pamet Systems
Acton, Ma
www.pametsystems.com|||You cannot trust SQL Server to not hit the bad rows. Not even by pushing the filter inside a derived
table. I've been there. Put the stuff in a temp table and work against that.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Ed Fultz" <efultz@.yahoo.com> wrote in message news:O6blHRSWEHA.4056@.TK2MSFTNGP11.phx.gbl...
> Is there a priority order on a where clause? Or does SQL check all of the
> where clause conditions all of the time? I have a case where I can,
> sometimes, hit non-numeric data in a column (caused by some bad
> conversions). Right now we have the following where clause:
> WHERE convert(integer, ?) BETWEEN convert(integer, low_street_num) AND
> convert(integer, high_street_num)
> AND (street_name = ? OR street_alias_name = ?)
> AND city = ?
> AND state_cd = ?
> AND zip_cd LIKE ?
> AND (juris_cd = ? OR juris_cd IS NULL)
> AND (side = ? OR side = 'B')
> AND status_cd = 'A'
> AND (side = ? OR side = 'B')
> AND status_cd = 'A'
> I am wondering if we were to change to put the status_cd = 'A' first would
> the query skip all entries whose status_cd is not 'A' and not even try to do
> the convert(integer) statement at all? Or is it going to try to do the
> convert(integer) regardless and my only solution is to make some routine to
> fix the non-numeric data or adjust this sql to ensure the data is numeric
> before trying to do the convert?
>
> --
> Edward Fultz
> Sr. Software Engineer
> Pamet Systems
> Acton, Ma
> www.pametsystems.com
>|||You should be careful to test such a migration thoroughly:
We had a system running on MSSQL7 (MSDE) that we migrated
to MSSQL2000 Ent.Ed.
Restore finished fine, program seemded to run, but after
some days it crashed. Then nothing and then again. We
found out the following:
We built up SQL statements so string values were given as
char(65)+char(66)+...
Now, this sometimes produced queries as big as 8-9kB,
which MSSQL7 handled fine.
MSSQL2000, however, gave sql parse error. This shouldn't
be a problem until the length of the query reaches ~100kB.
Local Microsoft wanted to make this work badly, but
couldn't do it. We had to backtrack to MSSQL7.
>--Original Message--
>Hi, here is my delema, I have SQL 7 running on a NT4 box
and I want to move my databases over to a SQL 2000 Windows
2003 server. What is the best method. These are two
different boxes. Any help is greatly appreciated.
>Scott Keegan
>.
>

Migration from SQl anywhere to SQl server 2000

I am using SQL Anywhere (database which comes with
powerbuilder) on Windows 2000 Server. I am migrating from
Sqlanywhere to sql server 2000. Will there be any problem
if I install MS SQl Server 2000 on Windwos 2000 server
with sql anywher already in that.<anonymous@.discussions.microsoft.com> wrote in message news:<1285f01c3f677$31a8c0f0$a001
280a@.phx.gbl>...
> I am using SQL Anywhere (database which comes with
> powerbuilder) on Windows 2000 Server. I am migrating from
> Sqlanywhere to sql server 2000. Will there be any problem
> if I install MS SQl Server 2000 on Windwos 2000 server
> with sql anywher already in that.
Hi,
You should not have any problems having SQL Anywhere and MS
SQL Server together on Windows 2000 server.
PK
SCPBDA7
SCJP 2
SCWCD

Saturday, February 25, 2012

Migration Assistant For Access Can''t Find SQL Database?

I've installed SQL 2005 Express Addition which created a default database using Windows Authentication -- MachineName/SQLEXPRES. I want to convert some access databases to sql server in the migration assistant, however, when I try to connect the migration assistant to the default database I can't find the database in the drop down box wizard? I'm perplexed? Please shed some light or point me to some articles that will help. Thanks.

It is not practical to use standard Express to migrate Access so see if you can use the one with Management Studio instead, this will give you control of all the steps. Hope this helps.

http://msdn.microsoft.com/vstudio/express/sql/download/

|||

Yes, Management Studio is the one I used. I am able to connect via Management Studio, however, the Migration Assistant can't locate it? Looking for other suggestions? Thanks.

|||

Try the eval good for 6 months, you could buy the developer for under $40 online if you have the ram this can help you move Access if all you have is tables and queries. If you have VBA you may need professional help. I have seen Access migration taking six months or more because it lets users add stuff SQL Server will not accept and it uses limited data types.


http://www.microsoft.com/sql/downloads/trial-software.mspx

|||

I'm not sure I understand what you mean by "default database" in this context. SQL Server does not create any default databases when you install it.

In my use of SSMS I find that the drop down box that show the database name does not actually show the list of databases in the server because it has not actually connected to the server yet, so it can not list the databases. You can either specify a new database to be created or specify an existing database to open once you connect, but you need to type the name of the database, it won't populate the list for you.

Regards,

Mike

Monday, February 20, 2012

Migrating to SQL 2003

We are running SQL 7, using Access 2000 as a front end. Our network person
is wanting to migrate to Windows 2003 (we're currently on Windows 2000), and
wants to know if we should migrate to SQL 2003 at the same time. Are there
major changes between SQL 7 and SQL 2003, and how hard of a task would it be
to migrate our single database to a new version of SQL?
Thanks,
Neil
Hi
You would be better to migrate to SQL 2005! Adding this migration will
increase the number of potential issues, but if you test it thoroughly then
you should be ok.
Check out the SQL 2005 Upgrade Advisor
http://www.microsoft.com/downloads/d...displaylang=en
and upgrade handbook
http://www.microsoft.com/technet/pro.../sqlupgrd.mspx
John
"Neil" wrote:

> We are running SQL 7, using Access 2000 as a front end. Our network person
> is wanting to migrate to Windows 2003 (we're currently on Windows 2000), and
> wants to know if we should migrate to SQL 2003 at the same time. Are there
> major changes between SQL 7 and SQL 2003, and how hard of a task would it be
> to migrate our single database to a new version of SQL?
> Thanks,
> Neil
>
>
|||Ummm, do you want to migrate to SQL 2000 or SQL 2005?
MC
"Neil" <nospam@.nospam.net> wrote in message
news:Y_anf.2725$QQ1.23@.newsread3.news.pas.earthlin k.net...
> We are running SQL 7, using Access 2000 as a front end. Our network person
> is wanting to migrate to Windows 2003 (we're currently on Windows 2000),
> and wants to know if we should migrate to SQL 2003 at the same time. Are
> there major changes between SQL 7 and SQL 2003, and how hard of a task
> would it be to migrate our single database to a new version of SQL?
> Thanks,
> Neil
>
|||Neil (nospam@.nospam.net) writes:
> We are running SQL 7, using Access 2000 as a front end. Our network
> person is wanting to migrate to Windows 2003 (we're currently on Windows
> 2000), and wants to know if we should migrate to SQL 2003 at the same
> time. Are there major changes between SQL 7 and SQL 2003, and how hard
> of a task would it be to migrate our single database to a new version of
> SQL?
There is no SQL 2003. There is SQL 2000 which is very mature now, and
there is SQL 2005 which was released just over a month ago.
While there are vast improvements in SQL 2005 over SQL 2000, migrating
your database to SQL 2005 can very well be a simple task, although there
are some incompatibilities, particularly if you head for compatibility
level 90 (which I recommend).
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx
|||Hi, Erland. Thanks for your reply. Given the incompatibilities between SQL
2005 and SQL 97, do you think it would be wise to just upgrade to SQL 2000?
Also, any ideas about which one might be better suited for Windows 2003
and/or an ODBC environment (using Access MDB as a front end)? Thanks!
Neil
"Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
news:Xns972AE1D20309BYazorman@.127.0.0.1...
> Neil (nospam@.nospam.net) writes:
> There is no SQL 2003. There is SQL 2000 which is very mature now, and
> there is SQL 2005 which was released just over a month ago.
> While there are vast improvements in SQL 2005 over SQL 2000, migrating
> your database to SQL 2005 can very well be a simple task, although there
> are some incompatibilities, particularly if you head for compatibility
> level 90 (which I recommend).
>
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/pro...ads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodinf...ons/books.mspx
|||Neil (nospam@.nospam.net) writes:
> Hi, Erland. Thanks for your reply. Given the incompatibilities between
> SQL 2005 and SQL 97, do you think it would be wise to just upgrade to
> SQL 2000? Also, any ideas about which one might be better suited for
> Windows 2003 and/or an ODBC environment (using Access MDB as a front
> end)? Thanks!
SQL 97? Do you mean Access 97?
I can't give any advice that involves Access as this is an unknown product
to me.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx
|||On Thu, 26 Jan 2006 05:02:36 GMT, Neil wrote:

>Hi, Erland. Thanks for your reply. Given the incompatibilities between SQL
>2005 and SQL 97, do you think it would be wise to just upgrade to SQL 2000?
>Also, any ideas about which one might be better suited for Windows 2003
>and/or an ODBC environment (using Access MDB as a front end)? Thanks!
>Neil
Hi Neil,
If you're upgrading anyway (whether from SQL 7 or fram Access 97, I
don't know), then I'd recommend you to go for SQL 2005. Every upgrade
you ever do will require you to deal with SOME incompatibilities. But
from SQL 7 to SQL 2005 should be relatively easy. (From Access [any
version] to SQL Server [any version] might be more trouble).
The payoff will be bigger if you go straight for 2005 - especially when
you start using the new features. Plus you'll be settled for some time
to come!
Hugo Kornelis, SQL Server MVP
|||I meant SQL 7.
I'm mainly looking for advice re. compatibility with Windows 2003, and
possibly ODBC environments.
Thanks.
"Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
news:Xns9757815ED3247Yazorman@.127.0.0.1...
> Neil (nospam@.nospam.net) writes:
> SQL 97? Do you mean Access 97?
> I can't give any advice that involves Access as this is an unknown product
> to me.
>
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/pro...ads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodinf...ons/books.mspx
|||Hi, Hugo. Thanks for the reply. See below.
"Hugo Kornelis" <hugo@.perFact.REMOVETHIS.info> wrote in message
news:1kcit1hfo208tb1pr1quci8o43ob8g1d1s@.4ax.com...
> On Thu, 26 Jan 2006 05:02:36 GMT, Neil wrote:
>
> Hi Neil,
> If you're upgrading anyway (whether from SQL 7 or fram Access 97, I
> don't know),
It's from SQL 7. We are currently using Access with a SQL 7 back end.

> then I'd recommend you to go for SQL 2005. Every upgrade
> you ever do will require you to deal with SOME incompatibilities. But
> from SQL 7 to SQL 2005 should be relatively easy.
Erland mentioned "compatibility level 90" as possibly entailing some
incompatibilities. Would you concur?
(From Access [any
> version] to SQL Server [any version] might be more trouble).
> The payoff will be bigger if you go straight for 2005 - especially when
> you start using the new features. Plus you'll be settled for some time
> to come!
I certainly agree with that. The only issue would be if there were a main
difference between upgrading to 2000 vs. 2005. But if upgrading to 2000 or
2005 were more or less the same, then I'd agree that 2005 would be the way
to go.
Thanks!
Neil

> --
> Hugo Kornelis, SQL Server MVP
|||X-Newsreader: Forte Agent 1.91/32.564
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@.supernews.com
Lines: 30
Path: TK2MSFTNGP08.phx.gbl!newsfeed00.sul.t-online.de!t-online.de!newsfeed.freenet.de!213.132.189.2.MISMAT CH!multikabel.net!feed20.multikabel.net!tudelft.nl !binfeed1.tudelft.nl!newsgate.newsserver.nl!feeder .z74.net!news.z74.net!sn-ams-06!sn-xt-ams-05!sn-p
ost-ams-01!supernews.com!corp.supernews.com!not-for-mail
Xref: TK2MSFTNGP08.phx.gbl microsoft.public.sqlserver.server:421875 microsoft.public.sqlserver.odbc:46013
On Fri, 27 Jan 2006 08:27:25 GMT, Neil wrote:

>Erland mentioned "compatibility level 90" as possibly entailing some
>incompatibilities. Would you concur?
Hi Neil,
Compatibility level 90 means that you unlock all the new features that
were implemented in SQL Server 2005. Upgrading to SQL Server 2005
without striving for compatibility level 90 is, IMHO, a bit silly.
Lower compatibility levels are included to make upgrading easier. At
compatibility level 70, many features still behave the same as in SQL
Server 7.0. Not all, though - some changes to the core of the DB engine
were just too drastic to allow mimicking the "old" behaviour.
Upgrading from SQL Server 7.0 to SQL Server 2005 at compatibility level
70 means that you have to make only minimal changes - you don't have to
change the features that are still supported in the compatibility level.
But this should only be a first step - the next step should be to
replace old functionality with new functionality, then set the
compatbility level to 90. And after that, you can begin to unleash the
true power of all the new features!
Hugo Kornelis, SQL Server MVP

Migrating to SQL 2003

We are running SQL 7, using Access 2000 as a front end. Our network person
is wanting to migrate to Windows 2003 (we're currently on Windows 2000), and
wants to know if we should migrate to SQL 2003 at the same time. Are there
major changes between SQL 7 and SQL 2003, and how hard of a task would it be
to migrate our single database to a new version of SQL?
Thanks,
NeilHi
You would be better to migrate to SQL 2005! Adding this migration will
increase the number of potential issues, but if you test it thoroughly then
you should be ok.
Check out the SQL 2005 Upgrade Advisor
http://www.microsoft.com/downloads/details.aspx?familyid=6107C27A-662C-4319-AFE7-B52D1568C30A&displaylang=en
and upgrade handbook
http://www.microsoft.com/technet/prodtechnol/sql/2005/sqlupgrd.mspx
John
"Neil" wrote:
> We are running SQL 7, using Access 2000 as a front end. Our network person
> is wanting to migrate to Windows 2003 (we're currently on Windows 2000), and
> wants to know if we should migrate to SQL 2003 at the same time. Are there
> major changes between SQL 7 and SQL 2003, and how hard of a task would it be
> to migrate our single database to a new version of SQL?
> Thanks,
> Neil
>
>|||Ummm, do you want to migrate to SQL 2000 or SQL 2005?
MC
"Neil" <nospam@.nospam.net> wrote in message
news:Y_anf.2725$QQ1.23@.newsread3.news.pas.earthlink.net...
> We are running SQL 7, using Access 2000 as a front end. Our network person
> is wanting to migrate to Windows 2003 (we're currently on Windows 2000),
> and wants to know if we should migrate to SQL 2003 at the same time. Are
> there major changes between SQL 7 and SQL 2003, and how hard of a task
> would it be to migrate our single database to a new version of SQL?
> Thanks,
> Neil
>|||Neil (nospam@.nospam.net) writes:
> We are running SQL 7, using Access 2000 as a front end. Our network
> person is wanting to migrate to Windows 2003 (we're currently on Windows
> 2000), and wants to know if we should migrate to SQL 2003 at the same
> time. Are there major changes between SQL 7 and SQL 2003, and how hard
> of a task would it be to migrate our single database to a new version of
> SQL?
There is no SQL 2003. There is SQL 2000 which is very mature now, and
there is SQL 2005 which was released just over a month ago.
While there are vast improvements in SQL 2005 over SQL 2000, migrating
your database to SQL 2005 can very well be a simple task, although there
are some incompatibilities, particularly if you head for compatibility
level 90 (which I recommend).
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx|||Hi, Erland. Thanks for your reply. Given the incompatibilities between SQL
2005 and SQL 97, do you think it would be wise to just upgrade to SQL 2000?
Also, any ideas about which one might be better suited for Windows 2003
and/or an ODBC environment (using Access MDB as a front end)? Thanks!
Neil
"Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
news:Xns972AE1D20309BYazorman@.127.0.0.1...
> Neil (nospam@.nospam.net) writes:
>> We are running SQL 7, using Access 2000 as a front end. Our network
>> person is wanting to migrate to Windows 2003 (we're currently on Windows
>> 2000), and wants to know if we should migrate to SQL 2003 at the same
>> time. Are there major changes between SQL 7 and SQL 2003, and how hard
>> of a task would it be to migrate our single database to a new version of
>> SQL?
> There is no SQL 2003. There is SQL 2000 which is very mature now, and
> there is SQL 2005 which was released just over a month ago.
> While there are vast improvements in SQL 2005 over SQL 2000, migrating
> your database to SQL 2005 can very well be a simple task, although there
> are some incompatibilities, particularly if you head for compatibility
> level 90 (which I recommend).
>
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx|||Neil (nospam@.nospam.net) writes:
> Hi, Erland. Thanks for your reply. Given the incompatibilities between
> SQL 2005 and SQL 97, do you think it would be wise to just upgrade to
> SQL 2000? Also, any ideas about which one might be better suited for
> Windows 2003 and/or an ODBC environment (using Access MDB as a front
> end)? Thanks!
SQL 97? Do you mean Access 97?
I can't give any advice that involves Access as this is an unknown product
to me.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx|||On Thu, 26 Jan 2006 05:02:36 GMT, Neil wrote:
>Hi, Erland. Thanks for your reply. Given the incompatibilities between SQL
>2005 and SQL 97, do you think it would be wise to just upgrade to SQL 2000?
>Also, any ideas about which one might be better suited for Windows 2003
>and/or an ODBC environment (using Access MDB as a front end)? Thanks!
>Neil
Hi Neil,
If you're upgrading anyway (whether from SQL 7 or fram Access 97, I
don't know), then I'd recommend you to go for SQL 2005. Every upgrade
you ever do will require you to deal with SOME incompatibilities. But
from SQL 7 to SQL 2005 should be relatively easy. (From Access [any
version] to SQL Server [any version] might be more trouble).
The payoff will be bigger if you go straight for 2005 - especially when
you start using the new features. Plus you'll be settled for some time
to come!
--
Hugo Kornelis, SQL Server MVP|||I meant SQL 7.
I'm mainly looking for advice re. compatibility with Windows 2003, and
possibly ODBC environments.
Thanks.
"Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
news:Xns9757815ED3247Yazorman@.127.0.0.1...
> Neil (nospam@.nospam.net) writes:
>> Hi, Erland. Thanks for your reply. Given the incompatibilities between
>> SQL 2005 and SQL 97, do you think it would be wise to just upgrade to
>> SQL 2000? Also, any ideas about which one might be better suited for
>> Windows 2003 and/or an ODBC environment (using Access MDB as a front
>> end)? Thanks!
> SQL 97? Do you mean Access 97?
> I can't give any advice that involves Access as this is an unknown product
> to me.
>
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx|||Hi, Hugo. Thanks for the reply. See below.
"Hugo Kornelis" <hugo@.perFact.REMOVETHIS.info> wrote in message
news:1kcit1hfo208tb1pr1quci8o43ob8g1d1s@.4ax.com...
> On Thu, 26 Jan 2006 05:02:36 GMT, Neil wrote:
>>Hi, Erland. Thanks for your reply. Given the incompatibilities between SQL
>>2005 and SQL 97, do you think it would be wise to just upgrade to SQL
>>2000?
>>Also, any ideas about which one might be better suited for Windows 2003
>>and/or an ODBC environment (using Access MDB as a front end)? Thanks!
>>Neil
> Hi Neil,
> If you're upgrading anyway (whether from SQL 7 or fram Access 97, I
> don't know),
It's from SQL 7. We are currently using Access with a SQL 7 back end.
> then I'd recommend you to go for SQL 2005. Every upgrade
> you ever do will require you to deal with SOME incompatibilities. But
> from SQL 7 to SQL 2005 should be relatively easy.
Erland mentioned "compatibility level 90" as possibly entailing some
incompatibilities. Would you concur?
(From Access [any
> version] to SQL Server [any version] might be more trouble).
> The payoff will be bigger if you go straight for 2005 - especially when
> you start using the new features. Plus you'll be settled for some time
> to come!
I certainly agree with that. The only issue would be if there were a main
difference between upgrading to 2000 vs. 2005. But if upgrading to 2000 or
2005 were more or less the same, then I'd agree that 2005 would be the way
to go.
Thanks!
Neil
> --
> Hugo Kornelis, SQL Server MVP|||On Fri, 27 Jan 2006 08:27:25 GMT, Neil wrote:
>> then I'd recommend you to go for SQL 2005. Every upgrade
>> you ever do will require you to deal with SOME incompatibilities. But
>> from SQL 7 to SQL 2005 should be relatively easy.
>Erland mentioned "compatibility level 90" as possibly entailing some
>incompatibilities. Would you concur?
Hi Neil,
Compatibility level 90 means that you unlock all the new features that
were implemented in SQL Server 2005. Upgrading to SQL Server 2005
without striving for compatibility level 90 is, IMHO, a bit silly.
Lower compatibility levels are included to make upgrading easier. At
compatibility level 70, many features still behave the same as in SQL
Server 7.0. Not all, though - some changes to the core of the DB engine
were just too drastic to allow mimicking the "old" behaviour.
Upgrading from SQL Server 7.0 to SQL Server 2005 at compatibility level
70 means that you have to make only minimal changes - you don't have to
change the features that are still supported in the compatibility level.
But this should only be a first step - the next step should be to
replace old functionality with new functionality, then set the
compatbility level to 90. And after that, you can begin to unleash the
true power of all the new features!
--
Hugo Kornelis, SQL Server MVP|||Neil (nospam@.nospam.net) writes:
> Erland mentioned "compatibility level 90" as possibly entailing some
> incompatibilities. Would you concur?
You can choose compatibiliy level 70. There still are cases of what
is is illegal syntax bot not caught by SQL 2000. (Don't know if SQL 7
has the same issues.) But with compatibility level 70, some functionalit
will not be available to you.
Beside mew reserved keywords, the main issue is the old-style outer
join (*= and =*) that are not permitted in level 90. If you have this,
rewrite it, because this is crap.
Note that you could run into issues if you upgrade to SQL 2000 as
well, althogh I think difference between level 70 and 80 is just
three keywords.
I've seen some mentions that Access 2003 is not co-operative with SQL2005,
but you probably get better answer on that in an Access newsgroup.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx|||Sounds like a plan. Thanks.
"Hugo Kornelis" <hugo@.perFact.REMOVETHIS.info> wrote in message
news:ct7lt1l2q78ulrbj4jm7p7se9spq00c62u@.4ax.com...
> On Fri, 27 Jan 2006 08:27:25 GMT, Neil wrote:
>> then I'd recommend you to go for SQL 2005. Every upgrade
>> you ever do will require you to deal with SOME incompatibilities. But
>> from SQL 7 to SQL 2005 should be relatively easy.
>>Erland mentioned "compatibility level 90" as possibly entailing some
>>incompatibilities. Would you concur?
> Hi Neil,
> Compatibility level 90 means that you unlock all the new features that
> were implemented in SQL Server 2005. Upgrading to SQL Server 2005
> without striving for compatibility level 90 is, IMHO, a bit silly.
> Lower compatibility levels are included to make upgrading easier. At
> compatibility level 70, many features still behave the same as in SQL
> Server 7.0. Not all, though - some changes to the core of the DB engine
> were just too drastic to allow mimicking the "old" behaviour.
> Upgrading from SQL Server 7.0 to SQL Server 2005 at compatibility level
> 70 means that you have to make only minimal changes - you don't have to
> change the features that are still supported in the compatibility level.
> But this should only be a first step - the next step should be to
> replace old functionality with new functionality, then set the
> compatbility level to 90. And after that, you can begin to unleash the
> true power of all the new features!
> --
> Hugo Kornelis, SQL Server MVP|||Thanks, and thanks for the note about Access 2003 and SQL 2005.
"Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
news:Xns9758F0BBCCE23Yazorman@.127.0.0.1...
> Neil (nospam@.nospam.net) writes:
>> Erland mentioned "compatibility level 90" as possibly entailing some
>> incompatibilities. Would you concur?
> You can choose compatibiliy level 70. There still are cases of what
> is is illegal syntax bot not caught by SQL 2000. (Don't know if SQL 7
> has the same issues.) But with compatibility level 70, some functionalit
> will not be available to you.
> Beside mew reserved keywords, the main issue is the old-style outer
> join (*= and =*) that are not permitted in level 90. If you have this,
> rewrite it, because this is crap.
> Note that you could run into issues if you upgrade to SQL 2000 as
> well, althogh I think difference between level 70 and 80 is just
> three keywords.
>
> I've seen some mentions that Access 2003 is not co-operative with SQL2005,
> but you probably get better answer on that in an Access newsgroup.
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx

Migrating to SQL 2003

We are running SQL 7, using Access 2000 as a front end. Our network person
is wanting to migrate to Windows 2003 (we're currently on Windows 2000), and
wants to know if we should migrate to SQL 2003 at the same time. Are there
major changes between SQL 7 and SQL 2003, and how hard of a task would it be
to migrate our single database to a new version of SQL?
Thanks,
Neil
Hi
You would be better to migrate to SQL 2005! Adding this migration will
increase the number of potential issues, but if you test it thoroughly then
you should be ok.
Check out the SQL 2005 Upgrade Advisor
http://www.microsoft.com/downloads/d...displaylang=en
and upgrade handbook
http://www.microsoft.com/technet/pro.../sqlupgrd.mspx
John
"Neil" wrote:

> We are running SQL 7, using Access 2000 as a front end. Our network person
> is wanting to migrate to Windows 2003 (we're currently on Windows 2000), and
> wants to know if we should migrate to SQL 2003 at the same time. Are there
> major changes between SQL 7 and SQL 2003, and how hard of a task would it be
> to migrate our single database to a new version of SQL?
> Thanks,
> Neil
>
>
|||Ummm, do you want to migrate to SQL 2000 or SQL 2005?
MC
"Neil" <nospam@.nospam.net> wrote in message
news:Y_anf.2725$QQ1.23@.newsread3.news.pas.earthlin k.net...
> We are running SQL 7, using Access 2000 as a front end. Our network person
> is wanting to migrate to Windows 2003 (we're currently on Windows 2000),
> and wants to know if we should migrate to SQL 2003 at the same time. Are
> there major changes between SQL 7 and SQL 2003, and how hard of a task
> would it be to migrate our single database to a new version of SQL?
> Thanks,
> Neil
>
|||Neil (nospam@.nospam.net) writes:
> We are running SQL 7, using Access 2000 as a front end. Our network
> person is wanting to migrate to Windows 2003 (we're currently on Windows
> 2000), and wants to know if we should migrate to SQL 2003 at the same
> time. Are there major changes between SQL 7 and SQL 2003, and how hard
> of a task would it be to migrate our single database to a new version of
> SQL?
There is no SQL 2003. There is SQL 2000 which is very mature now, and
there is SQL 2005 which was released just over a month ago.
While there are vast improvements in SQL 2005 over SQL 2000, migrating
your database to SQL 2005 can very well be a simple task, although there
are some incompatibilities, particularly if you head for compatibility
level 90 (which I recommend).
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx
|||Hi, Erland. Thanks for your reply. Given the incompatibilities between SQL
2005 and SQL 97, do you think it would be wise to just upgrade to SQL 2000?
Also, any ideas about which one might be better suited for Windows 2003
and/or an ODBC environment (using Access MDB as a front end)? Thanks!
Neil
"Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
news:Xns972AE1D20309BYazorman@.127.0.0.1...
> Neil (nospam@.nospam.net) writes:
> There is no SQL 2003. There is SQL 2000 which is very mature now, and
> there is SQL 2005 which was released just over a month ago.
> While there are vast improvements in SQL 2005 over SQL 2000, migrating
> your database to SQL 2005 can very well be a simple task, although there
> are some incompatibilities, particularly if you head for compatibility
> level 90 (which I recommend).
>
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/pro...ads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodinf...ons/books.mspx
|||Neil (nospam@.nospam.net) writes:
> Hi, Erland. Thanks for your reply. Given the incompatibilities between
> SQL 2005 and SQL 97, do you think it would be wise to just upgrade to
> SQL 2000? Also, any ideas about which one might be better suited for
> Windows 2003 and/or an ODBC environment (using Access MDB as a front
> end)? Thanks!
SQL 97? Do you mean Access 97?
I can't give any advice that involves Access as this is an unknown product
to me.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx
|||On Thu, 26 Jan 2006 05:02:36 GMT, Neil wrote:

>Hi, Erland. Thanks for your reply. Given the incompatibilities between SQL
>2005 and SQL 97, do you think it would be wise to just upgrade to SQL 2000?
>Also, any ideas about which one might be better suited for Windows 2003
>and/or an ODBC environment (using Access MDB as a front end)? Thanks!
>Neil
Hi Neil,
If you're upgrading anyway (whether from SQL 7 or fram Access 97, I
don't know), then I'd recommend you to go for SQL 2005. Every upgrade
you ever do will require you to deal with SOME incompatibilities. But
from SQL 7 to SQL 2005 should be relatively easy. (From Access [any
version] to SQL Server [any version] might be more trouble).
The payoff will be bigger if you go straight for 2005 - especially when
you start using the new features. Plus you'll be settled for some time
to come!
Hugo Kornelis, SQL Server MVP
|||I meant SQL 7.
I'm mainly looking for advice re. compatibility with Windows 2003, and
possibly ODBC environments.
Thanks.
"Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
news:Xns9757815ED3247Yazorman@.127.0.0.1...
> Neil (nospam@.nospam.net) writes:
> SQL 97? Do you mean Access 97?
> I can't give any advice that involves Access as this is an unknown product
> to me.
>
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/pro...ads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodinf...ons/books.mspx
|||Hi, Hugo. Thanks for the reply. See below.
"Hugo Kornelis" <hugo@.perFact.REMOVETHIS.info> wrote in message
news:1kcit1hfo208tb1pr1quci8o43ob8g1d1s@.4ax.com...
> On Thu, 26 Jan 2006 05:02:36 GMT, Neil wrote:
>
> Hi Neil,
> If you're upgrading anyway (whether from SQL 7 or fram Access 97, I
> don't know),
It's from SQL 7. We are currently using Access with a SQL 7 back end.

> then I'd recommend you to go for SQL 2005. Every upgrade
> you ever do will require you to deal with SOME incompatibilities. But
> from SQL 7 to SQL 2005 should be relatively easy.
Erland mentioned "compatibility level 90" as possibly entailing some
incompatibilities. Would you concur?
(From Access [any
> version] to SQL Server [any version] might be more trouble).
> The payoff will be bigger if you go straight for 2005 - especially when
> you start using the new features. Plus you'll be settled for some time
> to come!
I certainly agree with that. The only issue would be if there were a main
difference between upgrading to 2000 vs. 2005. But if upgrading to 2000 or
2005 were more or less the same, then I'd agree that 2005 would be the way
to go.
Thanks!
Neil

> --
> Hugo Kornelis, SQL Server MVP
|||X-Newsreader: Forte Agent 1.91/32.564
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@.supernews.com
Lines: 30
Path: TK2MSFTNGP08.phx.gbl!newsfeed00.sul.t-online.de!t-online.de!newsfeed.freenet.de!213.132.189.2.MISMAT CH!multikabel.net!feed20.multikabel.net!tudelft.nl !binfeed1.tudelft.nl!newsgate.newsserver.nl!feeder .z74.net!news.z74.net!sn-ams-06!sn-xt-ams-05!sn-p
ost-ams-01!supernews.com!corp.supernews.com!not-for-mail
Xref: TK2MSFTNGP08.phx.gbl microsoft.public.sqlserver.server:421875 microsoft.public.sqlserver.odbc:46013
On Fri, 27 Jan 2006 08:27:25 GMT, Neil wrote:

>Erland mentioned "compatibility level 90" as possibly entailing some
>incompatibilities. Would you concur?
Hi Neil,
Compatibility level 90 means that you unlock all the new features that
were implemented in SQL Server 2005. Upgrading to SQL Server 2005
without striving for compatibility level 90 is, IMHO, a bit silly.
Lower compatibility levels are included to make upgrading easier. At
compatibility level 70, many features still behave the same as in SQL
Server 7.0. Not all, though - some changes to the core of the DB engine
were just too drastic to allow mimicking the "old" behaviour.
Upgrading from SQL Server 7.0 to SQL Server 2005 at compatibility level
70 means that you have to make only minimal changes - you don't have to
change the features that are still supported in the compatibility level.
But this should only be a first step - the next step should be to
replace old functionality with new functionality, then set the
compatbility level to 90. And after that, you can begin to unleash the
true power of all the new features!
Hugo Kornelis, SQL Server MVP

Migrating to SQL 2003

We are running SQL 7, using Access 2000 as a front end. Our network person
is wanting to migrate to Windows 2003 (we're currently on Windows 2000), and
wants to know if we should migrate to SQL 2003 at the same time. Are there
major changes between SQL 7 and SQL 2003, and how hard of a task would it be
to migrate our single database to a new version of SQL?
Thanks,
NeilHi
You would be better to migrate to SQL 2005! Adding this migration will
increase the number of potential issues, but if you test it thoroughly then
you should be ok.
Check out the SQL 2005 Upgrade Advisor
http://www.microsoft.com/downloads/...&displaylang=en
and upgrade handbook
http://www.microsoft.com/technet/pr...5/sqlupgrd.mspx
John
"Neil" wrote:

> We are running SQL 7, using Access 2000 as a front end. Our network person
> is wanting to migrate to Windows 2003 (we're currently on Windows 2000), a
nd
> wants to know if we should migrate to SQL 2003 at the same time. Are there
> major changes between SQL 7 and SQL 2003, and how hard of a task would it
be
> to migrate our single database to a new version of SQL?
> Thanks,
> Neil
>
>|||Ummm, do you want to migrate to SQL 2000 or SQL 2005?
MC
"Neil" <nospam@.nospam.net> wrote in message
news:Y_anf.2725$QQ1.23@.newsread3.news.pas.earthlink.net...
> We are running SQL 7, using Access 2000 as a front end. Our network person
> is wanting to migrate to Windows 2003 (we're currently on Windows 2000),
> and wants to know if we should migrate to SQL 2003 at the same time. Are
> there major changes between SQL 7 and SQL 2003, and how hard of a task
> would it be to migrate our single database to a new version of SQL?
> Thanks,
> Neil
>|||Neil (nospam@.nospam.net) writes:
> We are running SQL 7, using Access 2000 as a front end. Our network
> person is wanting to migrate to Windows 2003 (we're currently on Windows
> 2000), and wants to know if we should migrate to SQL 2003 at the same
> time. Are there major changes between SQL 7 and SQL 2003, and how hard
> of a task would it be to migrate our single database to a new version of
> SQL?
There is no SQL 2003. There is SQL 2000 which is very mature now, and
there is SQL 2005 which was released just over a month ago.
While there are vast improvements in SQL 2005 over SQL 2000, migrating
your database to SQL 2005 can very well be a simple task, although there
are some incompatibilities, particularly if you head for compatibility
level 90 (which I recommend).
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|||Hi, Erland. Thanks for your reply. Given the incompatibilities between SQL
2005 and SQL 97, do you think it would be wise to just upgrade to SQL 2000?
Also, any ideas about which one might be better suited for Windows 2003
and/or an ODBC environment (using Access MDB as a front end)? Thanks!
Neil
"Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
news:Xns972AE1D20309BYazorman@.127.0.0.1...
> Neil (nospam@.nospam.net) writes:
> There is no SQL 2003. There is SQL 2000 which is very mature now, and
> there is SQL 2005 which was released just over a month ago.
> While there are vast improvements in SQL 2005 over SQL 2000, migrating
> your database to SQL 2005 can very well be a simple task, although there
> are some incompatibilities, particularly if you head for compatibility
> level 90 (which I recommend).
>
> --
> 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|||Neil (nospam@.nospam.net) writes:
> Hi, Erland. Thanks for your reply. Given the incompatibilities between
> SQL 2005 and SQL 97, do you think it would be wise to just upgrade to
> SQL 2000? Also, any ideas about which one might be better suited for
> Windows 2003 and/or an ODBC environment (using Access MDB as a front
> end)? Thanks!
SQL 97? Do you mean Access 97?
I can't give any advice that involves Access as this is an unknown product
to me.
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|||On Thu, 26 Jan 2006 05:02:36 GMT, Neil wrote:

>Hi, Erland. Thanks for your reply. Given the incompatibilities between SQL
>2005 and SQL 97, do you think it would be wise to just upgrade to SQL 2000?
>Also, any ideas about which one might be better suited for Windows 2003
>and/or an ODBC environment (using Access MDB as a front end)? Thanks!
>Neil
Hi Neil,
If you're upgrading anyway (whether from SQL 7 or fram Access 97, I
don't know), then I'd recommend you to go for SQL 2005. Every upgrade
you ever do will require you to deal with SOME incompatibilities. But
from SQL 7 to SQL 2005 should be relatively easy. (From Access [any
version] to SQL Server [any version] might be more trouble).
The payoff will be bigger if you go straight for 2005 - especially when
you start using the new features. Plus you'll be settled for some time
to come!
Hugo Kornelis, SQL Server MVP|||I meant SQL 7.
I'm mainly looking for advice re. compatibility with Windows 2003, and
possibly ODBC environments.
Thanks.
"Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
news:Xns9757815ED3247Yazorman@.127.0.0.1...
> Neil (nospam@.nospam.net) writes:
> SQL 97? Do you mean Access 97?
> I can't give any advice that involves Access as this is an unknown product
> to me.
>
> --
> 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|||Hi, Hugo. Thanks for the reply. See below.
"Hugo Kornelis" <hugo@.perFact.REMOVETHIS.info> wrote in message
news:1kcit1hfo208tb1pr1quci8o43ob8g1d1s@.
4ax.com...
> On Thu, 26 Jan 2006 05:02:36 GMT, Neil wrote:
>
> Hi Neil,
> If you're upgrading anyway (whether from SQL 7 or fram Access 97, I
> don't know),
It's from SQL 7. We are currently using Access with a SQL 7 back end.

> then I'd recommend you to go for SQL 2005. Every upgrade
> you ever do will require you to deal with SOME incompatibilities. But
> from SQL 7 to SQL 2005 should be relatively easy.
Erland mentioned "compatibility level 90" as possibly entailing some
incompatibilities. Would you concur?
(From Access [any
> version] to SQL Server [any version] might be more trouble).
> The payoff will be bigger if you go straight for 2005 - especially when
> you start using the new features. Plus you'll be settled for some time
> to come!
I certainly agree with that. The only issue would be if there were a main
difference between upgrading to 2000 vs. 2005. But if upgrading to 2000 or
2005 were more or less the same, then I'd agree that 2005 would be the way
to go.
Thanks!
Neil

> --
> Hugo Kornelis, SQL Server MVP|||X-Newsreader: Forte Agent 1.91/32.564
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@.supernews.com
Lines: 30
Path: TK2MSFTNGP08.phx.gbl!newsfeed00.sul.t-online.de!t-online.de!newsfeed.f
reenet.de!213.132.189.2.MISMATCH!multikabel.net!feed20.multikabel.net!tudelf
t.nl!binfeed1.tudelft.nl!newsgate.newsserver.nl!feeder.z74.net!news.z74.net!
sn-ams-06!sn-xt-ams-05!sn-p
ost-ams-01!supernews.com!corp.supernews.com!not-for-mail
Xref: TK2MSFTNGP08.phx.gbl microsoft.public.sqlserver.server:421875 microsof
t.public.sqlserver.odbc:46013
On Fri, 27 Jan 2006 08:27:25 GMT, Neil wrote:

>Erland mentioned "compatibility level 90" as possibly entailing some
>incompatibilities. Would you concur?
Hi Neil,
Compatibility level 90 means that you unlock all the new features that
were implemented in SQL Server 2005. Upgrading to SQL Server 2005
without striving for compatibility level 90 is, IMHO, a bit silly.
Lower compatibility levels are included to make upgrading easier. At
compatibility level 70, many features still behave the same as in SQL
Server 7.0. Not all, though - some changes to the core of the DB engine
were just too drastic to allow mimicking the "old" behaviour.
Upgrading from SQL Server 7.0 to SQL Server 2005 at compatibility level
70 means that you have to make only minimal changes - you don't have to
change the features that are still supported in the compatibility level.
But this should only be a first step - the next step should be to
replace old functionality with new functionality, then set the
compatbility level to 90. And after that, you can begin to unleash the
true power of all the new features!
Hugo Kornelis, SQL Server MVP

migrating to ms sql from db2

currently running db2 database on IBM AS/400, looking to down size. We want to convert the db2 database to MS SQL and run it on windows 2003.
Is this a latteral move or do we have to change anything within DB2 or MS SQL(naming conventions, file types or sizes, schemas, etc) is there any tools out there for this type of migration?
Thank you for your help.You can reverse engineer your DB2 with ERwin and forward generate the model
to SQL to get your schema accross. But that is not necessarily a 1-button
push type operation. I imagine there will be subtle difference in how chars
and such are handled and they may manifest them selves as truncation bugs
and such when you run you stored procedures and such later.
Ata R
Parvan Consulting Inc
NO_SPAMar_alias001@.NO_SPAMparvan.net
"dossman10" <anonymous@.discussions.microsoft.com> wrote in message
news:F0CF5A34-6196-44D1-9FA7-4C086AD70BCF@.microsoft.com...
> currently running db2 database on IBM AS/400, looking to down size. We
want to convert the db2 database to MS SQL and run it on windows 2003.
> Is this a latteral move or do we have to change anything within DB2 or MS
SQL(naming conventions, file types or sizes, schemas, etc) is there any
tools out there for this type of migration?
> Thank you for your help.

migrating to ms sql

we are wanting convert to MS SQL and windows 2003 running on an Intel platfrom, converting from IBM DB2 AS/400. Is it possible and what would it take to convert
Thank you.Sure it's possible.
It will take time, money and resources. Resources should
include people knowledgeable of both DB2 and Sql Server.
Your question wasn't very specific, so it's hard to give
you a very good answer.
>--Original Message--
>we are wanting convert to MS SQL and windows 2003
running on an Intel platfrom, converting from IBM DB2
AS/400. Is it possible and what would it take to convert?
>Thank you.
>.
>|||"dossman10" <anonymous@.discussions.microsoft.com> wrote in message
news:D1D753CE-78FC-4553-A36E-14FE075CC5BA@.microsoft.com...
> we are wanting convert to MS SQL and windows 2003 running on an Intel
platfrom, converting from IBM DB2 AS/400. Is it possible and what would it
take to convert?
> Thank you.|||Hi,
If it is only tables, We can do the data transfer using DTS.
But to connect from Win2003 server to AS/400 machine you should install
DB2CONNECT for AS400 provided
by IBM.
Thanks
Hari
MCDBA
"dossman10" <anonymous@.discussions.microsoft.com> wrote in message
news:D1D753CE-78FC-4553-A36E-14FE075CC5BA@.microsoft.com...
> we are wanting convert to MS SQL and windows 2003 running on an Intel
platfrom, converting from IBM DB2 AS/400. Is it possible and what would it
take to convert?
> Thank you.