I'm attempting to move a database which currently exists on an old Oracle
7.34 instance and tried to use Data Import via DTS to SQL 2000.
The Oracle database consists of views, indexes,packages,triggers as well as
tables structures. I tried DTS using both the ODBC and OLE for Oracle and
only tables and data came over correctly.
Views it appears were converted into tables. Indexes not at all.
I'm using the Oracle 9.2 client on my workstation.
Any ideas on how I might be able to convert this database over from Oracle?
thksYou'll have to move the code, views, etc manually
--
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
"Jack Snow" <mrbrew5510@.hotmail.com> wrote in message
news:tea_c.4190$lv3.2047604@.news4.srv.hcvlny.cv.net...
> I'm attempting to move a database which currently exists on an old Oracle
> 7.34 instance and tried to use Data Import via DTS to SQL 2000.
> The Oracle database consists of views, indexes,packages,triggers as well
as
> tables structures. I tried DTS using both the ODBC and OLE for Oracle and
> only tables and data came over correctly.
> Views it appears were converted into tables. Indexes not at all.
> I'm using the Oracle 9.2 client on my workstation.
> Any ideas on how I might be able to convert this database over from
Oracle?
>
> thks
>
Saturday, February 25, 2012
Migration from MySQL to SQL Server
How can I change the MySQL code to SQL Server's like below?
I could not find out to change appropriate UNSIGNED keyword and ENUM
keyword in SQL Server.
CREATE TABLE myTable (
id INT UNSIGNED NOT NULL,
name CHAR(20),
role ENUM('ADMIN','USER','GUEST','UNKNOWN') DEFAULT 'ADMIN'
PRIMARY KEY(id)
);
hi,
you can use "standard" signed integers in SQL Server syntax to host integer values in the range -2,147,483,648 to 2,147,483,647 as SQL Server does not provide unsigned integers... you can "scale up" to bigint if you required larger range in the integer domain..
http://msdn2.microsoft.com/en-us/library/ms187745.aspx
SQL Server does not provide an "Enum" feature, but you can define a CHECK CONSTRAINT for that...
usually you should consider a referential integrity based referenced table in the design if the "range" can grow as a direct CHECK requires modelling refinement and rewriting if you, say, want to add sometime later another "role" valid entry...
so... you can "translate" as
SET NOCOUNT ON; USE tempdb; GO CREATE TABLE myTable ( Id int NOT NULL PRIMARY KEY, Name char(20) NULL, -- but I bet varchar(20) should be better -- as not all names will be 20 chars long Role varchar(7) NOT NULL DEFAULT 'ADMIN' CONSTRAINT chk_Valid$Entries$for$Roles -- use this check constraint if you require CASE SENSITIVE validation of the role -- CHECK ( Role IN ('ADMIN' COLLATE Latin1_General_CS_AS , 'USER' COLLATE Latin1_General_CS_AS , 'GUEST' COLLATE Latin1_General_CS_AS , 'UNKNOWN' COLLATE Latin1_General_CS_AS ) ) -- use this check constraint if you do not require CASE SENSITIVE validation of the role CHECK ( Role IN ('ADMIN', 'USER', 'GUEST', 'UNKNOWN') ) ); GO INSERT INTO myTable VALUES ( 1 , 'Andrea', DEFAULT ); -- default role GO INSERT INTO myTable VALUES ( 2 , 'Andrea2', 'USER' ); -- valid role GO INSERT INTO myTable VALUES ( 3 , 'Andrea3', 'other' ); -- NOT valid role GO INSERT INTO myTable VALUES ( 4 , 'Andrea3', 'User' ); -- NOT valid role IF case sensite -- collation check has been set GO SELECT * FROM myTable GO DROP TABLE myTable; --<-- Msg 547, Level 16, State 0, Line 1 The INSERT statement conflicted with the CHECK constraint "chk_Valid$Entries$for$Roles". The conflict occurred in database "tempdb", table "dbo.myTable", column 'Role'. The statement has been terminated. Id Name Role -- -- - 1 Andrea ADMIN 2 Andrea2 USER 4 Andrea3 User I provided 2 different check constraints... the active one is NOT case sensitive, that's to say users can enter both 'ADMIN' and 'admin' (or whatever conbination of cases), where the commented one performs a case sensitive check and the 4th insert will fail accordingly...
thanks to Lorenzo Benaglia, friend and SQL Server MVP fellow for helping in the "migration"...
regards
Migration from MS access TO MS SQL
We recently needed to switch from Access over to MS SQL because of the
limitations with access and its size maximums. We currently use Access as our reporting trigger for the entire companies reporting. I'm currently trying to discover functionality that I had in Access in MS SQL. I'm slowly but surely learning. Our database structure in Access was set up with Master Files and revenue files in seperate Access databases and then linked into functional reporting access databases. So we had many links from DB to DB. Additionally we had links directly into the AS400(JDE). My question is two fold:
How do you link from DB to DB in MS SQL, my assumption was using a VIEW.
Is this the best method or should you store all the tables in the same DB(probably not, I would say).
How do you link(create view) a file where the source is the as/400? And again is this a good method for getting at that data. I think my problem here is the PROVIDER_NAME
One more. Our Infrastructure group named the server Local is that going to inhibit anything in the future.
And also one more. I get an error creating views that look at other SQL DB's when I include criteria. When I don't they work..
Thanks
jmThat's a lot of questions. I can try to answer some of them:
FACT: You can reference tables and other objects in other databases by using the full three-part name syntax:
database.owner.object
You can use this syntax is views, stored procedures, etc...wherever you would noramally reference the table or view. If you omit the database and owner, SQL server assumes you are refering to an object in the current database owned by either the current login or the dbo. Fully referencing objects is not normally required, and that's probably why you are not familiar with it.
OPINION: Put all your tables in one database. Was there a reason you had them separated in Access? That probably affected system performance.
QUESTION: What error are you getting when you include criteria in your linked views? (There should be some rules for the forum forbidding people from mentioning they are receiving an error without stating what the error is! :rolleyes: )
I don't think naming your server Local will do any harm except make code extremely confusing to read, especially code on other servers that reference it! It does show a complete lack of imagination and creativity, and you can tell them I said so.
blindman|||As fare as I know, SQL Server does not support links to "alien" systems like AS/400. So, you have in my opinion two options:
* Maintain MS Access as integration platform, even if your data is moved to SQL Server
* Let your reporting tool connect to the different systems and join the results
For a multi-database application, and a Access-SQL Server converison tool look at my references beneath.|||It is possible basically you may need MS Host Integration Server so you can talk to AS/400 servers. Using SQL 2000 Link Server technology you use Ole DB/ODBC to talk to any other RDBMS as long as it supports Ole DB/ODBC (including AS/400). I have not tried this myself so I could be way of the mark, I have tried it with Sybase running on Unix.|||Yes, you should be able to connect to your Oracle database. Checks SQL Server Books Online for "Configuring Linked Servers".
Access makes a fine reporting tool and a flexible user-interface, but if your data is on SQL server you would get the best performance by pushing as much processing back onto the server as possible. Access is notoriously slow when processing queries on remote data, because it often must pull entire tables across a network in order to make its joins. It is sometimes able to formulate a plan that involves the server filtering the data first, but this cannot be relied upon. Your best bet is to let SQL server make all the links between tables and other servers and pass that data back to Access for display. Add to that the fact that MS Access' security schema is primitive and clunky compared to SQL server.
Check out the option of converting your Access database to an Access Data Project (.adp file extension). ADP applications use a more direct connection to SQL server, and all processing is performed on the server since the ADP file cannot store tables and views. An Access Data Project is my preference for rapid application development.
blindman|||Blindman is corected. Why need a "middleware" Access when your data is in SQL Server? not ony that SQL Server is more robust & secure than Access , the performance is much better when directly access data. thru SQL Server.
limitations with access and its size maximums. We currently use Access as our reporting trigger for the entire companies reporting. I'm currently trying to discover functionality that I had in Access in MS SQL. I'm slowly but surely learning. Our database structure in Access was set up with Master Files and revenue files in seperate Access databases and then linked into functional reporting access databases. So we had many links from DB to DB. Additionally we had links directly into the AS400(JDE). My question is two fold:
How do you link from DB to DB in MS SQL, my assumption was using a VIEW.
Is this the best method or should you store all the tables in the same DB(probably not, I would say).
How do you link(create view) a file where the source is the as/400? And again is this a good method for getting at that data. I think my problem here is the PROVIDER_NAME
One more. Our Infrastructure group named the server Local is that going to inhibit anything in the future.
And also one more. I get an error creating views that look at other SQL DB's when I include criteria. When I don't they work..
Thanks
jmThat's a lot of questions. I can try to answer some of them:
FACT: You can reference tables and other objects in other databases by using the full three-part name syntax:
database.owner.object
You can use this syntax is views, stored procedures, etc...wherever you would noramally reference the table or view. If you omit the database and owner, SQL server assumes you are refering to an object in the current database owned by either the current login or the dbo. Fully referencing objects is not normally required, and that's probably why you are not familiar with it.
OPINION: Put all your tables in one database. Was there a reason you had them separated in Access? That probably affected system performance.
QUESTION: What error are you getting when you include criteria in your linked views? (There should be some rules for the forum forbidding people from mentioning they are receiving an error without stating what the error is! :rolleyes: )
I don't think naming your server Local will do any harm except make code extremely confusing to read, especially code on other servers that reference it! It does show a complete lack of imagination and creativity, and you can tell them I said so.
blindman|||As fare as I know, SQL Server does not support links to "alien" systems like AS/400. So, you have in my opinion two options:
* Maintain MS Access as integration platform, even if your data is moved to SQL Server
* Let your reporting tool connect to the different systems and join the results
For a multi-database application, and a Access-SQL Server converison tool look at my references beneath.|||It is possible basically you may need MS Host Integration Server so you can talk to AS/400 servers. Using SQL 2000 Link Server technology you use Ole DB/ODBC to talk to any other RDBMS as long as it supports Ole DB/ODBC (including AS/400). I have not tried this myself so I could be way of the mark, I have tried it with Sybase running on Unix.|||Yes, you should be able to connect to your Oracle database. Checks SQL Server Books Online for "Configuring Linked Servers".
Access makes a fine reporting tool and a flexible user-interface, but if your data is on SQL server you would get the best performance by pushing as much processing back onto the server as possible. Access is notoriously slow when processing queries on remote data, because it often must pull entire tables across a network in order to make its joins. It is sometimes able to formulate a plan that involves the server filtering the data first, but this cannot be relied upon. Your best bet is to let SQL server make all the links between tables and other servers and pass that data back to Access for display. Add to that the fact that MS Access' security schema is primitive and clunky compared to SQL server.
Check out the option of converting your Access database to an Access Data Project (.adp file extension). ADP applications use a more direct connection to SQL server, and all processing is performed on the server since the ADP file cannot store tables and views. An Access Data Project is my preference for rapid application development.
blindman|||Blindman is corected. Why need a "middleware" Access when your data is in SQL Server? not ony that SQL Server is more robust & secure than Access , the performance is much better when directly access data. thru SQL Server.
Migration from MS Access 2003
Hello,
I'm very new to MS SQL Server; I just downloaded Express 2005 yesterday. I have it up and running; it seems to be working fine.
Now onto business - I need to migrate data from existing MS Access 2003. How, exactly, do I do this? I've tried searching MSDN, TechNet, and here, and while I get results that seem to tell part of the story, I don't seem to get a true "How to" for this task.
Can someone please assist me with this?
Thank you.
Here you go:
http://support.microsoft.com/default.aspx/kb/237980
Buck Woody
Migration from MS Access 2003
Hello,
I'm very new to MS SQL Server; I just downloaded Express 2005 yesterday. I have it up and running; it seems to be working fine.
Now onto business - I need to migrate data from existing MS Access 2003. How, exactly, do I do this? I've tried searching MSDN, TechNet, and here, and while I get results that seem to tell part of the story, I don't seem to get a true "How to" for this task.
Can someone please assist me with this?
Thank you.
Here you go:
http://support.microsoft.com/default.aspx/kb/237980
Buck Woody
Migration from DTS to SSIS
Hi everybody,
I would REALLY appreciate it if some had a link to a good tutorial about migration from DTS to SSIS, but without visual studio . net.
For example I need to use DTS package in sql server 2005 and execute them, I used migration wizard (SQL 2005) but it didn't work because i have in my computer sql 2000 et sql 2005 and the server name is PC2, however when i use the server source PC2 and the server destination PC2 an error message appear "server destination should be a sql server 2005 instance ".
help me please..
Thanks very much anyone response my question.
Moving to the SSIS 2005 forum from the SSIS 2008 forum.|||If the connection is to a computer with both 2000 and 2005 on it, the 2005 install needs to be referenced by the server and instance name (MACHINENAME\INSTANCENAME).
Migration from DTS to SSIS
Hi everybody,
I would REALLY appreciate it if some had a link to a good tutorial about migration from DTS to SSIS, but without visual studio . net.
For example I need to use DTS package in sql server 2005 and execute them, I used migration wizard (SQL 2005) but it didn't work because i have in my computer sql 2000 et sql 2005 and the server name is PC2, however when i use the server source PC2 and the server destination PC2 an error message appear "server destination should be a sql server 2005 instance ".
help me please..
Thanks very much anyone response my question.
Moving to the SSIS 2005 forum from the SSIS 2008 forum.|||If the connection is to a computer with both 2000 and 2005 on it, the 2005 install needs to be referenced by the server and instance name (MACHINENAME\INSTANCENAME).
Migration from DB2 to MSSQL Server 2000
Hi Friends,
I am doing my final semester project. It is a migration tool that converts the DB2 PL dialect into MSSQL Server's T-SQL dialect.
I am in need of sample DB2 PL files(procedures, UDFs, triggers) for testing the tool. Please point out me to some DB2 files repository links or if you have some files, please give me the same. I will use this only for testing purposes.
Appreciate your help.
Thanks & Regards,
JakeI suggest you place your request in DB2 threads too.|||Hi Protege,
Thanks for the suggestion. I have placed it in the DB2 thread also.
Thanks & Regards,
Jake
Originally posted by Protege
I suggest you place your request in DB2 threads too.
I am doing my final semester project. It is a migration tool that converts the DB2 PL dialect into MSSQL Server's T-SQL dialect.
I am in need of sample DB2 PL files(procedures, UDFs, triggers) for testing the tool. Please point out me to some DB2 files repository links or if you have some files, please give me the same. I will use this only for testing purposes.
Appreciate your help.
Thanks & Regards,
JakeI suggest you place your request in DB2 threads too.|||Hi Protege,
Thanks for the suggestion. I have placed it in the DB2 thread also.
Thanks & Regards,
Jake
Originally posted by Protege
I suggest you place your request in DB2 threads too.
Migration from DB2
Hi,
We are migrating from DB2 to SQL Server 2000. We have used DB2 OLAP
functions (rank, sum, etc.) quit liberally. How should be translate them in
SQL Server.
Thanks
PrashantTake a look at SQL Server Analysis Services
http://www.microsoft.com/sql/evalua...bianalysis.mspx
http://sqlservercode.blogspot.com/
"Prashant Bharti" wrote:
> Hi,
> We are migrating from DB2 to SQL Server 2000. We have used DB2 OLAP
> functions (rank, sum, etc.) quit liberally. How should be translate them i
n
> SQL Server.
> Thanks
> Prashant
>
>|||I mean how can I translate following DB2 SQL to MS SQL Server SQL.
SELECT JOB, YEARS, ID, NAME,
ROW_NUMBER() OVER(PARTITION BY JOB ORDER BY YEARS) AS ROW#,
RANK() OVER(PARTITION BY JOB ORDER BY YEARS) AS RN1#,
DENSE_RANK() OVER(PARTITION BY JOB ORDER BY YEARS) AS RN2#
FROM STAFF
WHERE ID < 150 AND YEARS IN (6,7) AND JOB > 'L'
ORDER BY JOB, YEARS, ID, NAME
Thanks
Prashant
"SQL" <SQL@.discussions.microsoft.com> wrote in message
news:C1B8F525-56CC-419F-A731-AD70626DC169@.microsoft.com...
> Take a look at SQL Server Analysis Services
> http://www.microsoft.com/sql/evalua...bianalysis.mspx
> http://sqlservercode.blogspot.com/
>
> "Prashant Bharti" wrote:
>|||Use SQL Server 2005. It will be released in a few w
s and has those constr
ucts.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Prashant Bharti" <prashantb@.aditi.com> wrote in message
news:uzB0lF%230FHA.3568@.TK2MSFTNGP15.phx.gbl...
>I mean how can I translate following DB2 SQL to MS SQL Server SQL.
> SELECT JOB, YEARS, ID, NAME,
> ROW_NUMBER() OVER(PARTITION BY JOB ORDER BY YEARS) AS ROW#,
> RANK() OVER(PARTITION BY JOB ORDER BY YEARS) AS RN1#,
> DENSE_RANK() OVER(PARTITION BY JOB ORDER BY YEARS) AS RN2#
> FROM STAFF
> WHERE ID < 150 AND YEARS IN (6,7) AND JOB > 'L'
> ORDER BY JOB, YEARS, ID, NAME
> Thanks
> Prashant
> "SQL" <SQL@.discussions.microsoft.com> wrote in message
> news:C1B8F525-56CC-419F-A731-AD70626DC169@.microsoft.com...
>|||Can you please send me any document/link which says that these will be in
SQL Server 2005.
Thanks
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:O25Vh$%230FHA.2072@.TK2MSFTNGP14.phx.gbl...
> Use SQL Server 2005. It will be released in a few ws and has those
> constructs.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> Blog: http://solidqualitylearning.com/blogs/tibor/
>
> "Prashant Bharti" <prashantb@.aditi.com> wrote in message
> news:uzB0lF%230FHA.3568@.TK2MSFTNGP15.phx.gbl...
>|||You might be able to find the information at http://www.microsoft.com/sql/2005/def
ault.mspx. Or
download and install the documentation for 2005:
http://www.microsoft.com/downloads/...&displaylang=en
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Prashant Bharti" <prashantb@.aditi.com> wrote in message
news:u4Kl3Kk1FHA.980@.TK2MSFTNGP14.phx.gbl...
> Can you please send me any document/link which says that these will be in
SQL Server 2005.
> Thanks
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote i
n message
> news:O25Vh$%230FHA.2072@.TK2MSFTNGP14.phx.gbl...
>
We are migrating from DB2 to SQL Server 2000. We have used DB2 OLAP
functions (rank, sum, etc.) quit liberally. How should be translate them in
SQL Server.
Thanks
PrashantTake a look at SQL Server Analysis Services
http://www.microsoft.com/sql/evalua...bianalysis.mspx
http://sqlservercode.blogspot.com/
"Prashant Bharti" wrote:
> Hi,
> We are migrating from DB2 to SQL Server 2000. We have used DB2 OLAP
> functions (rank, sum, etc.) quit liberally. How should be translate them i
n
> SQL Server.
> Thanks
> Prashant
>
>|||I mean how can I translate following DB2 SQL to MS SQL Server SQL.
SELECT JOB, YEARS, ID, NAME,
ROW_NUMBER() OVER(PARTITION BY JOB ORDER BY YEARS) AS ROW#,
RANK() OVER(PARTITION BY JOB ORDER BY YEARS) AS RN1#,
DENSE_RANK() OVER(PARTITION BY JOB ORDER BY YEARS) AS RN2#
FROM STAFF
WHERE ID < 150 AND YEARS IN (6,7) AND JOB > 'L'
ORDER BY JOB, YEARS, ID, NAME
Thanks
Prashant
"SQL" <SQL@.discussions.microsoft.com> wrote in message
news:C1B8F525-56CC-419F-A731-AD70626DC169@.microsoft.com...
> Take a look at SQL Server Analysis Services
> http://www.microsoft.com/sql/evalua...bianalysis.mspx
> http://sqlservercode.blogspot.com/
>
> "Prashant Bharti" wrote:
>|||Use SQL Server 2005. It will be released in a few w
s and has those constructs.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Prashant Bharti" <prashantb@.aditi.com> wrote in message
news:uzB0lF%230FHA.3568@.TK2MSFTNGP15.phx.gbl...
>I mean how can I translate following DB2 SQL to MS SQL Server SQL.
> SELECT JOB, YEARS, ID, NAME,
> ROW_NUMBER() OVER(PARTITION BY JOB ORDER BY YEARS) AS ROW#,
> RANK() OVER(PARTITION BY JOB ORDER BY YEARS) AS RN1#,
> DENSE_RANK() OVER(PARTITION BY JOB ORDER BY YEARS) AS RN2#
> FROM STAFF
> WHERE ID < 150 AND YEARS IN (6,7) AND JOB > 'L'
> ORDER BY JOB, YEARS, ID, NAME
> Thanks
> Prashant
> "SQL" <SQL@.discussions.microsoft.com> wrote in message
> news:C1B8F525-56CC-419F-A731-AD70626DC169@.microsoft.com...
>|||Can you please send me any document/link which says that these will be in
SQL Server 2005.
Thanks
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:O25Vh$%230FHA.2072@.TK2MSFTNGP14.phx.gbl...
> Use SQL Server 2005. It will be released in a few w
s and has those> constructs.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> Blog: http://solidqualitylearning.com/blogs/tibor/
>
> "Prashant Bharti" <prashantb@.aditi.com> wrote in message
> news:uzB0lF%230FHA.3568@.TK2MSFTNGP15.phx.gbl...
>|||You might be able to find the information at http://www.microsoft.com/sql/2005/def
ault.mspx. Or
download and install the documentation for 2005:
http://www.microsoft.com/downloads/...&displaylang=en
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Prashant Bharti" <prashantb@.aditi.com> wrote in message
news:u4Kl3Kk1FHA.980@.TK2MSFTNGP14.phx.gbl...
> Can you please send me any document/link which says that these will be in
SQL Server 2005.
> Thanks
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote i
n message
> news:O25Vh$%230FHA.2072@.TK2MSFTNGP14.phx.gbl...
>
Migration from ComponentOne Reporting Service to SQL 2005 RS
Hi,
Is it possible to migrate from Component RS to SQL 2005 RS?Hi,
Is it possible to migrate from ComponentOne RS to SQL 2005 RS?
Is it possible to migrate from Component RS to SQL 2005 RS?Hi,
Is it possible to migrate from ComponentOne RS to SQL 2005 RS?
Migration from Cognos ...
Hi,
I've been asked to investigate for a client the migration from Cognos Decisionstream (7.1), PowerPlay and Impromptu (7.3) to SQL Server 2005. Key driver (so far) is to reduce licensing costs. I can't say I'm a Cognos guru.. so..
Has anyone done this / doing this / thinking about this?
What are the key benefits ?
What does Cognos offer that we don't ?
What are the biggest issues ?
Did you have any problems ?
What other items should I be considering ?
Thanks
www.SQLobSERVER.com
Here is what I found from my research.
1) There are no front-end tools available from Microsoft especially for Cube analysis. Where as in cognos we have PowerPlay Web for this.
2) There is no BI custom portal available from Microsoft. I saw there is some sample BI Portal app provided by Microsoft that is based on Share point services but this cannot be used for production environment.
Looks like Microsoft is totally depending on third party vendors for web based front-end solutions. I found that there is company called Panorama that provides front end web based solutions to SQL Server 2005 BI stuff. If you find any thing from your investigation please let me know.
I too have been asked to do this same evaluation for the company I work at.
We will be having a demo from MS this afternoon and I will post more information at that time.
What I can offer at this time is what my research has yielded.
So far it looks like MS is going to be excellent for the back end work (I.E. building the cubes using the new UDM structures)
What is not clear at this point is how Cognos Cubes will be able to be converted into a MS format?
In addition, I found ProClarity also has some front end modeling tools.
Lets see what MS has to say this afternoon!
|||Fresh out of the MS Demo.
This tool certainly has potential. The integration with the rest of the microsoft suite is exceptional as usual for microsoft products.
They do have end user tools that are in fact web based. This product is still maturing but in my opinion is ready for the market.
I will be going to a Cognos webinar next week and will report back my findings as to how well the two compare and also in relation to the needs of this company. Since this company already has Cognos, there is pressure to remain on that product. However, being a forward thinking company and a publicly traded company it is in the best interest to investigate further the possiblity of this microsoft shop to mirgrate over to the Microsoft tool.
I will post another update next week.
BTW- There was no mention of a converstion tool between Cognos and This MS product.
|||Matrix from a company called DataJungle can support both Cognos and Microsoft cubes in a single, integrated dashboard and analysis product. An excellent front end for those looking to migrate from the Cognos to Microsoft BI platform, without having to rip out there Cognos investment. The company seems to be hot in this market...especially given that Series 8 from Cognos is very expensive...more and more Cognos customers will be moving to Microsoft.
JG
|||Couple of more data points for you:
regarding issue #1: Have you looked at Report Builder in SQL Server 2005 Reporting Services? An end user can use this to design report on top of an Analysis Services cube.
regarding issue #2: We have been working very hard to get a solution to this - we are integrating reporting services with Windows SharePoint Services to enable this scenario. You can download a prerelease build of the Microsoft SQL Server 2005 Reporting Services Add-in for Microsoft SharePoint Technologies - Community Technology Preview (CTP) here:
http://www.microsoft.com/downloads/details.aspx?FamilyID=4E50BE6E-3F92-4552-A78C-B3BE1D94D5DA&displaylang=en&mg_id=10049
This is still baking but it will be available with SQL Server 2005 SP2 and will work with Microsoft Office SharePoint Server 2007.
Hope that helps,
-Lukasz
|||1) There are no front-end tools available from Microsoft especially for Cube analysis. Where as in cognos we have PowerPlay Web for this.
Really? How about Excel, Report Builder, or Proclarity?
2) There is no BI custom portal available from Microsoft. I saw there is some sample BI Portal app provided by Microsoft that is based on Share point services but this cannot be used for production environment.
Why?
|||>What are the key benefits (from the first post)?
Ask Cognos to show you how you can integrate custom applications with their backend services and you will have a key benefit 
Also, for a fraction of the Cognos licensing cost, you will get more feature-rich MS offerings in almost all areas. Cognos doesn't have a relational database and data mining offerings. They have a very basic ETL product. UDM wins hands down against PowerPlay. SSRS (both standard and ad-hoc reporting) is more powerful than their Report Studio (or Impromptu for that matter). Instead of a hodge podge of technologies, with MS you will get a well-integrated BI platform.
Teo,
You are still talking about the same "BI" tool in MS that, in their last service pack, REMOVED the 'select all' functionality in reporting services, right? did you just use the work "powerful" in reference to Report Builder? Really?
|||ChicagoClone,
I said "more powerful" (than Cognos), I didn't say "perfect" . BTW, the "select all" is back in SP2... and there is much rejoicing throughout the land. From the readme file:
In SQL Server 2005 Reporting Services (SSRS), a Select All check box was automatically added when you created an available values list for a multivalue report parameter. If you upgraded to SQL Server 2005 Service Pack 1 (SP1), the Select All check box was no longer available. In SQL Server 2005 Service Pack 2 (SP2), the Select All check box has been restored.
|||
Any comments about lack of semantic layer for the SSRS report designer (not report builder which can use Report Models). Cognos uses Framework manager for the semantic layer but do you think that people can do without this type of functionality in SSRS.
|||I am not sure it is such a good idea to have that layer. First, you need to wait for Cognos to write a provider for each database version you need to support. Second, such a layer may introduce performance issues because it auto-generates queries for you. Instead, I would encourage you consider UDM in SSAS 2005 as the ultimate semantic layer which can be integrated with many MS and third-party reporting tools as opposed to Cognos tools only in the case of the Framework manager.
|||One another thing I have heard people complain about is, the person who could build the cubes in either of these environments. I have heard users complain that you will need a developer to build cubes in SSAS where as person with limited knowledge can easily create the cubes in Cognos. I do not have experience in Cognos so not sure how much of this is true. I would appreciate if experts could comment in this area.
How easy it is to develop Cubes in Cognos compared to SSAS.?
|||Interesting points. My thinking was that these semantic layer solutions are more for deployments that don't utilize dimensional models but instead get their data straight from the OLTP data sources. Without someone building these dimensional models on the database side to simplify the data, the report designers would at least have the ability to simplify some of the data with these BI semantic layers perhaps at some cost to performance. So in essence, these BI semantic layers may only provide value for initial or prototyping deployments or any other situation where there are no dimensional models, either relational or mutidimensional based.Any thoughts on that.Thanks for your input.
|||In general, SSAS is a database so its primary users are DBAs. One area where you do need developer experience is enhancing the cube with business calculations which requires MDX knowledge. But both Cognos and SSAS real-life cubes will require to be extended. MDX is a standard language and there are books written for MDX. There aren't any books written for Cognos cubes or Cognos in general.
Migration from Cognos ...
Hi,
I've been asked to investigate for a client the migration from Cognos Decisionstream (7.1), PowerPlay and Impromptu (7.3) to SQL Server 2005. Key driver (so far) is to reduce licensing costs. I can't say I'm a Cognos guru.. so..
Has anyone done this / doing this / thinking about this?
What are the key benefits ?
What does Cognos offer that we don't ?
What are the biggest issues ?
Did you have any problems ?
What other items should I be considering ?
Thanks
www.SQLobSERVER.com
Here is what I found from my research.
1) There are no front-end tools available from Microsoft especially for Cube analysis. Where as in cognos we have PowerPlay Web for this.
2) There is no BI custom portal available from Microsoft. I saw there is some sample BI Portal app provided by Microsoft that is based on Share point services but this cannot be used for production environment.
Looks like Microsoft is totally depending on third party vendors for web based front-end solutions. I found that there is company called Panorama that provides front end web based solutions to SQL Server 2005 BI stuff. If you find any thing from your investigation please let me know.
I too have been asked to do this same evaluation for the company I work at.
We will be having a demo from MS this afternoon and I will post more information at that time.
What I can offer at this time is what my research has yielded.
So far it looks like MS is going to be excellent for the back end work (I.E. building the cubes using the new UDM structures)
What is not clear at this point is how Cognos Cubes will be able to be converted into a MS format?
In addition, I found ProClarity also has some front end modeling tools.
Lets see what MS has to say this afternoon!
|||Fresh out of the MS Demo.
This tool certainly has potential. The integration with the rest of the microsoft suite is exceptional as usual for microsoft products.
They do have end user tools that are in fact web based. This product is still maturing but in my opinion is ready for the market.
I will be going to a Cognos webinar next week and will report back my findings as to how well the two compare and also in relation to the needs of this company. Since this company already has Cognos, there is pressure to remain on that product. However, being a forward thinking company and a publicly traded company it is in the best interest to investigate further the possiblity of this microsoft shop to mirgrate over to the Microsoft tool.
I will post another update next week.
BTW- There was no mention of a converstion tool between Cognos and This MS product.
|||Matrix from a company called DataJungle can support both Cognos and Microsoft cubes in a single, integrated dashboard and analysis product. An excellent front end for those looking to migrate from the Cognos to Microsoft BI platform, without having to rip out there Cognos investment. The company seems to be hot in this market...especially given that Series 8 from Cognos is very expensive...more and more Cognos customers will be moving to Microsoft.
JG
|||Couple of more data points for you:
regarding issue #1: Have you looked at Report Builder in SQL Server 2005 Reporting Services? An end user can use this to design report on top of an Analysis Services cube.
regarding issue #2: We have been working very hard to get a solution to this - we are integrating reporting services with Windows SharePoint Services to enable this scenario. You can download a prerelease build of the Microsoft SQL Server 2005 Reporting Services Add-in for Microsoft SharePoint Technologies - Community Technology Preview (CTP) here:
http://www.microsoft.com/downloads/details.aspx?FamilyID=4E50BE6E-3F92-4552-A78C-B3BE1D94D5DA&displaylang=en&mg_id=10049
This is still baking but it will be available with SQL Server 2005 SP2 and will work with Microsoft Office SharePoint Server 2007.
Hope that helps,
-Lukasz
|||1) There are no front-end tools available from Microsoft especially for Cube analysis.Where as in cognos we have PowerPlay Web for this.
Really? How about Excel, Report Builder, or Proclarity?
2) There is no BI custom portal available from Microsoft. I saw there is some sample BI Portal app provided by Microsoft that is based on Share point services but this cannot be used for production environment.
Why?
|||>What are the key benefits (from the first post)?
Ask Cognos to show you how you can integrate custom applications with their backend services and you will have a key benefit Also, for a fraction of the Cognos licensing cost, you will get more feature-rich MS offerings in almost all areas. Cognos doesn't have a relational database and data mining offerings. They have a very basic ETL product. UDM wins hands down against PowerPlay. SSRS (both standard and ad-hoc reporting) is more powerful than their Report Studio (or Impromptu for that matter). Instead of a hodge podge of technologies, with MS you will get a well-integrated BI platform.
Teo,
You are still talking about the same "BI" tool in MS that, in their last service pack, REMOVED the 'select all' functionality in reporting services, right? did you just use the work "powerful" in reference to Report Builder? Really?
|||ChicagoClone,
I said "more powerful" (than Cognos), I didn't say "perfect" . BTW, the "select all" is back in SP2... and there is much rejoicing throughout the land. From the readme file:
In SQL Server 2005 Reporting Services (SSRS), a Select All check box was automatically added when you created an available values list for a multivalue report parameter. If you upgraded to SQL Server 2005 Service Pack 1 (SP1), the Select All check box was no longer available. In SQL Server 2005 Service Pack 2 (SP2), the Select All check box has been restored.
|||Any comments about lack of semantic layer for the SSRS report designer (not report builder which can use Report Models). Cognos uses Framework manager for the semantic layer but do you think that people can do without this type of functionality in SSRS.
|||I am not sure it is such a good idea to have that layer. First, you need to wait for Cognos to write a provider for each database version you need to support. Second, such a layer may introduce performance issues because it auto-generates queries for you. Instead, I would encourage you consider UDM in SSAS 2005 as the ultimate semantic layer which can be integrated with many MS and third-party reporting tools as opposed to Cognos tools only in the case of the Framework manager.
|||One another thing I have heard people complain about is, the person who could build the cubes in either of these environments. I have heard users complain that you will need a developer to build cubes in SSAS where as person with limited knowledge can easily create the cubes in Cognos. I do not have experience in Cognos so not sure how much of this is true. I would appreciate if experts could comment in this area.
How easy it is to develop Cubes in Cognos compared to SSAS.?
|||Interesting points. My thinking was that these semantic layer solutions are more for deployments that don't utilize dimensional models but instead get their data straight from the OLTP data sources. Without someone building these dimensional models on the database side to simplify the data, the report designers would at least have the ability to simplify some of the data with these BI semantic layers perhaps at some cost to performance. So in essence, these BI semantic layers may only provide value for initial or prototyping deployments or any other situation where there are no dimensional models, either relational or mutidimensional based.Any thoughts on that.Thanks for your input.
|||In general, SSAS is a database so its primary users are DBAs. One area where you do need developer experience is enhancing the cube with business calculations which requires MDX knowledge. But both Cognos and SSAS real-life cubes will require to be extended. MDX is a standard language and there are books written for MDX. There aren't any books written for Cognos cubes or Cognos in general.
Migration from Cognos ...
Hi,
I've been asked to investigate for a client the migration from Cognos Decisionstream (7.1), PowerPlay and Impromptu (7.3) to SQL Server 2005. Key driver (so far) is to reduce licensing costs. I can't say I'm a Cognos guru.. so..
Has anyone done this / doing this / thinking about this?
What are the key benefits ?
What does Cognos offer that we don't ?
What are the biggest issues ?
Did you have any problems ?
What other items should I be considering ?
Thanks
www.SQLobSERVER.com
Here is what I found from my research.
1) There are no front-end tools available from Microsoft especially for Cube analysis. Where as in cognos we have PowerPlay Web for this.
2) There is no BI custom portal available from Microsoft. I saw there is some sample BI Portal app provided by Microsoft that is based on Share point services but this cannot be used for production environment.
Looks like Microsoft is totally depending on third party vendors for web based front-end solutions. I found that there is company called Panorama that provides front end web based solutions to SQL Server 2005 BI stuff. If you find any thing from your investigation please let me know.
I too have been asked to do this same evaluation for the company I work at.
We will be having a demo from MS this afternoon and I will post more information at that time.
What I can offer at this time is what my research has yielded.
So far it looks like MS is going to be excellent for the back end work (I.E. building the cubes using the new UDM structures)
What is not clear at this point is how Cognos Cubes will be able to be converted into a MS format?
In addition, I found ProClarity also has some front end modeling tools.
Lets see what MS has to say this afternoon!
|||Fresh out of the MS Demo.
This tool certainly has potential. The integration with the rest of the microsoft suite is exceptional as usual for microsoft products.
They do have end user tools that are in fact web based. This product is still maturing but in my opinion is ready for the market.
I will be going to a Cognos webinar next week and will report back my findings as to how well the two compare and also in relation to the needs of this company. Since this company already has Cognos, there is pressure to remain on that product. However, being a forward thinking company and a publicly traded company it is in the best interest to investigate further the possiblity of this microsoft shop to mirgrate over to the Microsoft tool.
I will post another update next week.
BTW- There was no mention of a converstion tool between Cognos and This MS product.
|||Matrix from a company called DataJungle can support both Cognos and Microsoft cubes in a single, integrated dashboard and analysis product. An excellent front end for those looking to migrate from the Cognos to Microsoft BI platform, without having to rip out there Cognos investment. The company seems to be hot in this market...especially given that Series 8 from Cognos is very expensive...more and more Cognos customers will be moving to Microsoft.
JG
|||Couple of more data points for you:
regarding issue #1: Have you looked at Report Builder in SQL Server 2005 Reporting Services? An end user can use this to design report on top of an Analysis Services cube.
regarding issue #2: We have been working very hard to get a solution to this - we are integrating reporting services with Windows SharePoint Services to enable this scenario. You can download a prerelease build of the Microsoft SQL Server 2005 Reporting Services Add-in for Microsoft SharePoint Technologies - Community Technology Preview (CTP) here:
http://www.microsoft.com/downloads/details.aspx?FamilyID=4E50BE6E-3F92-4552-A78C-B3BE1D94D5DA&displaylang=en&mg_id=10049
This is still baking but it will be available with SQL Server 2005 SP2 and will work with Microsoft Office SharePoint Server 2007.
Hope that helps,
-Lukasz
|||1) There are no front-end tools available from Microsoft especially for Cube analysis. Where as in cognos we have PowerPlay Web for this.
Really? How about Excel, Report Builder, or Proclarity?
2) There is no BI custom portal available from Microsoft. I saw there is some sample BI Portal app provided by Microsoft that is based on Share point services but this cannot be used for production environment.
Why?
|||>What are the key benefits (from the first post)?
Ask Cognos to show you how you can integrate custom applications with their backend services and you will have a key benefit Also, for a fraction of the Cognos licensing cost, you will get more feature-rich MS offerings in almost all areas. Cognos doesn't have a relational database and data mining offerings. They have a very basic ETL product. UDM wins hands down against PowerPlay. SSRS (both standard and ad-hoc reporting) is more powerful than their Report Studio (or Impromptu for that matter). Instead of a hodge podge of technologies, with MS you will get a well-integrated BI platform.
Teo,
You are still talking about the same "BI" tool in MS that, in their last service pack, REMOVED the 'select all' functionality in reporting services, right? did you just use the work "powerful" in reference to Report Builder? Really?
|||ChicagoClone,
I said "more powerful" (than Cognos), I didn't say "perfect" . BTW, the "select all" is back in SP2... and there is much rejoicing throughout the land. From the readme file:
In SQL Server 2005 Reporting Services (SSRS), a Select All check box was automatically added when you created an available values list for a multivalue report parameter. If you upgraded to SQL Server 2005 Service Pack 1 (SP1), the Select All check box was no longer available. In SQL Server 2005 Service Pack 2 (SP2), the Select All check box has been restored.
|||Any comments about lack of semantic layer for the SSRS report designer (not report builder which can use Report Models). Cognos uses Framework manager for the semantic layer but do you think that people can do without this type of functionality in SSRS.
|||I am not sure it is such a good idea to have that layer. First, you need to wait for Cognos to write a provider for each database version you need to support. Second, such a layer may introduce performance issues because it auto-generates queries for you. Instead, I would encourage you consider UDM in SSAS 2005 as the ultimate semantic layer which can be integrated with many MS and third-party reporting tools as opposed to Cognos tools only in the case of the Framework manager.
|||One another thing I have heard people complain about is, the person who could build the cubes in either of these environments. I have heard users complain that you will need a developer to build cubes in SSAS where as person with limited knowledge can easily create the cubes in Cognos. I do not have experience in Cognos so not sure how much of this is true. I would appreciate if experts could comment in this area.
How easy it is to develop Cubes in Cognos compared to SSAS.?
|||Interesting points. My thinking was that these semantic layer solutions are more for deployments that don't utilize dimensional models but instead get their data straight from the OLTP data sources. Without someone building these dimensional models on the database side to simplify the data, the report designers would at least have the ability to simplify some of the data with these BI semantic layers perhaps at some cost to performance. So in essence, these BI semantic layers may only provide value for initial or prototyping deployments or any other situation where there are no dimensional models, either relational or mutidimensional based.Any thoughts on that.Thanks for your input.
|||In general, SSAS is a database so its primary users are DBAs. One area where you do need developer experience is enhancing the cube with business calculations which requires MDX knowledge. But both Cognos and SSAS real-life cubes will require to be extended. MDX is a standard language and there are books written for MDX. There aren't any books written for Cognos cubes or Cognos in general.
Migration from Cognos ...
Hi,
I've been asked to investigate for a client the migration from Cognos Decisionstream (7.1), PowerPlay and Impromptu (7.3) to SQL Server 2005. Key driver (so far) is to reduce licensing costs. I can't say I'm a Cognos guru.. so..
Has anyone done this / doing this / thinking about this?
What are the key benefits ?
What does Cognos offer that we don't ?
What are the biggest issues ?
Did you have any problems ?
What other items should I be considering ?
Thanks
www.SQLobSERVER.com
Here is what I found from my research.
1) There are no front-end tools available from Microsoft especially for Cube analysis. Where as in cognos we have PowerPlay Web for this.
2) There is no BI custom portal available from Microsoft. I saw there is some sample BI Portal app provided by Microsoft that is based on Share point services but this cannot be used for production environment.
Looks like Microsoft is totally depending on third party vendors for web based front-end solutions. I found that there is company called Panorama that provides front end web based solutions to SQL Server 2005 BI stuff. If you find any thing from your investigation please let me know.
I too have been asked to do this same evaluation for the company I work at.
We will be having a demo from MS this afternoon and I will post more information at that time.
What I can offer at this time is what my research has yielded.
So far it looks like MS is going to be excellent for the back end work (I.E. building the cubes using the new UDM structures)
What is not clear at this point is how Cognos Cubes will be able to be converted into a MS format?
In addition, I found ProClarity also has some front end modeling tools.
Lets see what MS has to say this afternoon!
|||Fresh out of the MS Demo.
This tool certainly has potential. The integration with the rest of the microsoft suite is exceptional as usual for microsoft products.
They do have end user tools that are in fact web based. This product is still maturing but in my opinion is ready for the market.
I will be going to a Cognos webinar next week and will report back my findings as to how well the two compare and also in relation to the needs of this company. Since this company already has Cognos, there is pressure to remain on that product. However, being a forward thinking company and a publicly traded company it is in the best interest to investigate further the possiblity of this microsoft shop to mirgrate over to the Microsoft tool.
I will post another update next week.
BTW- There was no mention of a converstion tool between Cognos and This MS product.
|||Matrix from a company called DataJungle can support both Cognos and Microsoft cubes in a single, integrated dashboard and analysis product. An excellent front end for those looking to migrate from the Cognos to Microsoft BI platform, without having to rip out there Cognos investment. The company seems to be hot in this market...especially given that Series 8 from Cognos is very expensive...more and more Cognos customers will be moving to Microsoft.
JG
|||Couple of more data points for you:
regarding issue #1: Have you looked at Report Builder in SQL Server 2005 Reporting Services? An end user can use this to design report on top of an Analysis Services cube.
regarding issue #2: We have been working very hard to get a solution to this - we are integrating reporting services with Windows SharePoint Services to enable this scenario. You can download a prerelease build of the Microsoft SQL Server 2005 Reporting Services Add-in for Microsoft SharePoint Technologies - Community Technology Preview (CTP) here:
http://www.microsoft.com/downloads/details.aspx?FamilyID=4E50BE6E-3F92-4552-A78C-B3BE1D94D5DA&displaylang=en&mg_id=10049
This is still baking but it will be available with SQL Server 2005 SP2 and will work with Microsoft Office SharePoint Server 2007.
Hope that helps,
-Lukasz
|||1) There are no front-end tools available from Microsoft especially for Cube analysis. Where as in cognos we have PowerPlay Web for this.
Really? How about Excel, Report Builder, or Proclarity?
2) There is no BI custom portal available from Microsoft. I saw there is some sample BI Portal app provided by Microsoft that is based on Share point services but this cannot be used for production environment.
Why?
|||>What are the key benefits (from the first post)?
Ask Cognos to show you how you can integrate custom applications with their backend services and you will have a key benefit Also, for a fraction of the Cognos licensing cost, you will get more feature-rich MS offerings in almost all areas. Cognos doesn't have a relational database and data mining offerings. They have a very basic ETL product. UDM wins hands down against PowerPlay. SSRS (both standard and ad-hoc reporting) is more powerful than their Report Studio (or Impromptu for that matter). Instead of a hodge podge of technologies, with MS you will get a well-integrated BI platform.
Teo,
You are still talking about the same "BI" tool in MS that, in their last service pack, REMOVED the 'select all' functionality in reporting services, right? did you just use the work "powerful" in reference to Report Builder? Really?
|||ChicagoClone,
I said "more powerful" (than Cognos), I didn't say "perfect" . BTW, the "select all" is back in SP2... and there is much rejoicing throughout the land. From the readme file:
In SQL Server 2005 Reporting Services (SSRS), a Select All check box was automatically added when you created an available values list for a multivalue report parameter. If you upgraded to SQL Server 2005 Service Pack 1 (SP1), the Select All check box was no longer available. In SQL Server 2005 Service Pack 2 (SP2), the Select All check box has been restored.
|||Any comments about lack of semantic layer for the SSRS report designer (not report builder which can use Report Models). Cognos uses Framework manager for the semantic layer but do you think that people can do without this type of functionality in SSRS.
|||I am not sure it is such a good idea to have that layer. First, you need to wait for Cognos to write a provider for each database version you need to support. Second, such a layer may introduce performance issues because it auto-generates queries for you. Instead, I would encourage you consider UDM in SSAS 2005 as the ultimate semantic layer which can be integrated with many MS and third-party reporting tools as opposed to Cognos tools only in the case of the Framework manager.
|||One another thing I have heard people complain about is, the person who could build the cubes in either of these environments. I have heard users complain that you will need a developer to build cubes in SSAS where as person with limited knowledge can easily create the cubes in Cognos. I do not have experience in Cognos so not sure how much of this is true. I would appreciate if experts could comment in this area.
How easy it is to develop Cubes in Cognos compared to SSAS.?
|||Interesting points. My thinking was that these semantic layer solutions are more for deployments that don't utilize dimensional models but instead get their data straight from the OLTP data sources. Without someone building these dimensional models on the database side to simplify the data, the report designers would at least have the ability to simplify some of the data with these BI semantic layers perhaps at some cost to performance. So in essence, these BI semantic layers may only provide value for initial or prototyping deployments or any other situation where there are no dimensional models, either relational or mutidimensional based.Any thoughts on that.Thanks for your input.
|||In general, SSAS is a database so its primary users are DBAs. One area where you do need developer experience is enhancing the cube with business calculations which requires MDX knowledge. But both Cognos and SSAS real-life cubes will require to be extended. MDX is a standard language and there are books written for MDX. There aren't any books written for Cognos cubes or Cognos in general.
Migration from Cognos ...
Hi,
I've been asked to investigate for a client the migration from Cognos Decisionstream (7.1), PowerPlay and Impromptu (7.3) to SQL Server 2005. Key driver (so far) is to reduce licensing costs. I can't say I'm a Cognos guru.. so..
Has anyone done this / doing this / thinking about this?
What are the key benefits ?
What does Cognos offer that we don't ?
What are the biggest issues ?
Did you have any problems ?
What other items should I be considering ?
Thanks
www.SQLobSERVER.com
Here is what I found from my research.
1) There are no front-end tools available from Microsoft especially for Cube analysis. Where as in cognos we have PowerPlay Web for this.
2) There is no BI custom portal available from Microsoft. I saw there is some sample BI Portal app provided by Microsoft that is based on Share point services but this cannot be used for production environment.
Looks like Microsoft is totally depending on third party vendors for web based front-end solutions. I found that there is company called Panorama that provides front end web based solutions to SQL Server 2005 BI stuff. If you find any thing from your investigation please let me know.
I too have been asked to do this same evaluation for the company I work at.
We will be having a demo from MS this afternoon and I will post more information at that time.
What I can offer at this time is what my research has yielded.
So far it looks like MS is going to be excellent for the back end work (I.E. building the cubes using the new UDM structures)
What is not clear at this point is how Cognos Cubes will be able to be converted into a MS format?
In addition, I found ProClarity also has some front end modeling tools.
Lets see what MS has to say this afternoon!
|||Fresh out of the MS Demo.
This tool certainly has potential. The integration with the rest of the microsoft suite is exceptional as usual for microsoft products.
They do have end user tools that are in fact web based. This product is still maturing but in my opinion is ready for the market.
I will be going to a Cognos webinar next week and will report back my findings as to how well the two compare and also in relation to the needs of this company. Since this company already has Cognos, there is pressure to remain on that product. However, being a forward thinking company and a publicly traded company it is in the best interest to investigate further the possiblity of this microsoft shop to mirgrate over to the Microsoft tool.
I will post another update next week.
BTW- There was no mention of a converstion tool between Cognos and This MS product.
|||Matrix from a company called DataJungle can support both Cognos and Microsoft cubes in a single, integrated dashboard and analysis product. An excellent front end for those looking to migrate from the Cognos to Microsoft BI platform, without having to rip out there Cognos investment. The company seems to be hot in this market...especially given that Series 8 from Cognos is very expensive...more and more Cognos customers will be moving to Microsoft.
JG
|||Couple of more data points for you:
regarding issue #1: Have you looked at Report Builder in SQL Server 2005 Reporting Services? An end user can use this to design report on top of an Analysis Services cube.
regarding issue #2: We have been working very hard to get a solution to this - we are integrating reporting services with Windows SharePoint Services to enable this scenario. You can download a prerelease build of the Microsoft SQL Server 2005 Reporting Services Add-in for Microsoft SharePoint Technologies - Community Technology Preview (CTP) here:
http://www.microsoft.com/downloads/details.aspx?FamilyID=4E50BE6E-3F92-4552-A78C-B3BE1D94D5DA&displaylang=en&mg_id=10049
This is still baking but it will be available with SQL Server 2005 SP2 and will work with Microsoft Office SharePoint Server 2007.
Hope that helps,
-Lukasz
|||1) There are no front-end tools available from Microsoft especially for Cube analysis. Where as in cognos we have PowerPlay Web for this.
Really? How about Excel, Report Builder, or Proclarity?
2) There is no BI custom portal available from Microsoft. I saw there is some sample BI Portal app provided by Microsoft that is based on Share point services but this cannot be used for production environment.
Why?
|||>What are the key benefits (from the first post)?
Ask Cognos to show you how you can integrate custom applications with their backend services and you will have a key benefit 
Also, for a fraction of the Cognos licensing cost, you will get more feature-rich MS offerings in almost all areas. Cognos doesn't have a relational database and data mining offerings. They have a very basic ETL product. UDM wins hands down against PowerPlay. SSRS (both standard and ad-hoc reporting) is more powerful than their Report Studio (or Impromptu for that matter). Instead of a hodge podge of technologies, with MS you will get a well-integrated BI platform.
Teo,
You are still talking about the same "BI" tool in MS that, in their last service pack, REMOVED the 'select all' functionality in reporting services, right? did you just use the work "powerful" in reference to Report Builder? Really?
|||ChicagoClone,
I said "more powerful" (than Cognos), I didn't say "perfect" 
. BTW, the "select all" is back in SP2... and there is much rejoicing throughout the land. From the readme file:
In SQL Server 2005 Reporting Services (SSRS), a Select All check box was automatically added when you created an available values list for a multivalue report parameter. If you upgraded to SQL Server 2005 Service Pack 1 (SP1), the Select All check box was no longer available. In SQL Server 2005 Service Pack 2 (SP2), the Select All check box has been restored.
|||
Any comments about lack of semantic layer for the SSRS report designer (not report builder which can use Report Models). Cognos uses Framework manager for the semantic layer but do you think that people can do without this type of functionality in SSRS.
|||I am not sure it is such a good idea to have that layer. First, you need to wait for Cognos to write a provider for each database version you need to support. Second, such a layer may introduce performance issues because it auto-generates queries for you. Instead, I would encourage you consider UDM in SSAS 2005 as the ultimate semantic layer which can be integrated with many MS and third-party reporting tools as opposed to Cognos tools only in the case of the Framework manager.
|||One another thing I have heard people complain about is, the person who could build the cubes in either of these environments. I have heard users complain that you will need a developer to build cubes in SSAS where as person with limited knowledge can easily create the cubes in Cognos. I do not have experience in Cognos so not sure how much of this is true. I would appreciate if experts could comment in this area.
How easy it is to develop Cubes in Cognos compared to SSAS.?
|||Interesting points. My thinking was that these semantic layer solutions are more for deployments that don't utilize dimensional models but instead get their data straight from the OLTP data sources. Without someone building these dimensional models on the database side to simplify the data, the report designers would at least have the ability to simplify some of the data with these BI semantic layers perhaps at some cost to performance. So in essence, these BI semantic layers may only provide value for initial or prototyping deployments or any other situation where there are no dimensional models, either relational or mutidimensional based.Any thoughts on that.Thanks for your input.
|||In general, SSAS is a database so its primary users are DBAs. One area where you do need developer experience is enhancing the cube with business calculations which requires MDX knowledge. But both Cognos and SSAS real-life cubes will require to be extended. MDX is a standard language and there are books written for MDX. There aren't any books written for Cognos cubes or Cognos in general.
Migration from COBOL400 to SQL Server
I want to migrate from COBOL400/AS400 to MS SQL Server, can any body tell me the way I can perform Data migration/Transfer without any loss of dataI'd be willing to bet that given enough of a description of what you want to do, that someone can tell you a relatively easy way to do it. So far, you haven't given enough information for me to even start.
-PatP|||1. Analyze the data in the old system.
2. Analyze the business requirements for usage of the data.
3. Analyze shortcomings in current data and structure.
4. Model a relational database(s) that accurately reflects and provides for 1,2,3.
5. In parallel to 4, you will probably need to create new apps or perform development to interface with new model and accurately reflect business needs.
6. Create a migration routine (preferrably repeatable and modular) to move data between systems.
7. Pray if you're into that type of thing. Do this a LOT.
-PatP|||1. Analyze the data in the old system.
2. Analyze the business requirements for usage of the data.
3. Analyze shortcomings in current data and structure.
4. Model a relational database(s) that accurately reflects and provides for 1,2,3.
5. In parallel to 4, you will probably need to create new apps or perform development to interface with new model and accurately reflect business needs.
6. Create a migration routine (preferrably repeatable and modular) to move data between systems.
7. Pray if you're into that type of thing. Do this a LOT.
migration from Beta 2 to Final edition
Will you please let me know how to have a smooth and NO DOWNTIME migration
from Beta 2 to Final version of SQL 2005? As per Microsoft, SQL 2005 final
version does not upgrade itself from Beta 2.
Thanks
John
I don't think there's any way to do a "smooth" migration. You cannot do an
in-place upgrade, so you'll have to do a side-by-side migration. I'm not
certain whether backed-up Beta 2 databases will restore on an RTM instance.
That's something you'll have to test on your end. Have you listened to any
of the migration webcasts? They discuss how to do side-by-side migrations
somewhat smoothly -- but no downtime might not be possible, depending on
your definition of that term.
Speaking of which, if you are running Beta 2 in production can we assume
that you're a TAP customer? Ask Microsoft for assistance.
Adam Machanic
Pro SQL Server 2005, available now
http://www.apress.com/book/bookDisplay.html?bID=457
"John" <netconsul@.gmail.com> wrote in message
news:OX$3NSc9FHA.1420@.TK2MSFTNGP09.phx.gbl...
> Will you please let me know how to have a smooth and NO DOWNTIME migration
> from Beta 2 to Final version of SQL 2005? As per Microsoft, SQL 2005 final
> version does not upgrade itself from Beta 2.
> Thanks
> John
>
from Beta 2 to Final version of SQL 2005? As per Microsoft, SQL 2005 final
version does not upgrade itself from Beta 2.
Thanks
John
I don't think there's any way to do a "smooth" migration. You cannot do an
in-place upgrade, so you'll have to do a side-by-side migration. I'm not
certain whether backed-up Beta 2 databases will restore on an RTM instance.
That's something you'll have to test on your end. Have you listened to any
of the migration webcasts? They discuss how to do side-by-side migrations
somewhat smoothly -- but no downtime might not be possible, depending on
your definition of that term.
Speaking of which, if you are running Beta 2 in production can we assume
that you're a TAP customer? Ask Microsoft for assistance.
Adam Machanic
Pro SQL Server 2005, available now
http://www.apress.com/book/bookDisplay.html?bID=457
"John" <netconsul@.gmail.com> wrote in message
news:OX$3NSc9FHA.1420@.TK2MSFTNGP09.phx.gbl...
> Will you please let me know how to have a smooth and NO DOWNTIME migration
> from Beta 2 to Final version of SQL 2005? As per Microsoft, SQL 2005 final
> version does not upgrade itself from Beta 2.
> Thanks
> John
>
migration from Beta 2 to Final edition
Will you please let me know how to have a smooth and NO DOWNTIME migration
from Beta 2 to Final version of SQL 2005? As per Microsoft, SQL 2005 final
version does not upgrade itself from Beta 2.
Thanks
JohnI don't think there's any way to do a "smooth" migration. You cannot do an
in-place upgrade, so you'll have to do a side-by-side migration. I'm not
certain whether backed-up Beta 2 databases will restore on an RTM instance.
That's something you'll have to test on your end. Have you listened to any
of the migration webcasts? They discuss how to do side-by-side migrations
somewhat smoothly -- but no downtime might not be possible, depending on
your definition of that term.
Speaking of which, if you are running Beta 2 in production can we assume
that you're a TAP customer? Ask Microsoft for assistance.
Adam Machanic
Pro SQL Server 2005, available now
http://www.apress.com/book/bookDisplay.html?bID=457
--
"John" <netconsul@.gmail.com> wrote in message
news:OX$3NSc9FHA.1420@.TK2MSFTNGP09.phx.gbl...
> Will you please let me know how to have a smooth and NO DOWNTIME migration
> from Beta 2 to Final version of SQL 2005? As per Microsoft, SQL 2005 final
> version does not upgrade itself from Beta 2.
> Thanks
> John
>
from Beta 2 to Final version of SQL 2005? As per Microsoft, SQL 2005 final
version does not upgrade itself from Beta 2.
Thanks
JohnI don't think there's any way to do a "smooth" migration. You cannot do an
in-place upgrade, so you'll have to do a side-by-side migration. I'm not
certain whether backed-up Beta 2 databases will restore on an RTM instance.
That's something you'll have to test on your end. Have you listened to any
of the migration webcasts? They discuss how to do side-by-side migrations
somewhat smoothly -- but no downtime might not be possible, depending on
your definition of that term.
Speaking of which, if you are running Beta 2 in production can we assume
that you're a TAP customer? Ask Microsoft for assistance.
Adam Machanic
Pro SQL Server 2005, available now
http://www.apress.com/book/bookDisplay.html?bID=457
--
"John" <netconsul@.gmail.com> wrote in message
news:OX$3NSc9FHA.1420@.TK2MSFTNGP09.phx.gbl...
> Will you please let me know how to have a smooth and NO DOWNTIME migration
> from Beta 2 to Final version of SQL 2005? As per Microsoft, SQL 2005 final
> version does not upgrade itself from Beta 2.
> Thanks
> John
>
migration from Beta 2 to Final edition
Will you please let me know how to have a smooth and NO DOWNTIME migration
from Beta 2 to Final version of SQL 2005? As per Microsoft, SQL 2005 final
version does not upgrade itself from Beta 2.
Thanks
JohnI don't think there's any way to do a "smooth" migration. You cannot do an
in-place upgrade, so you'll have to do a side-by-side migration. I'm not
certain whether backed-up Beta 2 databases will restore on an RTM instance.
That's something you'll have to test on your end. Have you listened to any
of the migration webcasts? They discuss how to do side-by-side migrations
somewhat smoothly -- but no downtime might not be possible, depending on
your definition of that term.
Speaking of which, if you are running Beta 2 in production can we assume
that you're a TAP customer? Ask Microsoft for assistance.
Adam Machanic
Pro SQL Server 2005, available now
http://www.apress.com/book/bookDisplay.html?bID=457
--
"John" <netconsul@.gmail.com> wrote in message
news:OX$3NSc9FHA.1420@.TK2MSFTNGP09.phx.gbl...
> Will you please let me know how to have a smooth and NO DOWNTIME migration
> from Beta 2 to Final version of SQL 2005? As per Microsoft, SQL 2005 final
> version does not upgrade itself from Beta 2.
> Thanks
> John
>
from Beta 2 to Final version of SQL 2005? As per Microsoft, SQL 2005 final
version does not upgrade itself from Beta 2.
Thanks
JohnI don't think there's any way to do a "smooth" migration. You cannot do an
in-place upgrade, so you'll have to do a side-by-side migration. I'm not
certain whether backed-up Beta 2 databases will restore on an RTM instance.
That's something you'll have to test on your end. Have you listened to any
of the migration webcasts? They discuss how to do side-by-side migrations
somewhat smoothly -- but no downtime might not be possible, depending on
your definition of that term.
Speaking of which, if you are running Beta 2 in production can we assume
that you're a TAP customer? Ask Microsoft for assistance.
Adam Machanic
Pro SQL Server 2005, available now
http://www.apress.com/book/bookDisplay.html?bID=457
--
"John" <netconsul@.gmail.com> wrote in message
news:OX$3NSc9FHA.1420@.TK2MSFTNGP09.phx.gbl...
> Will you please let me know how to have a smooth and NO DOWNTIME migration
> from Beta 2 to Final version of SQL 2005? As per Microsoft, SQL 2005 final
> version does not upgrade itself from Beta 2.
> Thanks
> John
>
Migration from Access to Sql Server
Hi, I import my tables from Access to SQl Server 2000
actually MSDE with the SQL server tools.
actually MSDE with the SQL server tools.
Is there a way to have the same table name as in access
because in SQl server it seems I have to call my
tables that way : testdb.dbo.po instead of just po in VB access.
That means changing all my Querys :(
Also I installed sql server on 1 PC (WinXp Pro) on my network and install the client
tools on another PC (Win98) but how can I access SQL Server from that PC?
When I'm in VB and do a connection with the ADO object I don't get
any server listed in it??
My connection string use on my local PC with server on it is working fine.
StrSqlSrv = "Provider=SQLOLEDB.1;Integrated Security=SSPI;" & _
"Persist Security Info=False;Initial Catalog=imdedi;" & _
"Data Source=" & servername
Also Is it possible to package (With VB package) a program using MSDE so that it will
install MSDE and create all tables on the client PC?
Can DAO connects to sql server?
Thank you. I know... alot of questions :)> That means changing all my Querys :(
no it doesn't. try it. you can use
databasename.username.tablename
or just
tablename|||Hi, this is my connections that work fine with ADO
The only thing I do is changing the ConnectionString to my Sql Server
To make it work I have to use the .dbo thing....
This works ->> testdb.dbo.company
company.ConnectionString = StrSqlSrv
company.RecordSource = "SELECT compno,compname,telno FROM company ORDER BY compno;"
company.Refresh
Here is the error I get
A message box display Invalif Object Name company
When I click OK then
a run-time error"
(80040e37) Method 'Refresh' of Object 'IAdodc' failed|||Hi, I was able to access my tables without the .dbo
I was missing a user...
Migration from Access : AutoNumber
I have proceed to an Access Migration to SQL Server.
The Access field type "autonumber" are now
of type "int" in SQL Server.
I do not see in SQL Server a way to tell him that it is
an auto counter.
Is this transparent ?
Will SQL Server manage it alone ?
Thanks, PierreI'm not sure of your exact question, but in SQL Server the equivalent of "Autonumber" is IDENTITY. If you want to count by one, then its IDENTITY (1,1).|||I do not see the field type "identity" in SQL Server ?
My question was, in Access we have the type of field
"automatic number" which is an auto incremental integer field.
(often ID numbers)
After migration, this one become a simple "int" field.
So in my sql statement, I never fullfill this field through
the "insert", because it is automatic in ACCESS.
Now, under SQL Server, it bugs.
So I need to tell to SQL Server that this is an atomatic incremental field.
I do not see how to do that.
Thanks,
Pierre.|||Pierre,
The IDENTITY property is not a data type, but an attribute that can be assigned to INT data types (and other data types as well). From EM, you can right-click on the table and go into Design. In the design, click on the field you wish to set to auto-increment. In the area beneath the listing of columns, you will see a list of attributes (Description, Default Value, Precision, Scale, Identity, Identity Seed, Indentity Increment, etc...).
Click on the Identity attribute and set it equal to "Yes".
Alternatively, you may use a script to create the table. Here is a generic script that you may use. Note, however, that you will have issues with trying to do it this way. Obviously, you cannot create a table with the same name over the existing table. Also, if you create a temporary table and push the data from your existing table into it, you will have to enable Identity Insert (see SQL BOL). However, I thought you should see the DDL for creating a table with an Identity Column so that you might better understand what SQL is doing.
CREATE TABLE [dbo].[tbl_MyTable] (
[int] IDENTITY (1, 1) NOT NULL ,
[MyColumn1] [varchar] (50) NOT NULL ,
[MyColumn2] [varchar] (3000) NULL ,
[MyColumn3] [varchar] (50) NOT NULL
) ON [PRIMARY]
Also not the following:
1. The syntax for IDENTITY is INDENTITY (Seed, Increment)
2. Seed is a starting value. You may not want to start at 1
3. Increment is a value by which the increment the identity. You may want to increment by a value other than 1.
HTH,
Hugh Scott
See SQL BOL for more information on IDENTITY
[i]Originally posted by Plarde
I do not see the field type "identity" in SQL Server ?
My question was, in Access we have the type of field
"automatic number" which is an auto incremental integer field.
(often ID numbers)
After migration, this one become a simple "int" field.
So in my sql statement, I never fullfill this field through
the "insert", because it is automatic in ACCESS.
Now, under SQL Server, it bugs.
So I need to tell to SQL Server that this is an atomatic incremental field.
I do not see how to do that.
Thanks,
Pierre.|||Thank you very much,
that was the solution.
It does work fine.
Pierre.
The Access field type "autonumber" are now
of type "int" in SQL Server.
I do not see in SQL Server a way to tell him that it is
an auto counter.
Is this transparent ?
Will SQL Server manage it alone ?
Thanks, PierreI'm not sure of your exact question, but in SQL Server the equivalent of "Autonumber" is IDENTITY. If you want to count by one, then its IDENTITY (1,1).|||I do not see the field type "identity" in SQL Server ?
My question was, in Access we have the type of field
"automatic number" which is an auto incremental integer field.
(often ID numbers)
After migration, this one become a simple "int" field.
So in my sql statement, I never fullfill this field through
the "insert", because it is automatic in ACCESS.
Now, under SQL Server, it bugs.
So I need to tell to SQL Server that this is an atomatic incremental field.
I do not see how to do that.
Thanks,
Pierre.|||Pierre,
The IDENTITY property is not a data type, but an attribute that can be assigned to INT data types (and other data types as well). From EM, you can right-click on the table and go into Design. In the design, click on the field you wish to set to auto-increment. In the area beneath the listing of columns, you will see a list of attributes (Description, Default Value, Precision, Scale, Identity, Identity Seed, Indentity Increment, etc...).
Click on the Identity attribute and set it equal to "Yes".
Alternatively, you may use a script to create the table. Here is a generic script that you may use. Note, however, that you will have issues with trying to do it this way. Obviously, you cannot create a table with the same name over the existing table. Also, if you create a temporary table and push the data from your existing table into it, you will have to enable Identity Insert (see SQL BOL). However, I thought you should see the DDL for creating a table with an Identity Column so that you might better understand what SQL is doing.
CREATE TABLE [dbo].[tbl_MyTable] (
[int] IDENTITY (1, 1) NOT NULL ,
[MyColumn1] [varchar] (50) NOT NULL ,
[MyColumn2] [varchar] (3000) NULL ,
[MyColumn3] [varchar] (50) NOT NULL
) ON [PRIMARY]
Also not the following:
1. The syntax for IDENTITY is INDENTITY (Seed, Increment)
2. Seed is a starting value. You may not want to start at 1
3. Increment is a value by which the increment the identity. You may want to increment by a value other than 1.
HTH,
Hugh Scott
See SQL BOL for more information on IDENTITY
[i]Originally posted by Plarde
I do not see the field type "identity" in SQL Server ?
My question was, in Access we have the type of field
"automatic number" which is an auto incremental integer field.
(often ID numbers)
After migration, this one become a simple "int" field.
So in my sql statement, I never fullfill this field through
the "insert", because it is automatic in ACCESS.
Now, under SQL Server, it bugs.
So I need to tell to SQL Server that this is an atomatic incremental field.
I do not see how to do that.
Thanks,
Pierre.|||Thank you very much,
that was the solution.
It does work fine.
Pierre.
Migration from 7 to 2000
Hello,
How compatible is database Backup from MSSQL 7 to 2000?
Database has a lot of Procedures. Can there be syntax Problems?
Should I change ODBC 3.70 to ODBC 2000 (Sql server versions)
Regards,
Arto
Arto Ylikotila arto.ylikotila@.santamargarita.fiThere is always a possibility, but it is unlikely that you need to do any si
gnificant code changes, if at all.
One thing is datatype comparisons in WHERE clause, where SQL Server converte
d the constant side to the column
side. Today, SQL Server does the conversions according to the documented "da
tatype precedence" in Books
Online.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Arto Ylikotila" <arto.ylikotila@.santamargarita.fi> wrote in message
news:%23GX1XB0NEHA.3380@.TK2MSFTNGP11.phx.gbl...
> Hello,
> How compatible is database Backup from MSSQL 7 to 2000?
> Database has a lot of Procedures. Can there be syntax Problems?
> Should I change ODBC 3.70 to ODBC 2000 (Sql server versions)
> Regards,
> Arto
> --
> Arto Ylikotila arto.ylikotila@.santamargarita.fi
>|||Another issue I know is replacement of all SUSER_NAME calls with
SUSER_SNAME; if you use direct queries to syslogins and sysusers system
tables then you should replace joins made by id with joins made by sid (but
better use system procedures instead)
Database backup from MSSQL7 fully compatible with 2000... moreover you may
attach DB from MSSQL7 directly to MSSQL2000, and all the needed internal
changes will be made by MSSQL2000 itself. Note that you won't be able to
attach DB back onto MSSQL7 after using it as 2000's DB. Same thing with
2000's backups - they can't be restored with MSSQL7 engine
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:u5QWmD0NEHA.680@.TK2MSFTNGP11.phx.gbl...
> There is always a possibility, but it is unlikely that you need to do any
significant code changes, if at all.
> One thing is datatype comparisons in WHERE clause, where SQL Server
converted the constant side to the column
> side. Today, SQL Server does the conversions according to the documented
"datatype precedence" in Books[vbcol=seagreen]
> Online.
> "Arto Ylikotila" <arto.ylikotila@.santamargarita.fi> wrote in message
> news:%23GX1XB0NEHA.3380@.TK2MSFTNGP11.phx.gbl...|||Hi,
SQL 7.0 Backups are fully compatible with SQL 2000.
For SQL 2000 (I assume that SP3a and post fixes are applied ) MS recommends
MDAC versions > 2.6x.
We had several problems with clients that has mdac versions < 2.6x (speciall
y sql servers with multiple instances and also have some localization probl
ems).
Regards..
How compatible is database Backup from MSSQL 7 to 2000?
Database has a lot of Procedures. Can there be syntax Problems?
Should I change ODBC 3.70 to ODBC 2000 (Sql server versions)
Regards,
Arto
Arto Ylikotila arto.ylikotila@.santamargarita.fiThere is always a possibility, but it is unlikely that you need to do any si
gnificant code changes, if at all.
One thing is datatype comparisons in WHERE clause, where SQL Server converte
d the constant side to the column
side. Today, SQL Server does the conversions according to the documented "da
tatype precedence" in Books
Online.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Arto Ylikotila" <arto.ylikotila@.santamargarita.fi> wrote in message
news:%23GX1XB0NEHA.3380@.TK2MSFTNGP11.phx.gbl...
> Hello,
> How compatible is database Backup from MSSQL 7 to 2000?
> Database has a lot of Procedures. Can there be syntax Problems?
> Should I change ODBC 3.70 to ODBC 2000 (Sql server versions)
> Regards,
> Arto
> --
> Arto Ylikotila arto.ylikotila@.santamargarita.fi
>|||Another issue I know is replacement of all SUSER_NAME calls with
SUSER_SNAME; if you use direct queries to syslogins and sysusers system
tables then you should replace joins made by id with joins made by sid (but
better use system procedures instead)
Database backup from MSSQL7 fully compatible with 2000... moreover you may
attach DB from MSSQL7 directly to MSSQL2000, and all the needed internal
changes will be made by MSSQL2000 itself. Note that you won't be able to
attach DB back onto MSSQL7 after using it as 2000's DB. Same thing with
2000's backups - they can't be restored with MSSQL7 engine
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:u5QWmD0NEHA.680@.TK2MSFTNGP11.phx.gbl...
> There is always a possibility, but it is unlikely that you need to do any
significant code changes, if at all.
> One thing is datatype comparisons in WHERE clause, where SQL Server
converted the constant side to the column
> side. Today, SQL Server does the conversions according to the documented
"datatype precedence" in Books[vbcol=seagreen]
> Online.
> "Arto Ylikotila" <arto.ylikotila@.santamargarita.fi> wrote in message
> news:%23GX1XB0NEHA.3380@.TK2MSFTNGP11.phx.gbl...|||Hi,
SQL 7.0 Backups are fully compatible with SQL 2000.
For SQL 2000 (I assume that SP3a and post fixes are applied ) MS recommends
MDAC versions > 2.6x.
We had several problems with clients that has mdac versions < 2.6x (speciall
y sql servers with multiple instances and also have some localization probl
ems).
Regards..
Migration from 7 to 2000
Hello,
How compatible is database Backup from MSSQL 7 to 2000?
Database has a lot of Procedures. Can there be syntax Problems?
Should I change ODBC 3.70 to ODBC 2000 (Sql server versions)
Regards,
Arto
Arto Ylikotila arto.ylikotila@.santamargarita.fi
There is always a possibility, but it is unlikely that you need to do any significant code changes, if at all.
One thing is datatype comparisons in WHERE clause, where SQL Server converted the constant side to the column
side. Today, SQL Server does the conversions according to the documented "datatype precedence" in Books
Online.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Arto Ylikotila" <arto.ylikotila@.santamargarita.fi> wrote in message
news:%23GX1XB0NEHA.3380@.TK2MSFTNGP11.phx.gbl...
> Hello,
> How compatible is database Backup from MSSQL 7 to 2000?
> Database has a lot of Procedures. Can there be syntax Problems?
> Should I change ODBC 3.70 to ODBC 2000 (Sql server versions)
> Regards,
> Arto
> --
> Arto Ylikotila arto.ylikotila@.santamargarita.fi
>
|||Another issue I know is replacement of all SUSER_NAME calls with
SUSER_SNAME; if you use direct queries to syslogins and sysusers system
tables then you should replace joins made by id with joins made by sid (but
better use system procedures instead)
Database backup from MSSQL7 fully compatible with 2000... moreover you may
attach DB from MSSQL7 directly to MSSQL2000, and all the needed internal
changes will be made by MSSQL2000 itself. Note that you won't be able to
attach DB back onto MSSQL7 after using it as 2000's DB. Same thing with
2000's backups - they can't be restored with MSSQL7 engine
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:u5QWmD0NEHA.680@.TK2MSFTNGP11.phx.gbl...
> There is always a possibility, but it is unlikely that you need to do any
significant code changes, if at all.
> One thing is datatype comparisons in WHERE clause, where SQL Server
converted the constant side to the column
> side. Today, SQL Server does the conversions according to the documented
"datatype precedence" in Books[vbcol=seagreen]
> Online.
> "Arto Ylikotila" <arto.ylikotila@.santamargarita.fi> wrote in message
> news:%23GX1XB0NEHA.3380@.TK2MSFTNGP11.phx.gbl...
|||Hi,
SQL 7.0 Backups are fully compatible with SQL 2000.
For SQL 2000 (I assume that SP3a and post fixes are applied ) MS recommends MDAC versions > 2.6x.
We had several problems with clients that has mdac versions < 2.6x (specially sql servers with multiple instances and also have some localization problems).
Regards..
How compatible is database Backup from MSSQL 7 to 2000?
Database has a lot of Procedures. Can there be syntax Problems?
Should I change ODBC 3.70 to ODBC 2000 (Sql server versions)
Regards,
Arto
Arto Ylikotila arto.ylikotila@.santamargarita.fi
There is always a possibility, but it is unlikely that you need to do any significant code changes, if at all.
One thing is datatype comparisons in WHERE clause, where SQL Server converted the constant side to the column
side. Today, SQL Server does the conversions according to the documented "datatype precedence" in Books
Online.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Arto Ylikotila" <arto.ylikotila@.santamargarita.fi> wrote in message
news:%23GX1XB0NEHA.3380@.TK2MSFTNGP11.phx.gbl...
> Hello,
> How compatible is database Backup from MSSQL 7 to 2000?
> Database has a lot of Procedures. Can there be syntax Problems?
> Should I change ODBC 3.70 to ODBC 2000 (Sql server versions)
> Regards,
> Arto
> --
> Arto Ylikotila arto.ylikotila@.santamargarita.fi
>
|||Another issue I know is replacement of all SUSER_NAME calls with
SUSER_SNAME; if you use direct queries to syslogins and sysusers system
tables then you should replace joins made by id with joins made by sid (but
better use system procedures instead)
Database backup from MSSQL7 fully compatible with 2000... moreover you may
attach DB from MSSQL7 directly to MSSQL2000, and all the needed internal
changes will be made by MSSQL2000 itself. Note that you won't be able to
attach DB back onto MSSQL7 after using it as 2000's DB. Same thing with
2000's backups - they can't be restored with MSSQL7 engine
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:u5QWmD0NEHA.680@.TK2MSFTNGP11.phx.gbl...
> There is always a possibility, but it is unlikely that you need to do any
significant code changes, if at all.
> One thing is datatype comparisons in WHERE clause, where SQL Server
converted the constant side to the column
> side. Today, SQL Server does the conversions according to the documented
"datatype precedence" in Books[vbcol=seagreen]
> Online.
> "Arto Ylikotila" <arto.ylikotila@.santamargarita.fi> wrote in message
> news:%23GX1XB0NEHA.3380@.TK2MSFTNGP11.phx.gbl...
|||Hi,
SQL 7.0 Backups are fully compatible with SQL 2000.
For SQL 2000 (I assume that SP3a and post fixes are applied ) MS recommends MDAC versions > 2.6x.
We had several problems with clients that has mdac versions < 2.6x (specially sql servers with multiple instances and also have some localization problems).
Regards..
Migration from 7 to 2000
Hello,
How compatible is database Backup from MSSQL 7 to 2000?
Database has a lot of Procedures. Can there be syntax Problems?
Should I change ODBC 3.70 to ODBC 2000 (Sql server versions)
Regards,
Arto
--
Arto Ylikotila arto.ylikotila@.santamargarita.fiThere is always a possibility, but it is unlikely that you need to do any significant code changes, if at all.
One thing is datatype comparisons in WHERE clause, where SQL Server converted the constant side to the column
side. Today, SQL Server does the conversions according to the documented "datatype precedence" in Books
Online.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Arto Ylikotila" <arto.ylikotila@.santamargarita.fi> wrote in message
news:%23GX1XB0NEHA.3380@.TK2MSFTNGP11.phx.gbl...
> Hello,
> How compatible is database Backup from MSSQL 7 to 2000?
> Database has a lot of Procedures. Can there be syntax Problems?
> Should I change ODBC 3.70 to ODBC 2000 (Sql server versions)
> Regards,
> Arto
> --
> Arto Ylikotila arto.ylikotila@.santamargarita.fi
>|||Another issue I know is replacement of all SUSER_NAME calls with
SUSER_SNAME; if you use direct queries to syslogins and sysusers system
tables then you should replace joins made by id with joins made by sid (but
better use system procedures instead)
Database backup from MSSQL7 fully compatible with 2000... moreover you may
attach DB from MSSQL7 directly to MSSQL2000, and all the needed internal
changes will be made by MSSQL2000 itself. Note that you won't be able to
attach DB back onto MSSQL7 after using it as 2000's DB. Same thing with
2000's backups - they can't be restored with MSSQL7 engine
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:u5QWmD0NEHA.680@.TK2MSFTNGP11.phx.gbl...
> There is always a possibility, but it is unlikely that you need to do any
significant code changes, if at all.
> One thing is datatype comparisons in WHERE clause, where SQL Server
converted the constant side to the column
> side. Today, SQL Server does the conversions according to the documented
"datatype precedence" in Books
> Online.
> "Arto Ylikotila" <arto.ylikotila@.santamargarita.fi> wrote in message
> news:%23GX1XB0NEHA.3380@.TK2MSFTNGP11.phx.gbl...
> > Hello,
> >
> > How compatible is database Backup from MSSQL 7 to 2000?
> > Database has a lot of Procedures. Can there be syntax Problems?
> >
> > Should I change ODBC 3.70 to ODBC 2000 (Sql server versions)|||Hi
SQL 7.0 Backups are fully compatible with SQL 2000
For SQL 2000 (I assume that SP3a and post fixes are applied ) MS recommends MDAC versions > 2.6x
We had several problems with clients that has mdac versions < 2.6x (specially sql servers with multiple instances and also have some localization problems)
Regards.
How compatible is database Backup from MSSQL 7 to 2000?
Database has a lot of Procedures. Can there be syntax Problems?
Should I change ODBC 3.70 to ODBC 2000 (Sql server versions)
Regards,
Arto
--
Arto Ylikotila arto.ylikotila@.santamargarita.fiThere is always a possibility, but it is unlikely that you need to do any significant code changes, if at all.
One thing is datatype comparisons in WHERE clause, where SQL Server converted the constant side to the column
side. Today, SQL Server does the conversions according to the documented "datatype precedence" in Books
Online.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Arto Ylikotila" <arto.ylikotila@.santamargarita.fi> wrote in message
news:%23GX1XB0NEHA.3380@.TK2MSFTNGP11.phx.gbl...
> Hello,
> How compatible is database Backup from MSSQL 7 to 2000?
> Database has a lot of Procedures. Can there be syntax Problems?
> Should I change ODBC 3.70 to ODBC 2000 (Sql server versions)
> Regards,
> Arto
> --
> Arto Ylikotila arto.ylikotila@.santamargarita.fi
>|||Another issue I know is replacement of all SUSER_NAME calls with
SUSER_SNAME; if you use direct queries to syslogins and sysusers system
tables then you should replace joins made by id with joins made by sid (but
better use system procedures instead)
Database backup from MSSQL7 fully compatible with 2000... moreover you may
attach DB from MSSQL7 directly to MSSQL2000, and all the needed internal
changes will be made by MSSQL2000 itself. Note that you won't be able to
attach DB back onto MSSQL7 after using it as 2000's DB. Same thing with
2000's backups - they can't be restored with MSSQL7 engine
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:u5QWmD0NEHA.680@.TK2MSFTNGP11.phx.gbl...
> There is always a possibility, but it is unlikely that you need to do any
significant code changes, if at all.
> One thing is datatype comparisons in WHERE clause, where SQL Server
converted the constant side to the column
> side. Today, SQL Server does the conversions according to the documented
"datatype precedence" in Books
> Online.
> "Arto Ylikotila" <arto.ylikotila@.santamargarita.fi> wrote in message
> news:%23GX1XB0NEHA.3380@.TK2MSFTNGP11.phx.gbl...
> > Hello,
> >
> > How compatible is database Backup from MSSQL 7 to 2000?
> > Database has a lot of Procedures. Can there be syntax Problems?
> >
> > Should I change ODBC 3.70 to ODBC 2000 (Sql server versions)|||Hi
SQL 7.0 Backups are fully compatible with SQL 2000
For SQL 2000 (I assume that SP3a and post fixes are applied ) MS recommends MDAC versions > 2.6x
We had several problems with clients that has mdac versions < 2.6x (specially sql servers with multiple instances and also have some localization problems)
Regards.
migration from 32 bit to 64 bit
Hi, I want to upgrade a server from a 32 bit system to a 64 bit system, will
i be able to use my same license with the new server or should i need to buy
a new license for the 64 bit server?
Thanks in advance for the help.
Regards,> Hi, I want to upgrade a server from a 32 bit system to a 64 bit system,
> will
> i be able to use my same license with the new server or should i need to
> buy
> a new license for the 64 bit server?
<Excerpt href="http://links.10026.com/?link=">http://www.microsoft.com/sql/howtobuy/default.mspx">
While you should choose the platform that matches your current hardware (in
order to obtain the appropriate media), SQL Server licenses are not platform
specific. For example, if you currently have a 32-bit server and plan to
upgrade the hardware to 64 bit in the future, you can purchase a 32-bit SKU
today, and later switch to 64 bit without having to
purchase an additional license.
</Excerpt>
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Frivas" <Frivas@.discussions.microsoft.com> wrote in message
news:E1927DBA-0E12-47D1-AC7C-2A132DFFC626@.microsoft.com...
> Hi, I want to upgrade a server from a 32 bit system to a 64 bit system,
> will
> i be able to use my same license with the new server or should i need to
> buy
> a new license for the 64 bit server?
> Thanks in advance for the help.
> Regards,
>
i be able to use my same license with the new server or should i need to buy
a new license for the 64 bit server?
Thanks in advance for the help.
Regards,> Hi, I want to upgrade a server from a 32 bit system to a 64 bit system,
> will
> i be able to use my same license with the new server or should i need to
> buy
> a new license for the 64 bit server?
<Excerpt href="http://links.10026.com/?link=">http://www.microsoft.com/sql/howtobuy/default.mspx">
While you should choose the platform that matches your current hardware (in
order to obtain the appropriate media), SQL Server licenses are not platform
specific. For example, if you currently have a 32-bit server and plan to
upgrade the hardware to 64 bit in the future, you can purchase a 32-bit SKU
today, and later switch to 64 bit without having to
purchase an additional license.
</Excerpt>
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Frivas" <Frivas@.discussions.microsoft.com> wrote in message
news:E1927DBA-0E12-47D1-AC7C-2A132DFFC626@.microsoft.com...
> Hi, I want to upgrade a server from a 32 bit system to a 64 bit system,
> will
> i be able to use my same license with the new server or should i need to
> buy
> a new license for the 64 bit server?
> Thanks in advance for the help.
> Regards,
>
Migration from 2000 ro 2005 Cluster
Hey All,
We have SQL Server 2000 in our production environment and we have a
brand spanking new cluster that has more CPU power and RAM than our
current server. The issue I have is how to move the data. We have 10
Databases, most are small, but we have a few that are 5 to 9 GB and
one that is over 100 GB.
I've already loaded SQL Server 2005 SP2 on the cluster for testing
etc.
My goal is to reduce downtime, and my stress, when we go live with the
cluster. My fall back plan is, backup the databases, copy the backups
to the cluster and restore them on the cluster.
I had a thought of installing SQL Server 2000 on the clusters and log
ship the databases to the SQL 2000 instance on the cluster, since I
can't log ship from 2000 to 2005. Then when go live day comes, I just
need to restore the existing logs, recover the databases and detach
the databases from 2000, then attach the databases to the 2005. From
what I know this is doable, but has anyone done this or something
similar? Are there any gotchas?
Thanks
Dave Ott<DaveOtt26.2@.gmail.com> wrote in message
news:1172770995.057390.293120@.j27g2000cwj.googlegroups.com...
> Hey All,
> We have SQL Server 2000 in our production environment and we have a
> brand spanking new cluster that has more CPU power and RAM than our
> current server. The issue I have is how to move the data. We have 10
> Databases, most are small, but we have a few that are 5 to 9 GB and
> one that is over 100 GB.
> I've already loaded SQL Server 2005 SP2 on the cluster for testing
> etc.
> My goal is to reduce downtime, and my stress, when we go live with the
> cluster. My fall back plan is, backup the databases, copy the backups
> to the cluster and restore them on the cluster.
> I had a thought of installing SQL Server 2000 on the clusters and log
> ship the databases to the SQL 2000 instance on the cluster, since I
> can't log ship from 2000 to 2005.
You can't? Why not? (I'm 99% sure a you can restore a 2000 database with
NORECOVERY in 2005. You can't however go the other way).
I'd probably go this route, but do it manually.
I.e. backup the databases, restore to the 2005 cluster with NORECOVERY.
Take a logbackup, restore to 2005 with NORECOVERY (to take care of the lag
in the original backup/restore cycle).
Repeat until you know the next round of log backup/restores will be quick
and then schedule the downtime, do one last log backup/restore and then
switch over to the 2005 server.
(I'd actually practice this once with a test client and then redo the entire
process if possible.)
Script it all out so it's fast and few mistakes.
> Then when go live day comes, I just
> need to restore the existing logs, recover the databases and detach
> the databases from 2000, then attach the databases to the 2005. From
> what I know this is doable, but has anyone done this or something
> similar? Are there any gotchas?
Seems to me more complicated than it's worth.
> Thanks
> Dave Ott
>|||If you do it all by scripts, you can log ship from SQL 2000 to SQL 2005.
You cannot use the STANDBY option but NORECOVERY works just fine. There is
no need for a SQL 2000 instance cluttering things up.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.com> wrote in message
news:Ozz1v$CXHHA.528@.TK2MSFTNGP03.phx.gbl...
> <DaveOtt26.2@.gmail.com> wrote in message
> news:1172770995.057390.293120@.j27g2000cwj.googlegroups.com...
> You can't? Why not? (I'm 99% sure a you can restore a 2000 database with
> NORECOVERY in 2005. You can't however go the other way).
> I'd probably go this route, but do it manually.
> I.e. backup the databases, restore to the 2005 cluster with NORECOVERY.
> Take a logbackup, restore to 2005 with NORECOVERY (to take care of the lag
> in the original backup/restore cycle).
> Repeat until you know the next round of log backup/restores will be quick
> and then schedule the downtime, do one last log backup/restore and then
> switch over to the 2005 server.
> (I'd actually practice this once with a test client and then redo the
> entire process if possible.)
> Script it all out so it's fast and few mistakes.
>
> Seems to me more complicated than it's worth.
>
>|||Geoff,
Once again you are there with the answer!
Thanks
Dave
We have SQL Server 2000 in our production environment and we have a
brand spanking new cluster that has more CPU power and RAM than our
current server. The issue I have is how to move the data. We have 10
Databases, most are small, but we have a few that are 5 to 9 GB and
one that is over 100 GB.
I've already loaded SQL Server 2005 SP2 on the cluster for testing
etc.
My goal is to reduce downtime, and my stress, when we go live with the
cluster. My fall back plan is, backup the databases, copy the backups
to the cluster and restore them on the cluster.
I had a thought of installing SQL Server 2000 on the clusters and log
ship the databases to the SQL 2000 instance on the cluster, since I
can't log ship from 2000 to 2005. Then when go live day comes, I just
need to restore the existing logs, recover the databases and detach
the databases from 2000, then attach the databases to the 2005. From
what I know this is doable, but has anyone done this or something
similar? Are there any gotchas?
Thanks
Dave Ott<DaveOtt26.2@.gmail.com> wrote in message
news:1172770995.057390.293120@.j27g2000cwj.googlegroups.com...
> Hey All,
> We have SQL Server 2000 in our production environment and we have a
> brand spanking new cluster that has more CPU power and RAM than our
> current server. The issue I have is how to move the data. We have 10
> Databases, most are small, but we have a few that are 5 to 9 GB and
> one that is over 100 GB.
> I've already loaded SQL Server 2005 SP2 on the cluster for testing
> etc.
> My goal is to reduce downtime, and my stress, when we go live with the
> cluster. My fall back plan is, backup the databases, copy the backups
> to the cluster and restore them on the cluster.
> I had a thought of installing SQL Server 2000 on the clusters and log
> ship the databases to the SQL 2000 instance on the cluster, since I
> can't log ship from 2000 to 2005.
You can't? Why not? (I'm 99% sure a you can restore a 2000 database with
NORECOVERY in 2005. You can't however go the other way).
I'd probably go this route, but do it manually.
I.e. backup the databases, restore to the 2005 cluster with NORECOVERY.
Take a logbackup, restore to 2005 with NORECOVERY (to take care of the lag
in the original backup/restore cycle).
Repeat until you know the next round of log backup/restores will be quick
and then schedule the downtime, do one last log backup/restore and then
switch over to the 2005 server.
(I'd actually practice this once with a test client and then redo the entire
process if possible.)
Script it all out so it's fast and few mistakes.
> Then when go live day comes, I just
> need to restore the existing logs, recover the databases and detach
> the databases from 2000, then attach the databases to the 2005. From
> what I know this is doable, but has anyone done this or something
> similar? Are there any gotchas?
Seems to me more complicated than it's worth.
> Thanks
> Dave Ott
>|||If you do it all by scripts, you can log ship from SQL 2000 to SQL 2005.
You cannot use the STANDBY option but NORECOVERY works just fine. There is
no need for a SQL 2000 instance cluttering things up.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.com> wrote in message
news:Ozz1v$CXHHA.528@.TK2MSFTNGP03.phx.gbl...
> <DaveOtt26.2@.gmail.com> wrote in message
> news:1172770995.057390.293120@.j27g2000cwj.googlegroups.com...
> You can't? Why not? (I'm 99% sure a you can restore a 2000 database with
> NORECOVERY in 2005. You can't however go the other way).
> I'd probably go this route, but do it manually.
> I.e. backup the databases, restore to the 2005 cluster with NORECOVERY.
> Take a logbackup, restore to 2005 with NORECOVERY (to take care of the lag
> in the original backup/restore cycle).
> Repeat until you know the next round of log backup/restores will be quick
> and then schedule the downtime, do one last log backup/restore and then
> switch over to the 2005 server.
> (I'd actually practice this once with a test client and then redo the
> entire process if possible.)
> Script it all out so it's fast and few mistakes.
>
> Seems to me more complicated than it's worth.
>
>|||Geoff,
Once again you are there with the answer!
Thanks
Dave
Migration from 2000 ro 2005 Cluster
<DaveOtt26.2@.gmail.com> wrote in message
news:1172770995.057390.293120@.j27g2000cwj.googlegr oups.com...
> Hey All,
> We have SQL Server 2000 in our production environment and we have a
> brand spanking new cluster that has more CPU power and RAM than our
> current server. The issue I have is how to move the data. We have 10
> Databases, most are small, but we have a few that are 5 to 9 GB and
> one that is over 100 GB.
> I've already loaded SQL Server 2005 SP2 on the cluster for testing
> etc.
> My goal is to reduce downtime, and my stress, when we go live with the
> cluster. My fall back plan is, backup the databases, copy the backups
> to the cluster and restore them on the cluster.
> I had a thought of installing SQL Server 2000 on the clusters and log
> ship the databases to the SQL 2000 instance on the cluster, since I
> can't log ship from 2000 to 2005.
You can't? Why not? (I'm 99% sure a you can restore a 2000 database with
NORECOVERY in 2005. You can't however go the other way).
I'd probably go this route, but do it manually.
I.e. backup the databases, restore to the 2005 cluster with NORECOVERY.
Take a logbackup, restore to 2005 with NORECOVERY (to take care of the lag
in the original backup/restore cycle).
Repeat until you know the next round of log backup/restores will be quick
and then schedule the downtime, do one last log backup/restore and then
switch over to the 2005 server.
(I'd actually practice this once with a test client and then redo the entire
process if possible.)
Script it all out so it's fast and few mistakes.
> Then when go live day comes, I just
> need to restore the existing logs, recover the databases and detach
> the databases from 2000, then attach the databases to the 2005. From
> what I know this is doable, but has anyone done this or something
> similar? Are there any gotchas?
Seems to me more complicated than it's worth.
> Thanks
> Dave Ott
>
If you do it all by scripts, you can log ship from SQL 2000 to SQL 2005.
You cannot use the STANDBY option but NORECOVERY works just fine. There is
no need for a SQL 2000 instance cluttering things up.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.com> wrote in message
news:Ozz1v$CXHHA.528@.TK2MSFTNGP03.phx.gbl...
> <DaveOtt26.2@.gmail.com> wrote in message
> news:1172770995.057390.293120@.j27g2000cwj.googlegr oups.com...
> You can't? Why not? (I'm 99% sure a you can restore a 2000 database with
> NORECOVERY in 2005. You can't however go the other way).
> I'd probably go this route, but do it manually.
> I.e. backup the databases, restore to the 2005 cluster with NORECOVERY.
> Take a logbackup, restore to 2005 with NORECOVERY (to take care of the lag
> in the original backup/restore cycle).
> Repeat until you know the next round of log backup/restores will be quick
> and then schedule the downtime, do one last log backup/restore and then
> switch over to the 2005 server.
> (I'd actually practice this once with a test client and then redo the
> entire process if possible.)
> Script it all out so it's fast and few mistakes.
>
> Seems to me more complicated than it's worth.
>
>
|||Geoff,
Once again you are there with the answer!
Thanks
Dave
news:1172770995.057390.293120@.j27g2000cwj.googlegr oups.com...
> Hey All,
> We have SQL Server 2000 in our production environment and we have a
> brand spanking new cluster that has more CPU power and RAM than our
> current server. The issue I have is how to move the data. We have 10
> Databases, most are small, but we have a few that are 5 to 9 GB and
> one that is over 100 GB.
> I've already loaded SQL Server 2005 SP2 on the cluster for testing
> etc.
> My goal is to reduce downtime, and my stress, when we go live with the
> cluster. My fall back plan is, backup the databases, copy the backups
> to the cluster and restore them on the cluster.
> I had a thought of installing SQL Server 2000 on the clusters and log
> ship the databases to the SQL 2000 instance on the cluster, since I
> can't log ship from 2000 to 2005.
You can't? Why not? (I'm 99% sure a you can restore a 2000 database with
NORECOVERY in 2005. You can't however go the other way).
I'd probably go this route, but do it manually.
I.e. backup the databases, restore to the 2005 cluster with NORECOVERY.
Take a logbackup, restore to 2005 with NORECOVERY (to take care of the lag
in the original backup/restore cycle).
Repeat until you know the next round of log backup/restores will be quick
and then schedule the downtime, do one last log backup/restore and then
switch over to the 2005 server.
(I'd actually practice this once with a test client and then redo the entire
process if possible.)
Script it all out so it's fast and few mistakes.
> Then when go live day comes, I just
> need to restore the existing logs, recover the databases and detach
> the databases from 2000, then attach the databases to the 2005. From
> what I know this is doable, but has anyone done this or something
> similar? Are there any gotchas?
Seems to me more complicated than it's worth.
> Thanks
> Dave Ott
>
If you do it all by scripts, you can log ship from SQL 2000 to SQL 2005.
You cannot use the STANDBY option but NORECOVERY works just fine. There is
no need for a SQL 2000 instance cluttering things up.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.com> wrote in message
news:Ozz1v$CXHHA.528@.TK2MSFTNGP03.phx.gbl...
> <DaveOtt26.2@.gmail.com> wrote in message
> news:1172770995.057390.293120@.j27g2000cwj.googlegr oups.com...
> You can't? Why not? (I'm 99% sure a you can restore a 2000 database with
> NORECOVERY in 2005. You can't however go the other way).
> I'd probably go this route, but do it manually.
> I.e. backup the databases, restore to the 2005 cluster with NORECOVERY.
> Take a logbackup, restore to 2005 with NORECOVERY (to take care of the lag
> in the original backup/restore cycle).
> Repeat until you know the next round of log backup/restores will be quick
> and then schedule the downtime, do one last log backup/restore and then
> switch over to the 2005 server.
> (I'd actually practice this once with a test client and then redo the
> entire process if possible.)
> Script it all out so it's fast and few mistakes.
>
> Seems to me more complicated than it's worth.
>
>
|||Geoff,
Once again you are there with the answer!
Thanks
Dave
Migration from 2000 ro 2005 Cluster
Hey All,
We have SQL Server 2000 in our production environment and we have a
brand spanking new cluster that has more CPU power and RAM than our
current server. The issue I have is how to move the data. We have 10
Databases, most are small, but we have a few that are 5 to 9 GB and
one that is over 100 GB.
I've already loaded SQL Server 2005 SP2 on the cluster for testing
etc.
My goal is to reduce downtime, and my stress, when we go live with the
cluster. My fall back plan is, backup the databases, copy the backups
to the cluster and restore them on the cluster.
I had a thought of installing SQL Server 2000 on the clusters and log
ship the databases to the SQL 2000 instance on the cluster, since I
can't log ship from 2000 to 2005. Then when go live day comes, I just
need to restore the existing logs, recover the databases and detach
the databases from 2000, then attach the databases to the 2005. From
what I know this is doable, but has anyone done this or something
similar? Are there any gotchas?
Thanks
Dave Ott<DaveOtt26.2@.gmail.com> wrote in message
news:1172770995.057390.293120@.j27g2000cwj.googlegroups.com...
> Hey All,
> We have SQL Server 2000 in our production environment and we have a
> brand spanking new cluster that has more CPU power and RAM than our
> current server. The issue I have is how to move the data. We have 10
> Databases, most are small, but we have a few that are 5 to 9 GB and
> one that is over 100 GB.
> I've already loaded SQL Server 2005 SP2 on the cluster for testing
> etc.
> My goal is to reduce downtime, and my stress, when we go live with the
> cluster. My fall back plan is, backup the databases, copy the backups
> to the cluster and restore them on the cluster.
> I had a thought of installing SQL Server 2000 on the clusters and log
> ship the databases to the SQL 2000 instance on the cluster, since I
> can't log ship from 2000 to 2005.
You can't? Why not? (I'm 99% sure a you can restore a 2000 database with
NORECOVERY in 2005. You can't however go the other way).
I'd probably go this route, but do it manually.
I.e. backup the databases, restore to the 2005 cluster with NORECOVERY.
Take a logbackup, restore to 2005 with NORECOVERY (to take care of the lag
in the original backup/restore cycle).
Repeat until you know the next round of log backup/restores will be quick
and then schedule the downtime, do one last log backup/restore and then
switch over to the 2005 server.
(I'd actually practice this once with a test client and then redo the entire
process if possible.)
Script it all out so it's fast and few mistakes.
> Then when go live day comes, I just
> need to restore the existing logs, recover the databases and detach
> the databases from 2000, then attach the databases to the 2005. From
> what I know this is doable, but has anyone done this or something
> similar? Are there any gotchas?
Seems to me more complicated than it's worth.
> Thanks
> Dave Ott
>|||If you do it all by scripts, you can log ship from SQL 2000 to SQL 2005.
You cannot use the STANDBY option but NORECOVERY works just fine. There is
no need for a SQL 2000 instance cluttering things up.
--
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.com> wrote in message
news:Ozz1v$CXHHA.528@.TK2MSFTNGP03.phx.gbl...
> <DaveOtt26.2@.gmail.com> wrote in message
> news:1172770995.057390.293120@.j27g2000cwj.googlegroups.com...
>> Hey All,
>> We have SQL Server 2000 in our production environment and we have a
>> brand spanking new cluster that has more CPU power and RAM than our
>> current server. The issue I have is how to move the data. We have 10
>> Databases, most are small, but we have a few that are 5 to 9 GB and
>> one that is over 100 GB.
>> I've already loaded SQL Server 2005 SP2 on the cluster for testing
>> etc.
>> My goal is to reduce downtime, and my stress, when we go live with the
>> cluster. My fall back plan is, backup the databases, copy the backups
>> to the cluster and restore them on the cluster.
>> I had a thought of installing SQL Server 2000 on the clusters and log
>> ship the databases to the SQL 2000 instance on the cluster, since I
>> can't log ship from 2000 to 2005.
> You can't? Why not? (I'm 99% sure a you can restore a 2000 database with
> NORECOVERY in 2005. You can't however go the other way).
> I'd probably go this route, but do it manually.
> I.e. backup the databases, restore to the 2005 cluster with NORECOVERY.
> Take a logbackup, restore to 2005 with NORECOVERY (to take care of the lag
> in the original backup/restore cycle).
> Repeat until you know the next round of log backup/restores will be quick
> and then schedule the downtime, do one last log backup/restore and then
> switch over to the 2005 server.
> (I'd actually practice this once with a test client and then redo the
> entire process if possible.)
> Script it all out so it's fast and few mistakes.
>
>> Then when go live day comes, I just
>> need to restore the existing logs, recover the databases and detach
>> the databases from 2000, then attach the databases to the 2005. From
>> what I know this is doable, but has anyone done this or something
>> similar? Are there any gotchas?
> Seems to me more complicated than it's worth.
>
>> Thanks
>> Dave Ott
>|||Geoff,
Once again you are there with the answer!
Thanks
Dave
We have SQL Server 2000 in our production environment and we have a
brand spanking new cluster that has more CPU power and RAM than our
current server. The issue I have is how to move the data. We have 10
Databases, most are small, but we have a few that are 5 to 9 GB and
one that is over 100 GB.
I've already loaded SQL Server 2005 SP2 on the cluster for testing
etc.
My goal is to reduce downtime, and my stress, when we go live with the
cluster. My fall back plan is, backup the databases, copy the backups
to the cluster and restore them on the cluster.
I had a thought of installing SQL Server 2000 on the clusters and log
ship the databases to the SQL 2000 instance on the cluster, since I
can't log ship from 2000 to 2005. Then when go live day comes, I just
need to restore the existing logs, recover the databases and detach
the databases from 2000, then attach the databases to the 2005. From
what I know this is doable, but has anyone done this or something
similar? Are there any gotchas?
Thanks
Dave Ott<DaveOtt26.2@.gmail.com> wrote in message
news:1172770995.057390.293120@.j27g2000cwj.googlegroups.com...
> Hey All,
> We have SQL Server 2000 in our production environment and we have a
> brand spanking new cluster that has more CPU power and RAM than our
> current server. The issue I have is how to move the data. We have 10
> Databases, most are small, but we have a few that are 5 to 9 GB and
> one that is over 100 GB.
> I've already loaded SQL Server 2005 SP2 on the cluster for testing
> etc.
> My goal is to reduce downtime, and my stress, when we go live with the
> cluster. My fall back plan is, backup the databases, copy the backups
> to the cluster and restore them on the cluster.
> I had a thought of installing SQL Server 2000 on the clusters and log
> ship the databases to the SQL 2000 instance on the cluster, since I
> can't log ship from 2000 to 2005.
You can't? Why not? (I'm 99% sure a you can restore a 2000 database with
NORECOVERY in 2005. You can't however go the other way).
I'd probably go this route, but do it manually.
I.e. backup the databases, restore to the 2005 cluster with NORECOVERY.
Take a logbackup, restore to 2005 with NORECOVERY (to take care of the lag
in the original backup/restore cycle).
Repeat until you know the next round of log backup/restores will be quick
and then schedule the downtime, do one last log backup/restore and then
switch over to the 2005 server.
(I'd actually practice this once with a test client and then redo the entire
process if possible.)
Script it all out so it's fast and few mistakes.
> Then when go live day comes, I just
> need to restore the existing logs, recover the databases and detach
> the databases from 2000, then attach the databases to the 2005. From
> what I know this is doable, but has anyone done this or something
> similar? Are there any gotchas?
Seems to me more complicated than it's worth.
> Thanks
> Dave Ott
>|||If you do it all by scripts, you can log ship from SQL 2000 to SQL 2005.
You cannot use the STANDBY option but NORECOVERY works just fine. There is
no need for a SQL 2000 instance cluttering things up.
--
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.com> wrote in message
news:Ozz1v$CXHHA.528@.TK2MSFTNGP03.phx.gbl...
> <DaveOtt26.2@.gmail.com> wrote in message
> news:1172770995.057390.293120@.j27g2000cwj.googlegroups.com...
>> Hey All,
>> We have SQL Server 2000 in our production environment and we have a
>> brand spanking new cluster that has more CPU power and RAM than our
>> current server. The issue I have is how to move the data. We have 10
>> Databases, most are small, but we have a few that are 5 to 9 GB and
>> one that is over 100 GB.
>> I've already loaded SQL Server 2005 SP2 on the cluster for testing
>> etc.
>> My goal is to reduce downtime, and my stress, when we go live with the
>> cluster. My fall back plan is, backup the databases, copy the backups
>> to the cluster and restore them on the cluster.
>> I had a thought of installing SQL Server 2000 on the clusters and log
>> ship the databases to the SQL 2000 instance on the cluster, since I
>> can't log ship from 2000 to 2005.
> You can't? Why not? (I'm 99% sure a you can restore a 2000 database with
> NORECOVERY in 2005. You can't however go the other way).
> I'd probably go this route, but do it manually.
> I.e. backup the databases, restore to the 2005 cluster with NORECOVERY.
> Take a logbackup, restore to 2005 with NORECOVERY (to take care of the lag
> in the original backup/restore cycle).
> Repeat until you know the next round of log backup/restores will be quick
> and then schedule the downtime, do one last log backup/restore and then
> switch over to the 2005 server.
> (I'd actually practice this once with a test client and then redo the
> entire process if possible.)
> Script it all out so it's fast and few mistakes.
>
>> Then when go live day comes, I just
>> need to restore the existing logs, recover the databases and detach
>> the databases from 2000, then attach the databases to the 2005. From
>> what I know this is doable, but has anyone done this or something
>> similar? Are there any gotchas?
> Seems to me more complicated than it's worth.
>
>> Thanks
>> Dave Ott
>|||Geoff,
Once again you are there with the answer!
Thanks
Dave
Migration form MS access reports to Sql server reports
Does any of the free dowloadable reporting packs come with Reporting Services wizard to migrate data and reports from MS-Access?
Is this possible with Reporting tool?|||It may be, but with what is built into Reporting Services you have to have Access 2003. This doesn't mean you couldn't open the Access 97 database with a 2003 version of Access.
Does SQL Server reporting tools come integrated with any of the VS 2005 tools?
Yes, if you are dealing with the 2000 version than have your service packs up to date and you have to have Access 2003 for the option to show up in your designer. Once you have Access 2003 it will give you the option under "project" --> "import reports".
I believe in 2005 it is under the same location: "project" --> "import reports"
I hope this helps.
|||I need to convert from MS Access 97 to .NET 2005.Is this possible with Reporting tool?|||It may be, but with what is built into Reporting Services you have to have Access 2003. This doesn't mean you couldn't open the Access 97 database with a 2003 version of Access.
Migration exceptions
Hi,
How should one deal with exceptions generated by the DTS to SSIS conversion wizard in sql server 2005?
ThanksWhat exceptions are you getting? That would be a good place to start.
How should one deal with exceptions generated by the DTS to SSIS conversion wizard in sql server 2005?
ThanksWhat exceptions are you getting? That would be a good place to start.
Migration data from SQL 7.0 to SQL 2005
I know that sQL 2005 support upgrading a SQL 7.0 database if you install it
on to of the existing 7.0 instance and perfrom a full system upgrade. What I
don'y know is, if I set up a sepparate SQL 2005 server, is there a way to
import the SQL 7.0 database and convert it for use inder 2005? I don't want
to burn my tracks by upgrdaing the existing server. If the install goes bad,
I can't fall back if nercessary. The books online for the lates preview don't
indicate the abaility migrate data fromj 7.0 as a stand alone process
sepparate from a full upgrade.
You should be able to detach the database from SQL Server 7.0 and attach it
to SQL Server 2005 using sp_detach_db and sp_attach_db system stored
procedures. For more information about upgrading databases from previous
versions to SQL Server 2005, see SQL Server 2005 Books Online.
Vyas, MVP (SQL Server)
SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
"AJStein" <AJStein@.discussions.microsoft.com> wrote in message
news:520F2B5E-6ECA-4EC3-90CD-643348C44A80@.microsoft.com...
> I know that sQL 2005 support upgrading a SQL 7.0 database if you install
it
> on to of the existing 7.0 instance and perfrom a full system upgrade. What
I
> don'y know is, if I set up a sepparate SQL 2005 server, is there a way to
> import the SQL 7.0 database and convert it for use inder 2005? I don't
want
> to burn my tracks by upgrdaing the existing server. If the install goes
bad,
> I can't fall back if nercessary. The books online for the lates preview
don't
> indicate the abaility migrate data fromj 7.0 as a stand alone process
> sepparate from a full upgrade.
|||I have read the books online and I don't get the impression that you can
either directly attach a 7.0 database or alternatively, use the "copy
database wizard". Attempts to directly attach a SQL 7.0 database have failed
when initiated by scripts generated using the new scripting wizard. The “copy
database wizard” clearly states in its opening text that it can only be used
when copying SQL 2000 or 2005 data. There is no mention of copying SQL 7.0
data at all.
The books online recommend not using “sp_attach_db” command since it will no
longer be supported in the future. They suggest using the “CREAT DATABASE”
command in its place which is what the script generated by the wizard used.
In eaither case, the action failed.
"Narayana Vyas Kondreddi" wrote:
> You should be able to detach the database from SQL Server 7.0 and attach it
> to SQL Server 2005 using sp_detach_db and sp_attach_db system stored
> procedures. For more information about upgrading databases from previous
> versions to SQL Server 2005, see SQL Server 2005 Books Online.
> --
> Vyas, MVP (SQL Server)
> SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
>
> "AJStein" <AJStein@.discussions.microsoft.com> wrote in message
> news:520F2B5E-6ECA-4EC3-90CD-643348C44A80@.microsoft.com...
> it
> I
> want
> bad,
> don't
>
>
|||OK, I got it to work. For some reason, scheduling the script to run via the
agent causes it to fail when executed. However, when I copied the script to
the query analyzer and executed it from there, it worked correctly.
"Narayana Vyas Kondreddi" wrote:
> You should be able to detach the database from SQL Server 7.0 and attach it
> to SQL Server 2005 using sp_detach_db and sp_attach_db system stored
> procedures. For more information about upgrading databases from previous
> versions to SQL Server 2005, see SQL Server 2005 Books Online.
> --
> Vyas, MVP (SQL Server)
> SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
>
> "AJStein" <AJStein@.discussions.microsoft.com> wrote in message
> news:520F2B5E-6ECA-4EC3-90CD-643348C44A80@.microsoft.com...
> it
> I
> want
> bad,
> don't
>
>
|||For additional help with upgrading to SQL Server 2005 from earlier versions
of SQL Server, you may be interested in the SQL Server 2005 Upgrade Advisor:
http://www.microsoft.com/downloads/d...DisplayLang=en
"AJStein" <AJStein@.discussions.microsoft.com> wrote in message
news:520F2B5E-6ECA-4EC3-90CD-643348C44A80@.microsoft.com...
>I know that sQL 2005 support upgrading a SQL 7.0 database if you install it
> on to of the existing 7.0 instance and perfrom a full system upgrade. What
> I
> don'y know is, if I set up a sepparate SQL 2005 server, is there a way to
> import the SQL 7.0 database and convert it for use inder 2005? I don't
> want
> to burn my tracks by upgrdaing the existing server. If the install goes
> bad,
> I can't fall back if nercessary. The books online for the lates preview
> don't
> indicate the abaility migrate data fromj 7.0 as a stand alone process
> sepparate from a full upgrade.
on to of the existing 7.0 instance and perfrom a full system upgrade. What I
don'y know is, if I set up a sepparate SQL 2005 server, is there a way to
import the SQL 7.0 database and convert it for use inder 2005? I don't want
to burn my tracks by upgrdaing the existing server. If the install goes bad,
I can't fall back if nercessary. The books online for the lates preview don't
indicate the abaility migrate data fromj 7.0 as a stand alone process
sepparate from a full upgrade.
You should be able to detach the database from SQL Server 7.0 and attach it
to SQL Server 2005 using sp_detach_db and sp_attach_db system stored
procedures. For more information about upgrading databases from previous
versions to SQL Server 2005, see SQL Server 2005 Books Online.
Vyas, MVP (SQL Server)
SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
"AJStein" <AJStein@.discussions.microsoft.com> wrote in message
news:520F2B5E-6ECA-4EC3-90CD-643348C44A80@.microsoft.com...
> I know that sQL 2005 support upgrading a SQL 7.0 database if you install
it
> on to of the existing 7.0 instance and perfrom a full system upgrade. What
I
> don'y know is, if I set up a sepparate SQL 2005 server, is there a way to
> import the SQL 7.0 database and convert it for use inder 2005? I don't
want
> to burn my tracks by upgrdaing the existing server. If the install goes
bad,
> I can't fall back if nercessary. The books online for the lates preview
don't
> indicate the abaility migrate data fromj 7.0 as a stand alone process
> sepparate from a full upgrade.
|||I have read the books online and I don't get the impression that you can
either directly attach a 7.0 database or alternatively, use the "copy
database wizard". Attempts to directly attach a SQL 7.0 database have failed
when initiated by scripts generated using the new scripting wizard. The “copy
database wizard” clearly states in its opening text that it can only be used
when copying SQL 2000 or 2005 data. There is no mention of copying SQL 7.0
data at all.
The books online recommend not using “sp_attach_db” command since it will no
longer be supported in the future. They suggest using the “CREAT DATABASE”
command in its place which is what the script generated by the wizard used.
In eaither case, the action failed.
"Narayana Vyas Kondreddi" wrote:
> You should be able to detach the database from SQL Server 7.0 and attach it
> to SQL Server 2005 using sp_detach_db and sp_attach_db system stored
> procedures. For more information about upgrading databases from previous
> versions to SQL Server 2005, see SQL Server 2005 Books Online.
> --
> Vyas, MVP (SQL Server)
> SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
>
> "AJStein" <AJStein@.discussions.microsoft.com> wrote in message
> news:520F2B5E-6ECA-4EC3-90CD-643348C44A80@.microsoft.com...
> it
> I
> want
> bad,
> don't
>
>
|||OK, I got it to work. For some reason, scheduling the script to run via the
agent causes it to fail when executed. However, when I copied the script to
the query analyzer and executed it from there, it worked correctly.
"Narayana Vyas Kondreddi" wrote:
> You should be able to detach the database from SQL Server 7.0 and attach it
> to SQL Server 2005 using sp_detach_db and sp_attach_db system stored
> procedures. For more information about upgrading databases from previous
> versions to SQL Server 2005, see SQL Server 2005 Books Online.
> --
> Vyas, MVP (SQL Server)
> SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
>
> "AJStein" <AJStein@.discussions.microsoft.com> wrote in message
> news:520F2B5E-6ECA-4EC3-90CD-643348C44A80@.microsoft.com...
> it
> I
> want
> bad,
> don't
>
>
|||For additional help with upgrading to SQL Server 2005 from earlier versions
of SQL Server, you may be interested in the SQL Server 2005 Upgrade Advisor:
http://www.microsoft.com/downloads/d...DisplayLang=en
"AJStein" <AJStein@.discussions.microsoft.com> wrote in message
news:520F2B5E-6ECA-4EC3-90CD-643348C44A80@.microsoft.com...
>I know that sQL 2005 support upgrading a SQL 7.0 database if you install it
> on to of the existing 7.0 instance and perfrom a full system upgrade. What
> I
> don'y know is, if I set up a sepparate SQL 2005 server, is there a way to
> import the SQL 7.0 database and convert it for use inder 2005? I don't
> want
> to burn my tracks by upgrdaing the existing server. If the install goes
> bad,
> I can't fall back if nercessary. The books online for the lates preview
> don't
> indicate the abaility migrate data fromj 7.0 as a stand alone process
> sepparate from a full upgrade.
Subscribe to:
Posts (Atom)