I am trying to find a way to easily merge data from one development laptop to another.
Me and another developer are working on a .NET application that uses SQL 2k. Since we are the only two developers, and we both work from home, we spend a lot of time working remotely, so we each have a copy of SQL on our laptops. While this plan works fine for the most part, we are finding that keeping our systems synchronized to be more painful than one would think it should be. Initially, we tried just using DTS packages to copy tables and data from one system to the other, but this would cause one person's data they had to be lost (not a bad thing, but a real pain if you are testing a specific scenario and have to have the data setup a certain way).
We then tried using SQL merge replication, but since the tables are still in active development, modifying, adding, or changing tables is next to impossible (I did find the way to disable the replication temporarily and then re-enable it, but it takes too long just to add a column or something else simple). I would be fine with the replication scenario if someone could suggest a way to easily modify the table schemas with the replication enabled.
I am pretty sure there has to a simple way to do what we are doing, its just that neither of us are familiar with SQL enough to really see how to do it. Is there a way to syncronize each row's data before pushing new schema elements to other servers using DTS, or is there an easy way to enable the replication and still be able to have access to the table's schema?It sounds to me like you are describing Merge replication for existing tables, and a bit of DTS (then establishing a new merge publication for ongoing changes) for new tables.
-PatP|||Exactly. For the normal, day-to-day stuff that we do the merge replication is fine because we are connected over a network (VPN or local LAN), so that works beautifully, I would like to keep it if possible. The pain starts when I have to make an update to the tables or add a new table (which at this point in development is VERY frequent, at least one new table a week and slight modifications to all as time and testing goes along). Unfortunately, we do not have the luxury of working off a plan, so the tables tend to be rather "from the hip", which compounds this problem even more.
I suppose I am more accustomed to LDAP replication (I am learning SQL the hard way), which replicates the schema objects in addition to the data. I am looking for something along those lines, where the master (or in this case Publisher) not only defines the data objects to the subscribers, it defines the schema to be used. I don't see why it would be that much different in SQL.
If I could just get a nod in the right direction, or even a 'it would be possible to do it, but watch for this and that' I would be eternally grateful, this is driving me nuts.sql
Showing posts with label laptop. Show all posts
Showing posts with label laptop. Show all posts
Friday, March 23, 2012
Replication Question
Wednesday, March 7, 2012
Replication Model
Hello,
I am just playing about with replication and trying to work the best way
to keep a central database updated.
We have a laptop user who will need to be able to work in disconnected mode
(MSDE) then connect up and replicate changes back to a server from which
others can run reports. The server copy will never be updated besides from
the changes replicated down from the 1 laptop user.
What would be the best model for this? Seems I have a few options but was
hoping someone could point me in the right direction of which machine would
be the publisher, the type (merge, snapshot) and whether push or pull. I
understand the concepts of publisher, subscriber etc, but am just unsure of
how it all fits together.
Thanks is advance
- EdHi
It sounds like your application would probably be a candidate for merge
replication, especially if there is a future need for more than one client
updating the data and if you are replicating larger volumes of data.
Snapshot replication would be more applicable if the data was not updatable
and the frequency of replication low.
You don't say which version of SQL Server is running on the server, this may
effect how you administer the replication and you may want to check out the
topic "Understanding SQL Server 2000 Desktop Engine (MSDE 2000)" in Books
Online.
John
"Ed." wrote:
> Hello,
> I am just playing about with replication and trying to work the best way
> to keep a central database updated.
> We have a laptop user who will need to be able to work in disconnected mode
> (MSDE) then connect up and replicate changes back to a server from which
> others can run reports. The server copy will never be updated besides from
> the changes replicated down from the 1 laptop user.
> What would be the best model for this? Seems I have a few options but was
> hoping someone could point me in the right direction of which machine would
> be the publisher, the type (merge, snapshot) and whether push or pull. I
> understand the concepts of publisher, subscriber etc, but am just unsure of
> how it all fits together.
> Thanks is advance
> - Ed
>
>
I am just playing about with replication and trying to work the best way
to keep a central database updated.
We have a laptop user who will need to be able to work in disconnected mode
(MSDE) then connect up and replicate changes back to a server from which
others can run reports. The server copy will never be updated besides from
the changes replicated down from the 1 laptop user.
What would be the best model for this? Seems I have a few options but was
hoping someone could point me in the right direction of which machine would
be the publisher, the type (merge, snapshot) and whether push or pull. I
understand the concepts of publisher, subscriber etc, but am just unsure of
how it all fits together.
Thanks is advance
- EdHi
It sounds like your application would probably be a candidate for merge
replication, especially if there is a future need for more than one client
updating the data and if you are replicating larger volumes of data.
Snapshot replication would be more applicable if the data was not updatable
and the frequency of replication low.
You don't say which version of SQL Server is running on the server, this may
effect how you administer the replication and you may want to check out the
topic "Understanding SQL Server 2000 Desktop Engine (MSDE 2000)" in Books
Online.
John
"Ed." wrote:
> Hello,
> I am just playing about with replication and trying to work the best way
> to keep a central database updated.
> We have a laptop user who will need to be able to work in disconnected mode
> (MSDE) then connect up and replicate changes back to a server from which
> others can run reports. The server copy will never be updated besides from
> the changes replicated down from the 1 laptop user.
> What would be the best model for this? Seems I have a few options but was
> hoping someone could point me in the right direction of which machine would
> be the publisher, the type (merge, snapshot) and whether push or pull. I
> understand the concepts of publisher, subscriber etc, but am just unsure of
> how it all fits together.
> Thanks is advance
> - Ed
>
>
Replication Model
Hello,
I am just playing about with replication and trying to work the best way
to keep a central database updated.
We have a laptop user who will need to be able to work in disconnected mode
(MSDE) then connect up and replicate changes back to a server from which
others can run reports. The server copy will never be updated besides from
the changes replicated down from the 1 laptop user.
What would be the best model for this? Seems I have a few options but was
hoping someone could point me in the right direction of which machine would
be the publisher, the type (merge, snapshot) and whether push or pull. I
understand the concepts of publisher, subscriber etc, but am just unsure of
how it all fits together.
Thanks is advance
- Ed
Hi
It sounds like your application would probably be a candidate for merge
replication, especially if there is a future need for more than one client
updating the data and if you are replicating larger volumes of data.
Snapshot replication would be more applicable if the data was not updatable
and the frequency of replication low.
You don't say which version of SQL Server is running on the server, this may
effect how you administer the replication and you may want to check out the
topic "Understanding SQL Server 2000 Desktop Engine (MSDE 2000)" in Books
Online.
John
"Ed." wrote:
> Hello,
> I am just playing about with replication and trying to work the best way
> to keep a central database updated.
> We have a laptop user who will need to be able to work in disconnected mode
> (MSDE) then connect up and replicate changes back to a server from which
> others can run reports. The server copy will never be updated besides from
> the changes replicated down from the 1 laptop user.
> What would be the best model for this? Seems I have a few options but was
> hoping someone could point me in the right direction of which machine would
> be the publisher, the type (merge, snapshot) and whether push or pull. I
> understand the concepts of publisher, subscriber etc, but am just unsure of
> how it all fits together.
> Thanks is advance
> - Ed
>
>
I am just playing about with replication and trying to work the best way
to keep a central database updated.
We have a laptop user who will need to be able to work in disconnected mode
(MSDE) then connect up and replicate changes back to a server from which
others can run reports. The server copy will never be updated besides from
the changes replicated down from the 1 laptop user.
What would be the best model for this? Seems I have a few options but was
hoping someone could point me in the right direction of which machine would
be the publisher, the type (merge, snapshot) and whether push or pull. I
understand the concepts of publisher, subscriber etc, but am just unsure of
how it all fits together.
Thanks is advance
- Ed
Hi
It sounds like your application would probably be a candidate for merge
replication, especially if there is a future need for more than one client
updating the data and if you are replicating larger volumes of data.
Snapshot replication would be more applicable if the data was not updatable
and the frequency of replication low.
You don't say which version of SQL Server is running on the server, this may
effect how you administer the replication and you may want to check out the
topic "Understanding SQL Server 2000 Desktop Engine (MSDE 2000)" in Books
Online.
John
"Ed." wrote:
> Hello,
> I am just playing about with replication and trying to work the best way
> to keep a central database updated.
> We have a laptop user who will need to be able to work in disconnected mode
> (MSDE) then connect up and replicate changes back to a server from which
> others can run reports. The server copy will never be updated besides from
> the changes replicated down from the 1 laptop user.
> What would be the best model for this? Seems I have a few options but was
> hoping someone could point me in the right direction of which machine would
> be the publisher, the type (merge, snapshot) and whether push or pull. I
> understand the concepts of publisher, subscriber etc, but am just unsure of
> how it all fits together.
> Thanks is advance
> - Ed
>
>
Replication Model
Hello,
I am just playing about with replication and trying to work the best way
to keep a central database updated.
We have a laptop user who will need to be able to work in disconnected mode
(MSDE) then connect up and replicate changes back to a server from which
others can run reports. The server copy will never be updated besides from
the changes replicated down from the 1 laptop user.
What would be the best model for this? Seems I have a few options but was
hoping someone could point me in the right direction of which machine would
be the publisher, the type (merge, snapshot) and whether push or pull. I
understand the concepts of publisher, subscriber etc, but am just unsure of
how it all fits together.
Thanks is advance
- EdHi
It sounds like your application would probably be a candidate for merge
replication, especially if there is a future need for more than one client
updating the data and if you are replicating larger volumes of data.
Snapshot replication would be more applicable if the data was not updatable
and the frequency of replication low.
You don't say which version of SQL Server is running on the server, this may
effect how you administer the replication and you may want to check out the
topic "Understanding SQL Server 2000 Desktop Engine (MSDE 2000)" in Books
Online.
John
"Ed." wrote:
> Hello,
> I am just playing about with replication and trying to work the best way
> to keep a central database updated.
> We have a laptop user who will need to be able to work in disconnected mod
e
> (MSDE) then connect up and replicate changes back to a server from which
> others can run reports. The server copy will never be updated besides from
> the changes replicated down from the 1 laptop user.
> What would be the best model for this? Seems I have a few options but was
> hoping someone could point me in the right direction of which machine woul
d
> be the publisher, the type (merge, snapshot) and whether push or pull. I
> understand the concepts of publisher, subscriber etc, but am just unsure o
f
> how it all fits together.
> Thanks is advance
> - Ed
>
>
I am just playing about with replication and trying to work the best way
to keep a central database updated.
We have a laptop user who will need to be able to work in disconnected mode
(MSDE) then connect up and replicate changes back to a server from which
others can run reports. The server copy will never be updated besides from
the changes replicated down from the 1 laptop user.
What would be the best model for this? Seems I have a few options but was
hoping someone could point me in the right direction of which machine would
be the publisher, the type (merge, snapshot) and whether push or pull. I
understand the concepts of publisher, subscriber etc, but am just unsure of
how it all fits together.
Thanks is advance
- EdHi
It sounds like your application would probably be a candidate for merge
replication, especially if there is a future need for more than one client
updating the data and if you are replicating larger volumes of data.
Snapshot replication would be more applicable if the data was not updatable
and the frequency of replication low.
You don't say which version of SQL Server is running on the server, this may
effect how you administer the replication and you may want to check out the
topic "Understanding SQL Server 2000 Desktop Engine (MSDE 2000)" in Books
Online.
John
"Ed." wrote:
> Hello,
> I am just playing about with replication and trying to work the best way
> to keep a central database updated.
> We have a laptop user who will need to be able to work in disconnected mod
e
> (MSDE) then connect up and replicate changes back to a server from which
> others can run reports. The server copy will never be updated besides from
> the changes replicated down from the 1 laptop user.
> What would be the best model for this? Seems I have a few options but was
> hoping someone could point me in the right direction of which machine woul
d
> be the publisher, the type (merge, snapshot) and whether push or pull. I
> understand the concepts of publisher, subscriber etc, but am just unsure o
f
> how it all fits together.
> Thanks is advance
> - Ed
>
>
Tuesday, February 21, 2012
Replication in XP home
Please help!!
I have recently installed ms sql on my system and I am trying to replicate my machine which happens to be a compaq laptop which is running xp home edition. The publisher machine can see my server however gives me an invalid subscription error. I have been told that it might be due to the fact the the laptop is on xp home, would this be a problem???
please get back to me, anyone.,.much appreciated!!!!
JaysunJaysun,
What version of SQL Server did you install? Check http://www.microsoft.com/sql/evaluation/sysreqs/2000/default.asp for version/OS compability.
If your version of SQL Server is compatible with XP home I would also suggest looking at the account that SQL Server is using to login. If it is using the local system account then I will not be able to talk to other servers on the domain.
Regards,|||hi thanks for coming back to me, ive checked the version and its ok. plus i can connect to the publisher and also to other servers. esp to another laptop that is running xp prof, and that does not seem to have a problem replicating. however i cannot connect to other servers running windows 2k. ive checked the sql account and username and password is the same as the other laptop./
the error i get when i try and connect to another server:
login failed for user 'sa' not associated with a trusted sql server
would it be because i this one is not logged into a domain??
I have recently installed ms sql on my system and I am trying to replicate my machine which happens to be a compaq laptop which is running xp home edition. The publisher machine can see my server however gives me an invalid subscription error. I have been told that it might be due to the fact the the laptop is on xp home, would this be a problem???
please get back to me, anyone.,.much appreciated!!!!
JaysunJaysun,
What version of SQL Server did you install? Check http://www.microsoft.com/sql/evaluation/sysreqs/2000/default.asp for version/OS compability.
If your version of SQL Server is compatible with XP home I would also suggest looking at the account that SQL Server is using to login. If it is using the local system account then I will not be able to talk to other servers on the domain.
Regards,|||hi thanks for coming back to me, ive checked the version and its ok. plus i can connect to the publisher and also to other servers. esp to another laptop that is running xp prof, and that does not seem to have a problem replicating. however i cannot connect to other servers running windows 2k. ive checked the sql account and username and password is the same as the other laptop./
the error i get when i try and connect to another server:
login failed for user 'sa' not associated with a trusted sql server
would it be because i this one is not logged into a domain??
Subscribe to:
Posts (Atom)