Showing posts with label newbi. Show all posts
Showing posts with label newbi. Show all posts

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
quote:

>--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
quote:

>customers, invoices and so on. A decision has been taken

to use Sql
quote:

>Server 2000 (MSDE at customers)as RDBMS. It has also been

decided that
quote:

>the development should be devided into several

iterations. Adding more
quote:

>functionality at each iteration.
>My problem is as follows: How do I distribute the design

(tables,
quote:

>stored proc, columns, keys etc) of the database when

releasing new
quote:

>versions of the program?
>Let's assume that a customer table has the following

columns "Id",
quote:

>"Name" and "Phone". In the next version of my program I

have added
quote:

>funcionality to send e-mails to a customer so I have now

added a
quote:

>column called "Email" to the customer table.
>This new column, some how, has to be inserted into the

database before
quote:

>the new version of the program can be used. I want to add

this column
quote:

>to the table without loosing any existing data in the

table. Which is
quote:

>the best strategy to do this? I have played around with

SQLDMO,
quote:

>looking at my own development database to create some

sort of
quote:

>definition file that could be used to alter table's. It

feel's like
quote:

>there is a better solution than to manualy go through all

objects
quote:

>(table, column, keys, Stored proc. etc) that I want to

replicate.
quote:

>Is there any good websites on this subject?
>The program will be used at over 100 customers. Each

customer should
quote:

>run a installation program that will take care of

updating the
quote:

>database so that they can run the version of my program.
>Br
>Jonas
>.
>

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
>.
>