Resorting Columns

Here's something I've never run into before, and I hope someone can help.
I have two identical SQL2000 databases (DB1 and DB2). Each has a different
name and is part of a different merge scheme. My developer has an
application that writes data from a table in DB1 to an identical table in
DB2, but it's failing. He says that it's because the columns in one table
aren't in the same order as the columns in the other table. E.g., one table
has column19 in the 19th position, and the other table has column19 in the
15th position.
Is there a way to move a column from one position to another without
removing the databases from replication?
I'd really appreciate some help in this.
Thanks,
John Steen
Developers should never ever rely on the column order. Tell your developer
to stop being lazy and specify the columns in the insert statement. If he
doesn't he will introduce some very subtle bugs over time that will be nearly
impossible to track down. I made the same mistake at my first job while I
was still in college and still regret it.
|||Thank, Scott, I'll definitely pass that along to our developer.
Unfortunately, I don't think it's going to fly this time. We're trying to
piece together a quick solution for a short-term problem that will be going
away by the end of the month. He's not going to want to rewrite all his apps
just for that. If there's a way for me to change the position of the column
in the table so the app will work, I'd rather do that.
Thanks,
John
"Scott S." wrote:

> Developers should never ever rely on the column order. Tell your developer
> to stop being lazy and specify the columns in the insert statement. If he
> doesn't he will introduce some very subtle bugs over time that will be nearly
> impossible to track down. I made the same mistake at my first job while I
> was still in college and still regret it.

Resorting a report by Column click

have a report that has about 7 columns
I would like to enable the user to be able to resort the report by simply
clicking on a column heading. For example if my Column names are
County Organization Name Program Name
I would the user to be able to click the County Column header and re-sort
the entire report in a descending alpha order and then also click
Organization name column header to re-sort by column name.
Anyone have any ideas of how this might be accomplished?Various approaches for RS 2000 have been discussed on this newsgroup. Search
the newsgroup for "dynamic sort column" or similar keywords.
You may also want to check a sample posted on GotDotNet:
http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=6a347b53-5594-40f9-861d-876beabeda16
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Report Guy" <Report Guy@.discussions.microsoft.com> wrote in message
news:F6EA8E3B-5810-4914-82D7-520C749E4B11@.microsoft.com...
> have a report that has about 7 columns
> I would like to enable the user to be able to resort the report by simply
> clicking on a column heading. For example if my Column names are
> County Organization Name Program Name
> I would the user to be able to click the County Column header and re-sort
> the entire report in a descending alpha order and then also click
> Organization name column header to re-sort by column name.
> Anyone have any ideas of how this might be accomplished?|||There are also several more examples on www.msbicentral.com
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
"Robert Bruckner [MSFT]" <robruc@.online.microsoft.com> wrote in message
news:up5254EHFHA.2740@.TK2MSFTNGP12.phx.gbl...
> Various approaches for RS 2000 have been discussed on this newsgroup.
> Search the newsgroup for "dynamic sort column" or similar keywords.
> You may also want to check a sample posted on GotDotNet:
> http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=6a347b53-5594-40f9-861d-876beabeda16
> --
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
> "Report Guy" <Report Guy@.discussions.microsoft.com> wrote in message
> news:F6EA8E3B-5810-4914-82D7-520C749E4B11@.microsoft.com...
>> have a report that has about 7 columns
>> I would like to enable the user to be able to resort the report by simply
>> clicking on a column heading. For example if my Column names are
>> County Organization Name Program Name
>> I would the user to be able to click the County Column header and re-sort
>> the entire report in a descending alpha order and then also click
>> Organization name column header to re-sort by column name.
>> Anyone have any ideas of how this might be accomplished?
>|||Ok I went to the link that you posted below. I downloaded the sample report
and am trying to figure it out. Where is the code other other event that
does the re-sort?
I copied the same report parameters into the project I'm working on and they
didn't work. Of course, i taylored the fields in the database to field names
I have in my DB, but I can't get the resort to work. There's no readme or
other documentation, so i'm hoping someone can help me out...
"Robert Bruckner [MSFT]" wrote:
> Various approaches for RS 2000 have been discussed on this newsgroup. Search
> the newsgroup for "dynamic sort column" or similar keywords.
> You may also want to check a sample posted on GotDotNet:
> http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=6a347b53-5594-40f9-861d-876beabeda16
> --
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
> "Report Guy" <Report Guy@.discussions.microsoft.com> wrote in message
> news:F6EA8E3B-5810-4914-82D7-520C749E4B11@.microsoft.com...
> > have a report that has about 7 columns
> >
> > I would like to enable the user to be able to resort the report by simply
> > clicking on a column heading. For example if my Column names are
> > County Organization Name Program Name
> >
> > I would the user to be able to click the County Column header and re-sort
> > the entire report in a descending alpha order and then also click
> > Organization name column header to re-sort by column name.
> >
> > Anyone have any ideas of how this might be accomplished?
>
>

Resolver Issues

I'm not able to resolve conflicts using the conflict viewer because I have
timestamp columns in my tables. Can I manually resolve these conflicts by
making the necessary changes to the data?
I'm using filters on my articles and I'm noticing that replication is
changing rows in the table that don't meet my filter clause. Well, all
the data didn't change in the row just the Last_Update_Date and
Last_Update_By columns changed. I have a trigger on my tables that
updates these columns. For some reason my trigger is getting fired.
These two columns get updated so replication thinks it needs to push these
changes along to the subscriber. I end up with conflicts if the
subscriber has also changed these rows.
The first thing to figure out is what is causing teh triggers to fire.
As far as manually doing this, you can. The conflict viewer is just another
application which sits over a set of data. You can easily do this yourself.
You can freely read/write to the conflict tables if you choose since the
only things which reads from them is the conflict viewer. If you choose,
you can write your own application to replace the conflict viewer in order
to fit it into your environment and tailor it to your needs.
Mike
Principal Mentor
Solid Quality Learning
"More than just Training"
SQL Server MVP
http://www.solidqualitylearning.com
http://www.mssqlserver.com
|||I figured out my trigger issue.
I appreciate your help.
"Michael Hotek" <mhotek@.nomail.com> wrote in message
news:O4wRnlLKEHA.620@.tk2msftngp13.phx.gbl...
> The first thing to figure out is what is causing teh triggers to fire.
> As far as manually doing this, you can. The conflict viewer is just
another
> application which sits over a set of data. You can easily do this
yourself.
> You can freely read/write to the conflict tables if you choose since the
> only things which reads from them is the conflict viewer. If you choose,
> you can write your own application to replace the conflict viewer in order
> to fit it into your environment and tailor it to your needs.
> --
> Mike
> Principal Mentor
> Solid Quality Learning
> "More than just Training"
> SQL Server MVP
> http://www.solidqualitylearning.com
> http://www.mssqlserver.com
>

Resize Report Column Width when Hidden

I have a report that has a certain number of columns that are hidden and when hidden they leave a lot of white space. Is there a way to detect when they are hidden and set the width property to 0 and then reverse the value when they are visible?I used a list box with embedded list boxes to control the column widths automatically. Now the problem is that If I give column headers in the list they do not shrink and I don't want the data repeated above each group either. Any ideas?sql

resetting identity columns

Is there a way besides truncate table to reset the identity column of a tabl
e?
Thanks,
JoeLook at DBCC CHECKIDENT in Books Online.
"jaylou" <jaylou@.discussions.microsoft.com> wrote in message
news:109E8A34-65B2-4E8D-8FA3-C99D00C25D20@.microsoft.com...
> Is there a way besides truncate table to reset the identity column of a
> table?
> Thanks,
> Joe
>|||Jaylou,
Yes. DBCC CHECKIDENT ...RESEED argument.
HTH
Jerry
"jaylou" <jaylou@.discussions.microsoft.com> wrote in message
news:109E8A34-65B2-4E8D-8FA3-C99D00C25D20@.microsoft.com...
> Is there a way besides truncate table to reset the identity column of a
> table?
> Thanks,
> Joe
>|||Thank you!
I knew there was something but I couldn't find it.|||Thank you!
I knew there was something but I couldn't find it.

Representing rows as columns

Hi
I have a table in SQL Server 2000 that has following data:

PunchTime PunchType
11:45:00 In
12:45:00 Out
1:45:00 In
3:15:00 Out

Is there a way in SQL to represent this in the following format:
In Out In Out
11:45:00 12:45:00 1:45:00 3:15:00

ThanksYou specification is unclear in several respects. What is the datatype of
the PunchTime column (DATETIME or CHAR maybe)? What is the primary key of
this table? Do we know whether the times are AM or PM? Why is 1:45 shown
after 12:45 in your required result?

The best answer will be to do it in your client application. What you want
is purely presentational and presentational functionality belongs
client-side.

--
David Portas
SQL Server MVP
--|||[posted and mailed, please reply in news]

Rajeev (navvyus@.yahoo.com) writes:
> I have a table in SQL Server 2000 that has following data:
> PunchTime PunchType
> 11:45:00 In
> 12:45:00 Out
> 1:45:00 In
> 3:15:00 Out
> Is there a way in SQL to represent this in the following format:
> In Out In Out
> 11:45:00 12:45:00 1:45:00 3:15:00

There is no built-in construct, but there are a couple of possibilities
to depending on your requirements.

For this particular case, you could to this, under the assumption that
you have at most four rows per day:

SELECT In = in1.PunchTime, Out = out1.PunchTime,
In = in2.PunchTime, Out = out2.PunchTime
FROM tbl in1
JOIN tbl out1 ON in1.PunchDate = out1.PunchDate
LEFT JOIN tbl in2 ON in1.Punchdate = in2.PunchDate
AND in1.PunchType = in2.PunchType
AND in1.PunchType < in2.PunchType
LEFT JOIN tbl out2 ON out1.Punchdate = out2.PunchDate
AND out1.PunchType = out2.PunchType
AND out1.PunchType < out2.PunchType
WHERE in1.PunchType = 'In'
AND out1.PunchType = 'Out'

Here I have assumed there is a date column in the table, since that
would make sense. I have also been lazy and assumed that there is
always one In and one Out each day.

In a more general columns where you want dynamic column names etc,
you have to build dynamic SQL. But before you do that, check out
the third-party tool RAC, http://www.rac4sql.net/ which aspires to
be the ultimate tool for crosstab queries.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp

representing months with columns

I keep running into people that represent each month, January through
December, as a column in a table. Considering the nature of some of the
reports generated from this data, storing it in this way can certainly be
convenient; however I personally find the idea repugnant. I've been doing
this a while and think I have a pretty good intuitive grasp on what is good
database design and what isn't... but in this case the other designer could
come back and argue that since the number of months never changes,
representing each of them with a column is perfectly valid. Then I could
argue that that greatly complicates retrieving aggregate data, but then he
could say that my approach greatly complicates presenting the data with a
column per month...
In the beginning of my career as a database designer I never had issues like
this, I didn't need to work with anyone. Now it seems at every turn I end up
arguning with someone about what is good design and what isn't. Usually it's
regrettably obvious that the other person doesn't know what he's doing
("MUST you use nested cursors when all you need is a JOIN!?"), but in this
case I'm not so sure. Before I start another argument, I would like to hear
other people's thoughts in the matter.
Comments?
PaulYour colleague seems to favour denormalization without justification. By
normalizing your data, you make querying straightforward. Same goes for
maintenance. It's easy to craft a pivot query to present the results he
wants. It's messier to take his denormalized table and then run various
queries against it.
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Toronto, ON Canada
.
"PJ6" <nobody@.nowhere.net> wrote in message
news:u21R9lWYGHA.4144@.TK2MSFTNGP04.phx.gbl...
I keep running into people that represent each month, January through
December, as a column in a table. Considering the nature of some of the
reports generated from this data, storing it in this way can certainly be
convenient; however I personally find the idea repugnant. I've been doing
this a while and think I have a pretty good intuitive grasp on what is good
database design and what isn't... but in this case the other designer could
come back and argue that since the number of months never changes,
representing each of them with a column is perfectly valid. Then I could
argue that that greatly complicates retrieving aggregate data, but then he
could say that my approach greatly complicates presenting the data with a
column per month...
In the beginning of my career as a database designer I never had issues like
this, I didn't need to work with anyone. Now it seems at every turn I end up
arguning with someone about what is good design and what isn't. Usually it's
regrettably obvious that the other person doesn't know what he's doing
("MUST you use nested cursors when all you need is a JOIN!?"), but in this
case I'm not so sure. Before I start another argument, I would like to hear
other people's thoughts in the matter.
Comments?
Paul|||I'll sometimes do this but will treat it as redundant data.
The source will be the normalised structure and the denormalised created
from it - maybe recreated from scratch sometines maintained depending on the
requirement.
The reason would be performance - if there is a lot of data then this
structure can help a lot.
Unfortunately the tools available for database manipulation (especially sql
server) are so user friendly now that people are able to do quite a lot
without any real understanding of what they are doing so you end up having t
o
work with collegues who've got quite a long way without much basic knowledge
.
And in a company being right isn't always appreiated.
I've had that recently with a company that's full of application and excel
programmers. They refuse to listen to anything about relational theory and
even the sql server "experts" try to make the database into a glorified exce
l
spreadsheet.
I was moved to another seat because the guy who wants to ru things got upset
that I kept correcting him when he was diseminating knowledge about sql
server.|||I once had a system where monthly accounting summaries were held this way.
Made reports easy, but updates were obviously horrendous.
The real fun came when the company wanted to change from calendar month
periods to fixed 4-wly, so you have 13 (ish) in a year, Loads of code to
be redone!
Separate rows with appropriate start and end date columns is far more
flexible and probably the better way to go.
Mike John
"PJ6" <nobody@.nowhere.net> wrote in message
news:u21R9lWYGHA.4144@.TK2MSFTNGP04.phx.gbl...
>I keep running into people that represent each month, January through
>December, as a column in a table. Considering the nature of some of the
>reports generated from this data, storing it in this way can certainly be
>convenient; however I personally find the idea repugnant. I've been doing
>this a while and think I have a pretty good intuitive grasp on what is good
>database design and what isn't... but in this case the other designer could
>come back and argue that since the number of months never changes,
>representing each of them with a column is perfectly valid. Then I could
>argue that that greatly complicates retrieving aggregate data, but then he
>could say that my approach greatly complicates presenting the data with a
>column per month...
> In the beginning of my career as a database designer I never had issues
> like this, I didn't need to work with anyone. Now it seems at every turn I
> end up arguning with someone about what is good design and what isn't.
> Usually it's regrettably obvious that the other person doesn't know what
> he's doing ("MUST you use nested cursors when all you need is a JOIN!?"),
> but in this case I'm not so sure. Before I start another argument, I would
> like to hear other people's thoughts in the matter.
> Comments?
> Paul
>|||RE:
<< They refuse to listen to anything about relational theory and even the
sql server "experts" try to make the database into a glorified excel
spreadsheet.>>
And to make matters worse, Microsoft is intentionally blurring the lines
between a spreadsheet and a database
Check out the second paragraph in this PC Magazine review of MS Access 12:
http://www.pcmag.com/article2/0,1895,1888065,00.asp
It's a shame because it explicitly promotes the "spreadsheet mentality" of
database design.
"Nigel Rivett" <NigelRivett@.discussions.microsoft.com> wrote in message
news:E3AF2A1A-F935-4CC8-8659-70E0A6801053@.microsoft.com...
> I'll sometimes do this but will treat it as redundant data.
> The source will be the normalised structure and the denormalised created
> from it - maybe recreated from scratch sometines maintained depending on
> the
> requirement.
> The reason would be performance - if there is a lot of data then this
> structure can help a lot.
> Unfortunately the tools available for database manipulation (especially
> sql
> server) are so user friendly now that people are able to do quite a lot
> without any real understanding of what they are doing so you end up having
> to
> work with collegues who've got quite a long way without much basic
> knowledge.
> And in a company being right isn't always appreiated.
> I've had that recently with a company that's full of application and excel
> programmers. They refuse to listen to anything about relational theory and
> even the sql server "experts" try to make the database into a glorified
> excel
> spreadsheet.
> I was moved to another seat because the guy who wants to ru things got
> upset
> that I kept correcting him when he was diseminating knowledge about sql
> server.|||PJ6 (nobody@.nowhere.net) writes:
> I keep running into people that represent each month, January through
> December, as a column in a table. Considering the nature of some of the
> reports generated from this data, storing it in this way can certainly
> be convenient; however I personally find the idea repugnant. I've been
> doing this a while and think I have a pretty good intuitive grasp on
> what is good database design and what isn't... but in this case the
> other designer could come back and argue that since the number of months
> never changes,
And then the company decides to change its fiscal year to run from
April to March. Or Mike John's example where they moved to four-w
periods.

> representing each of them with a column is perfectly valid. Then I could
> argue that that greatly complicates retrieving aggregate data, but then he
> could say that my approach greatly complicates presenting the data with a
> column per month...
Yes, the last comment has some relevance, but
CREATE VIEW ... AS
SELECT product,
Jan = SUM(CASE month WHEN 1 THEN sales ELSE 0 END),
Feb = SUM(CASE month WHEN 2 THEN sales ELSE 0 END),
..
FROM monthsales
GROUP BY product
takes care of that.

> In the beginning of my career as a database designer I never had issues
> like this, I didn't need to work with anyone. Now it seems at every turn
> I end up arguning with someone about what is good design and what isn't.
It cannot be denied that database design in real life is about trade-offs,
and there are often more than one valid design.
There are plenty of rules, and while I mostly obey them, I've broken
them all. Including "no repeating groups". What you need is a good
feeling for when it's right to break the rule.
And it matters a lot what the purpose of the database is. They say that
OLAP databases don't look like OLTP databases. (I haven't worked with
OLAP, so I don't know.)
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||This denormalized design is fine in a Data Warehouse or OLAP schema,
where the data is static, the range of the data is static and the data
validated before it goes into the tables.
It is a nightmare for OLTP. I would construct a Calendar table with
ranges for fiscal periods, holidays, promotional periods, etc. set it
up for 10-20 years and join to it to get your "annual window" for
reports.
As an aside, years ago there was an article in DB2 magazine comparing
performance and storage usage between the two designs. I vaguely
remember that the normalized design performed better but took up more
space after April in the sample data. Disk is cheap; time and
integrity are not.

Repoting Services

I have a question.

Can I hide columns or fields , when there are too many fields in the data set . I want to take all fields but hide some in preview tab.Please somebody help me on this.

Thanks

Sudha

You can set the Hidden property to true. you can do this at the column level, and it will not show up.

BobP

REPOST - Moving from 7.0 to 2000

Dear All,
I have a database 4.2 gb of data, 50 view, 618 sp, 31
functions 92 tables, 10 with image columns and 27 jobs in
SQL Server 7.0.
As the title sugests I am migrating to 2000 and would like
some tips / help ect. I have read the Microsoft Guide, but
was wondering there any tips, help and more
importantly 'Do not do even if MS tells you too' would be
greatly appriciated.
A
Hi
Test, Test and Test your applications. Yes, there is SQL 7.0 compatability
mode, but there are small differences between how 7 and 2000 would do
something, even in that mode.
The basic migration is easy. Make sure that the objects are owned correctly,
make sure that there are no objects referring to objects that have been
removed/renamed.
I move 7.0's to 2000's on daily basis and it just works. Best is if you
move onto new hardware at the same time as you don't keep any legacy
configuration mistakes.
Regards
Mike
"Alice" wrote:

> Dear All,
> I have a database 4.2 gb of data, 50 view, 618 sp, 31
> functions 92 tables, 10 with image columns and 27 jobs in
> SQL Server 7.0.
> As the title sugests I am migrating to 2000 and would like
> some tips / help ect. I have read the Microsoft Guide, but
> was wondering there any tips, help and more
> importantly 'Do not do even if MS tells you too' would be
> greatly appriciated.
> A
>
|||Thanks for your reply, it has been very helpful.
Unfortunatly we are installing it on an existing Server so
I was wondering what are the common legacy configuration
problems ?
Thanks

>--Original Message--
>Hi
>Test, Test and Test your applications. Yes, there is SQL
7.0 compatability
>mode, but there are small differences between how 7 and
2000 would do
>something, even in that mode.
>The basic migration is easy. Make sure that the objects
are owned correctly,
>make sure that there are no objects referring to objects
that have been
>removed/renamed.
>I move 7.0's to 2000's on daily basis and it just works.
Best is if you
>move onto new hardware at the same time as you don't keep
any legacy[vbcol=seagreen]
>configuration mistakes.
>Regards
>Mike
>"Alice" wrote:
in[vbcol=seagreen]
like[vbcol=seagreen]
but[vbcol=seagreen]
be
>.
>

REPOST - Moving from 7.0 to 2000

Dear All,
I have a database 4.2 gb of data, 50 view, 618 sp, 31
functions 92 tables, 10 with image columns and 27 jobs in
SQL Server 7.0.
As the title sugests I am migrating to 2000 and would like
some tips / help ect. I have read the Microsoft Guide, but
was wondering there any tips, help and more
importantly 'Do not do even if MS tells you too' would be
greatly appriciated.
AHi
Test, Test and Test your applications. Yes, there is SQL 7.0 compatability
mode, but there are small differences between how 7 and 2000 would do
something, even in that mode.
The basic migration is easy. Make sure that the objects are owned correctly,
make sure that there are no objects referring to objects that have been
removed/renamed.
I move 7.0's to 2000's on daily basis and it just works. Best is if you
move onto new hardware at the same time as you don't keep any legacy
configuration mistakes.
Regards
Mike
"Alice" wrote:
> Dear All,
> I have a database 4.2 gb of data, 50 view, 618 sp, 31
> functions 92 tables, 10 with image columns and 27 jobs in
> SQL Server 7.0.
> As the title sugests I am migrating to 2000 and would like
> some tips / help ect. I have read the Microsoft Guide, but
> was wondering there any tips, help and more
> importantly 'Do not do even if MS tells you too' would be
> greatly appriciated.
> A
>|||Thanks for your reply, it has been very helpful.
Unfortunatly we are installing it on an existing Server so
I was wondering what are the common legacy configuration
problems ?
Thanks
>--Original Message--
>Hi
>Test, Test and Test your applications. Yes, there is SQL
7.0 compatability
>mode, but there are small differences between how 7 and
2000 would do
>something, even in that mode.
>The basic migration is easy. Make sure that the objects
are owned correctly,
>make sure that there are no objects referring to objects
that have been
>removed/renamed.
>I move 7.0's to 2000's on daily basis and it just works.
Best is if you
>move onto new hardware at the same time as you don't keep
any legacy
>configuration mistakes.
>Regards
>Mike
>"Alice" wrote:
>> Dear All,
>> I have a database 4.2 gb of data, 50 view, 618 sp, 31
>> functions 92 tables, 10 with image columns and 27 jobs
in
>> SQL Server 7.0.
>> As the title sugests I am migrating to 2000 and would
like
>> some tips / help ect. I have read the Microsoft Guide,
but
>> was wondering there any tips, help and more
>> importantly 'Do not do even if MS tells you too' would
be
>> greatly appriciated.
>> A
>>
>.
>

REPOST - Moving from 7.0 to 2000

Dear All,
I have a database 4.2 gb of data, 50 view, 618 sp, 31
functions 92 tables, 10 with image columns and 27 jobs in
SQL Server 7.0.
As the title sugests I am migrating to 2000 and would like
some tips / help ect. I have read the Microsoft Guide, but
was wondering there any tips, help and more
importantly 'Do not do even if MS tells you too' would be
greatly appriciated.
AHi
Test, Test and Test your applications. Yes, there is SQL 7.0 compatability
mode, but there are small differences between how 7 and 2000 would do
something, even in that mode.
The basic migration is easy. Make sure that the objects are owned correctly,
make sure that there are no objects referring to objects that have been
removed/renamed.
I move 7.0's to 2000's on daily basis and it just works. Best is if you
move onto new hardware at the same time as you don't keep any legacy
configuration mistakes.
Regards
Mike
"Alice" wrote:

> Dear All,
> I have a database 4.2 gb of data, 50 view, 618 sp, 31
> functions 92 tables, 10 with image columns and 27 jobs in
> SQL Server 7.0.
> As the title sugests I am migrating to 2000 and would like
> some tips / help ect. I have read the Microsoft Guide, but
> was wondering there any tips, help and more
> importantly 'Do not do even if MS tells you too' would be
> greatly appriciated.
> A
>|||Thanks for your reply, it has been very helpful.
Unfortunatly we are installing it on an existing Server so
I was wondering what are the common legacy configuration
problems ?
Thanks

>--Original Message--
>Hi
>Test, Test and Test your applications. Yes, there is SQL
7.0 compatability
>mode, but there are small differences between how 7 and
2000 would do
>something, even in that mode.
>The basic migration is easy. Make sure that the objects
are owned correctly,
>make sure that there are no objects referring to objects
that have been
>removed/renamed.
>I move 7.0's to 2000's on daily basis and it just works.
Best is if you
>move onto new hardware at the same time as you don't keep
any legacy
>configuration mistakes.
>Regards
>Mike
>"Alice" wrote:
>
in[vbcol=seagreen]
like[vbcol=seagreen]
but[vbcol=seagreen]
be[vbcol=seagreen]
>.
>