[MSSQL] Tabellen synchronizeren

Pagina: 1
Acties:

Onderwerpen


Verwijderd

Topicstarter
Ik heb een VB 2008 applicatie welke gekoppeld is aan een database.
De koppeling naar de db is aangegeven in een ConnectionString.

Nu maak ik gebruik van twee verschillende databases, voor twee verschillende bedrijven.

Nu heb ik een nieuw onderdeel toegevoegd welke gebruik moet maken van dezelfde data. Dus als er in database 1 wat wordt toegevoegd, verwijderd of aangepast dan moet dit precies ook zo gedaan zijn in database 2 en vice versa.

Nu kan ik door middel van triggers op de tabellen hier wel voor zorgen, het gaat ongeveer om 10 tabellen. Dit is wel tijdrovend werk en wanneer ik wat aan ga passen moet ik alle triggers weer doorlopen. Ik heb niet echt een idee of dit op een andere manier kan.

Ik maak in de applicatie gebruik van de tableadapters welke gekoppeld zijn aan de database. Dus ik kan de database wel iedere keer omzetten, zodat de betreffende data uit één database komt, maar mocht de applicatie dan een keer vastlopen, dan weet ik niet of de database weer naar de juiste database wordt gezet. Zelfde probleem is wanneer er een ander scherm wordt geopend welke gebruik maakt van de andere database.

Is er iemand die kan zeggen hoe ik dit het beter kan doen? Als het niet anders kan ga ik verder met het maken van de triggers, maar als het makkelijker kan dan graag.

De connectionstring is aangemaakt in my.settings.

Bedenk me net (terwijl ik dit type) dat ik mogelijk ook een extra connectionstring kan aanmaken voor de primary database en dan deze tableadapters altijd aan deze koppel.
Zo hoef ik date betreffende tabellen maar in 1 database te vullen en is het niet noodzakelijk dat deze bestaan in de andere db.
Of heeft er iemand een beter idee?


Als mijn verhaal niet duidelijk is hoor ik het graag. Ik weet even niet hoe ik het beter kan uitleggen.

  • Orion84
  • Registratie: April 2002
  • Laatst online: 16-09 17:40

Orion84

Admin General Chat / Wonen & Mobiliteit

Fotogenie(k)?

Wat zit er in die twee databases en wat maakt ze verschillend, terwijl ze toch voor dezelfde applicatie bedoeld zijn en blijkbaar wel op elkaar lijken (aangezien je ze wilt synchroniseren).

Klinkt alsof je beter twee aparte applicaties kan hebben, met elk hun eigen DB, of juist 1 applicatie met 1 DB met daarin alle data. Maar misschien mis ik iets in je uitleg en heb je een goede reden om voor deze opzet te kiezen?

The problem with common sense is that it's not all that common. | LinkedIn | Flickr


Verwijderd

Topicstarter
De applicatie is identiek voor beide, maar de databases zijn verschillend aangezien er door twee aparte BV's in gewerkt wordt.
Nu hebben we een systeem ontwikkeld waarin de bedrijven gaan samenwerken, hierin gaat altijd dezelfde data gebruikt worden.

  • Orion84
  • Registratie: April 2002
  • Laatst online: 16-09 17:40

Orion84

Admin General Chat / Wonen & Mobiliteit

Fotogenie(k)?

En over welk deel gaat je vraag nu precies? Over die twee identieke applicaties die met verschillende databases overweg moeten kunnen? Of over dat nieuwe gedeelde systeem?

En wat betreft dat laatste: wat bedoel je met "dezelfde data"? Een derde, centrale database, of een set met data die in beide oorspronkelijke databases voorkomt?

Probeer eens iets gestructureerder uit te leggen wat de situatie is en wat je probleem is, want persoonlijk kan ik er echt geen touw aan vast knopen. Teken anders eens wat plaatjes van de verschillende componenten en de data die daarin is opgeslagen en verwerkt wordt etc.

The problem with common sense is that it's not all that common. | LinkedIn | Flickr


  • Hydra
  • Registratie: September 2000
  • Laatst online: 21-08 17:09
MSSQL kan dat ook zelf voor je regelen: MSDN: SQL Server Replication

https://niels.nu


  • Orion84
  • Registratie: April 2002
  • Laatst online: 16-09 17:40

Orion84

Admin General Chat / Wonen & Mobiliteit

Fotogenie(k)?

De vraag is alleen of de topicstarter wel een probleem heeft waarvoor replication de oplossing is. Als ik hem hoor praten over twee verschillende databases van verschillende bedrijven, dan klinkt replication niet heel logisch.

The problem with common sense is that it's not all that common. | LinkedIn | Flickr


  • Tukk
  • Registratie: Januari 2002
  • Laatst online: 17-09 10:57

Tukk

De α-man met het ẞ-brein

Andere oplossingen:

• Een derde database waarin je de gemeenschappelijke data regelt (deze database is dan de bron voor de andere twee, geen problemen als er even een db uitligt). IMHO de meest logische keuze op basis van je info,
• SSIS, eens per x minuten de data synchen tussen de twee databases

Q: How many geeks does it take to ruin a joke? A: You mean nerd, not geek. And not joke, but riddle. Proceed.


  • Hydra
  • Registratie: September 2000
  • Laatst online: 21-08 17:09
Orion84 schreef op woensdag 19 september 2012 @ 15:25:
[...]

De vraag is alleen of de topicstarter wel een probleem heeft waarvoor replication de oplossing is. Als ik hem hoor praten over twee verschillende databases van verschillende bedrijven, dan klinkt replication niet heel logisch.
Klinkt mij meer alsof hij 2 keer dezelfde applicatie heeft draaien met alleen andere data (zelfde databasestructuur) en nu dat samen wil laten werken. Hoe dan ook moet 'ie gewoon duidelijker zijn en wat meer eigen inzet tonen, ook gezien z'n posthistorie, IMHO.

https://niels.nu

Pagina: 1