Wednesday, March 28, 2012

replication strategy

Hi all,
First of all, I'm a newbi to databases.
Anyway, I am about to start writing a program that is handling
customers, invoices and so on. A decision has been taken to use Sql
Server 2000 (MSDE at customers)as RDBMS. It has also been decided that
the development should be devided into several iterations. Adding more
functionality at each iteration.
My problem is as follows: How do I distribute the design (tables,
stored proc, columns, keys etc) of the database when releasing new
versions of the program?
Let's assume that a customer table has the following columns "Id",
"Name" and "Phone". In the next version of my program I have added
funcionality to send e-mails to a customer so I have now added a
column called "Email" to the customer table.
This new column, some how, has to be inserted into the database before
the new version of the program can be used. I want to add this column
to the table without loosing any existing data in the table. Which is
the best strategy to do this? I have played around with SQLDMO,
looking at my own development database to create some sort of
definition file that could be used to alter table's. It feel's like
there is a better solution than to manualy go through all objects
(table, column, keys, Stored proc. etc) that I want to replicate.
Is there any good websites on this subject?
The program will be used at over 100 customers. Each customer should
run a installation program that will take care of updating the
database so that they can run the version of my program.
Br
JonasYou are really talking about distributing database
upgrade, not SQL Server replicaiton.
I'd just perform all (or most) database updates in some T-
SQL scripts, include the scripts in the install package,
have the install program control teir execution, and make
sure that the install program know how to check for
success/failure conditions and act accordingly.
I don't mean to sugges that you include all database
changes in a single T-SQL script. In many cases, that
wouldn't lead to robust error checking.
Linchi
>--Original Message--
>Hi all,
>First of all, I'm a newbi to databases.
>Anyway, I am about to start writing a program that is
handling
>customers, invoices and so on. A decision has been taken
to use Sql
>Server 2000 (MSDE at customers)as RDBMS. It has also been
decided that
>the development should be devided into several
iterations. Adding more
>functionality at each iteration.
>My problem is as follows: How do I distribute the design
(tables,
>stored proc, columns, keys etc) of the database when
releasing new
>versions of the program?
>Let's assume that a customer table has the following
columns "Id",
>"Name" and "Phone". In the next version of my program I
have added
>funcionality to send e-mails to a customer so I have now
added a
>column called "Email" to the customer table.
>This new column, some how, has to be inserted into the
database before
>the new version of the program can be used. I want to add
this column
>to the table without loosing any existing data in the
table. Which is
>the best strategy to do this? I have played around with
SQLDMO,
>looking at my own development database to create some
sort of
>definition file that could be used to alter table's. It
feel's like
>there is a better solution than to manualy go through all
objects
>(table, column, keys, Stored proc. etc) that I want to
replicate.
>Is there any good websites on this subject?
>The program will be used at over 100 customers. Each
customer should
>run a installation program that will take care of
updating the
>database so that they can run the version of my program.
>Br
>Jonas
>.
>

No comments:

Post a Comment