Link Table

Ronia,
this could be achieved using replication (and triggers,
linked servers, DTS...). It largely depends on latency -
the delay between the change made on A and it appearing
on B, and whether the data in B is updatable. If you can
give me a bit more info on these matters, then we'll be
in a better position to advise.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
Hi Paul,
Data won't be update by table B. Update will only done via Table A.
so it is only a read only .
There's a replication mode which fit with this scen.
But i am not familiar with replication. and i will ask me not to use system
account with it, I don't know how to do it.
Thanks.
Ronia.
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> ?
news:8aae01c4d17a$1828d140$a601280a@.phx.gbl ?...
> Ronia,
> this could be achieved using replication (and triggers,
> linked servers, DTS...). It largely depends on latency -
> the delay between the change made on A and it appearing
> on B, and whether the data in B is updatable. If you can
> give me a bit more info on these matters, then we'll be
> in a better position to advise.
> Rgds,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
|||Transactional replication would be best for your
scenario. Replication uses agents which are essentially
jobs run by the sql server agent. For the security
requirements have a look in books on line
for 'replication, security', 'Role Requirements'.
To run replication you won't need the sysadmin account
but to set it up, configure it and monitor it, you will.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Hi Ronia,
Why dont you create a view in your database "B"?
Use B
Go
Create view T
As
Select * From A.dbo.T
Go
This will let you read the data from the database A, table T.
Sriram
"Ronia" <Ronia@.mail.com> wrote in message news:<OaGb5tj0EHA.480@.TK2MSFTNGP10.phx.gbl>...
> Hi Paul,
> Data won't be update by table B. Update will only done via Table A.
> so it is only a read only .
> There's a replication mode which fit with this scen.
> But i am not familiar with replication. and i will ask me not to use system
> account with it, I don't know how to do it.
> Thanks.
> Ronia.
|||hi Sriram,
Will there be any preformance issue.. when doing this? However is they
are located within the same server is that performance will not be an
issue?...
compare with Transactional replication which will be better?
Thanks
Ronia
"Sriram" <srivish@.gmail.com> ?
news:25274ca3.0411241354.5e914fc2@.posting.google.c om ?...
> Hi Ronia,
> Why dont you create a view in your database "B"?
> Use B
> Go
> Create view T
> As
> Select * From A.dbo.T
> Go
> This will let you read the data from the database A, table T.
> Sriram
>
> "Ronia" <Ronia@.mail.com> wrote in message
news:<OaGb5tj0EHA.480@.TK2MSFTNGP10.phx.gbl>...[vbcol=seagreen]
system[vbcol=seagreen]
|||It depends...
If you require a copy of the data, so eg you can do
reports on it, while not affecting - blocking - users who
are making updates on the main table, then replication
would be suitable. It can also be used to effectively
load balance database access if the databases exist on
different drives. Also, so people use snapshot
replication to have a copy of a table that users can play
around with and modify the data indiscriminantly, knowing
that all the changes will later be overwritten.
So, what is your requirement for a copy of the data? If
it doesn't fit into one of these categories, then a cross-
database view may indeed be the solution.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

Limits on number of merge subscribers?

I'm testing merge replication between a SQL server 2000
publisher and multiple MSDE subscribers. The publication
consists of somewhere around 200 articles (tables, views,
store procs). All subscriptions are pull subscriptions.
My test environment has roughly 10 subscribers.
So far the solution seems to work nicely.
Does anyone know what kind of performance issues I may run
into if the number of subscribers increased to 50 or 100?
It there a theoretical limit or is it simply a question of
machine capability and band width?
Pat,
I haven't ever used more than a dozen simultaneous subscribers, but this
article details scaling up to 2000 subscribers and the correlation with
download speed, effect of RAM, processors etc:
http://www.microsoft.com/technet/pro...mergperf.mspx.
BTW, as far as I know there is no documented limit to the number of
subscribers.
HTH,
Paul Ibison

Limitation in number of fields a Table published by push merge Replication may have

SQL 2000 SP3: There is a table with more than 254 Fields in it. (please
don't ask why :-) )
we observed, that replication on fields which are beyond the magic limit of
254 simply do not replicate.
( Enterprise manager says Replication takes place, but data do not show up
at destination.
Is this a known documented limitation ? Is it a bug with perhaps an
existing patch?
This is a known limitation. I'd consider splitting up the table into 2
separate related tables related and replicate them both. This can be made
transparent to the users by presenting them with a view which has the
original table's name and an InsteadOf trigger.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||I consider this to be a bug:
The Enterprisemanager accepts the publikation,
The replication Monitor says "1 Insert Done"
but the data is lost.
I would have no objections if the enterprise manager said:
"are you mad this is nothing you should publish I can't publish tables that
are so large / task rejected"
But If It accepts the task It should accomplish the task.
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:uieZiLGFFHA.1564@.TK2MSFTNGP09.phx.gbl...
> This is a known limitation. I'd consider splitting up the table into 2
> separate related tables related and replicate them both. This can be made
> transparent to the users by presenting them with a view which has the
> original table's name and an InsteadOf trigger.
> Rgds,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>