Diaster Recovery - Different Build Numbers

I have to test for a diaster recovery plan (in case the
building burned down) We do a full backup of the data
files on our SQL Server 2000 nightly. (Using Veritas with
SQL client) My job is to build a new server and restore
the databases. All is find until I try to restore the
master. Then I get the error that the build numbers are
different. I have applied all the service packs and
patches that I believe to be on the original box, but
cannot get the build numbers to match. Does MS list what
patches or updates are in which build numbers?
ThanksChris,
See if this helps
SQLSecurity Checklist
http://www.sqlsecurity.com/DesktopDefault.aspx?tabindex=3&tabid=4
--
Dinesh.
SQL Server FAQ at
http://www.tkdinesh.com
"Chris" <chris.mcbirney@.go.doe.gov> wrote in message
news:581b01c376ff$9a59f2b0$a501280a@.phx.gbl...
> I have to test for a diaster recovery plan (in case the
> building burned down) We do a full backup of the data
> files on our SQL Server 2000 nightly. (Using Veritas with
> SQL client) My job is to build a new server and restore
> the databases. All is find until I try to restore the
> master. Then I get the error that the build numbers are
> different. I have applied all the service packs and
> patches that I believe to be on the original box, but
> cannot get the build numbers to match. Does MS list what
> patches or updates are in which build numbers?
> Thanks

Developing a Search Case

hi all,
I am developing a search case...and i got to develop a stored procedure.

the procedure will be called in the following way...

exec search_text('t1@.c1%c2%c3%t2@.c1%c2%c3%t3@.c1%c2%,'he llo')

i.e. i want to search for 'hello' in the t1,t2,t3 tables and c1,c2,c3..are the corresponding columns in respective tables..

writing select statement is easy.,..but need a best solution to divide the tables and columns and then writing the procedure...

help me out...

thanks and regards
sai sreenivasHi,

it all depends on what database server you want to run the Stored Procedure...
So, what's the database and we try again...|||hii ,
My Database server is SQLSERVER on windows 2000 platform.....

looking forward for your reply...

thanks and regards
SAI SREENIVAS JEEDIGUNTA|||I'm sorry man, I'm not that familiar with Microsoft software.
If it were DB2 or Informix I could give you the solution...|||Will you always have the pattern 1 table and 3 columns ? Can you post the sql statement you have already designed that you want emulated in the sp ? Will you be running this sp in sql server or through a front-end like visual basic ... ? Will you always be searching for "hello" or some unknown string ?|||What results are you expecting back from your stored procedure ?

Dev. Team - Keeping Three Tiers in Sync

This may not be a MSSQL-specific question, but
I wanted to ask it here first, in case there's
a MSSQL and/or SourceSafe solution that will help.

Our dev team is having some difficulty with
keeping the nightly builds in sync with the
stored proc mods. I'm wondering if there are
some good case studies on how to avoid this
"drift". Something like genning a new DB from
checked-in SPs, etc. alongside each regular build,
then always have a paired enterprise app/database
duo that is tagged and added to a history.

FWIW, we have a 3-tier .NET/C# app, and
ADO.NET is throwing exceptions every other
day.

If the suggestion is to whip the DB guys, that
works for me as well. ;-)

Nah, there's much love there.

Thanks in advance,
~swoozWe keep all of our DDL scripts under source control. These are labeled and
built along with the app code as part of an installer custom action. We
promote all stored procedures, views, and functions along with the rest of
the app so the interfaces don't get out of sync as long as the checked-in
code is correct.

Our database installer allows either a new our upgrade installation. Even
if the 'new' install isn't needed for production, it facilitates testing
since it's the 'gold' database schema. We also include upgrade capability
as needed for production releases. The bottom line is that new and upgraded
schema are identical.

--
Hope this helps.

Dan Guzman
SQL Server MVP

"swoozie" <swooziep@.yahoo.com> wrote in message
news:1112826148.798845.123840@.g14g2000cwa.googlegr oups.com...
> This may not be a MSSQL-specific question, but
> I wanted to ask it here first, in case there's
> a MSSQL and/or SourceSafe solution that will help.
> Our dev team is having some difficulty with
> keeping the nightly builds in sync with the
> stored proc mods. I'm wondering if there are
> some good case studies on how to avoid this
> "drift". Something like genning a new DB from
> checked-in SPs, etc. alongside each regular build,
> then always have a paired enterprise app/database
> duo that is tagged and added to a history.
> FWIW, we have a 3-tier .NET/C# app, and
> ADO.NET is throwing exceptions every other
> day.
> If the suggestion is to whip the DB guys, that
> works for me as well. ;-)
> Nah, there's much love there.
> Thanks in advance,
> ~swooz|||We use a product called DB Ghost to build our SQL Server databases
directly from SourceSafe every 10 minutes. A script checks the report
it produces for any errors and automatically emails all of the DBAs and
Development team if any are found. This covers any syntax or
dependency issues with checked in code.

If everything builds OK DB Ghost is then used to produce an upgrade
script against a restored copy of our test database. If this fails the
problem is emailed out and fixed there and then. The test database
copy is then restored again and the compare rerun - if it works then we
have a delta script that we can run in Query Analyzer against our real
test database. This same approach is used all the way to production.
The script produced also works first time - I've used other products
before but none of them come close to producing a working delta script
in the first run - I always had to correct object dependency problems
manually in Query Analyzer first.

The real beauty of this is that we only keep the delta script produced
by our overnight build which starts from a labelled baseline of all
code in VSS. This means that our SQL Code is 100% in line with our
VB6/.NET and ASP code every single time we do a release. Sure, it
doesn't get around the problem of developers not checking their changes
in properly but it does give us a great audit trail which means we get
to the root causes of those tricky test database problems real quick.

We are even thinking of losing the delta script altogether and just
letting DB Ghost do the upgrade dynamically, that way our baselined,
labelled scripts in VSS are the real 'source database' - this is
totally cool stuff.