[SQLServer] table uit andere database linken

[MrHighStone]

Geen idee of het kan, maar ik zou graag een tabel uit de ene database 'linken' naar een andere database. Iemand enig idee (zonder views te gebruiken)?

[Verwijderd]

SELECT * FROM [databasenaam]..[tabelnaam]
werkt heel goed

[Verwijderd]

SELECT * FROM [databasenaam].[dbo].[tabelnaam]

dan toch

[Verwijderd]

Verwijderd schreef op 28 november 2002 @ 09:40:
SELECT * FROM [databasenaam].[dbo].[tabelnaam]

dan toch

Het is maar net de vraag of de owner van de tabel ook echt dbo is en niet bijvoorbeeld Developer of boschpj. Daar zal je dus wel even rekening moeten houden.

[Verwijderd]

Als je de naam weglaat dan gebruikt ie volgens mij de rechten die je hebt op de tabel. Dat is wel handig als je niet weet welke gebruiker zo'n link gaat raadplegen. Kan je dus de security gebruiken die je zelf hebt neergezet.

[MrHighStone]

Oeps, ik heb me iets te eenvoudig uitgedrukt.

Wat ik bedoel is het volgende:
Stel ik heb een productentabel in database A
Ik wil deze productentabel 'hergebruiken' in database B, met daarbij de mogelijkheid ook constraints ed toe te passen (helaas gaat dit niet met een view, anders was het eenvoudig), maar waarbij de data in database A blijft staan. Dus eigenlijk als tabel op te nemen in database B.

Beetje hetzelfde idee als een tabel in een access database linken vanuit een andere database, maar dan in SQL Server

Lekker duidelijk he

[Annie]

MrHighStone schreef op 28 November 2002 @ 10:41:
Lekker duidelijk he

uhh, nee

Om toch een poging te doen je te begrijpen gooi ik even de term "replication" in de ring (zie bijv. books online voor meer info). Ik vermoed dat je het in die richting moet zoeken.

[Verwijderd]

Verwijderd schreef op 28 November 2002 @ 09:50:
[...]


Het is maar net de vraag of de owner van de tabel ook echt dbo is en niet bijvoorbeeld Developer of boschpj. Daar zal je dus wel even rekening moeten houden.

'dbo' staat voor db owner, ongeacht wie tot die role behoort. Het is echt NOT DONE tables aan te maken onder een andere user dan de db owner, daar krijg je alleen maar ellende mee: security regel je middels andere methodieken.

[Verwijderd]

nog iets meer help (een beetje maar, don't worry):
Je originele tabel wordt je publication. De tabel waar je naartoe wil je subscription. Indien je ook wijzigingen wil maken kan het ook andersom. Voordeel van deze methode boven een job laten lopen oid is dat het niet op dezelfde server hoeft te staan...

[Verwijderd]

Ik denk dat Annie een hele goede oplossing heeft aangedragen...
Je zou namelijk kunnen denk aan bijvoorbeeld Transactional replication.
Maar er zijn wel een aantal dingen waar je aan moet denken:
Mag Database B ook records toevoegen aan Database A...
Hoe gaat het met constraints en replicatie?
Maar goed... kijk maar eens in books online....

[Verwijderd]

Als de tabel op een andere server staat dan zou ik inderdaad repliceren. Anders zou ik dat niet doen. Dan heb je replicatie helemaal niet nodig.
Constraints kan je ook met triggers afdwingen die kijkt naar je tabel uit de andere database

[Verwijderd]

Maar bij replicatie kan je de triggers ook mee repliceren.... Dan hoef je het niet dubbel te doen.... Gewoon eenvoudiger dus....

[Verwijderd]

Ik bedoel dus triggers die in 1 database staan maar over de tabellen op beide databases werken. Waarom zou je een tabel repliceren naar een andere database op dezelfde server ?
Lijkt mij overkill.

[kenneth]

Verwijderd schreef op 28 november 2002 @ 13:24:
[...]

'dbo' staat voor db owner, ongeacht wie tot die role behoort. Het is echt NOT DONE tables aan te maken onder een andere user dan de db owner, daar krijg je alleen maar ellende mee: security regel je middels andere methodieken.

Maar dan voldoet dbnaam..tblnaam toch? Waarom dan per sé dbnaam.dbo.tblnaam

[Verwijderd]

mithalph schreef op 28 november 2002 @ 15:42:
[...]
Maar dan voldoet dbnaam..tblnaam toch? Waarom dan per sé dbnaam.dbo.tblnaam

Omdat je met dbo zeker weet dat je de tabel kan benaderen, ook wanneer iemand een table heeft aangemaakt onder zn eigen user

[Verwijderd]

Als de databases binnen 1 instance van SQL Server staan, dan is het zeker makkelijker om het aan te roepen met dbo...database.... maar als het op een andere instance staat, dan is repliceren makkelijker dan door middel van een linked server....

[wacco]

Als ik jou posts lees, en de hele discusse over dbo even negeer, vermoed ik dat je gewoon dit wilt:
verwijzen uit db B naar db A, zodat de info uit A niet in B terecht komt, maar dat B wel de info beschikbaar heeft (en kan wijzigen). Right?

Waarom selecteer je dan niet gewoon uit allebie de db's, en verwijs je naar de vars met B.var en A.var? En wil je dan iets wijzigen dan gaat dat goed. Verder vertel je de gebruiker dat het maar één db is, en die heeft dan niets door. Wil je informatie met elkaar verbinden, dan zorg je gewoon dat de unieke id van elkaar gekoppeld wordt. Dit kan in db B als iedere record gelinkt moet worden met iets uit A, of je maakt er een aparte tabel voor.

(of klets ik nu onzin en kán dit helemaal niet met db's? en kan dit alleen maar met tables?)