offline db synchroniseren met online db

[Verwijderd]

Ik ben bezig met een project waarbij het mogelijk moet zijn om in een webbased omgeving gegevens uit een online database op te halen en deze gegevens vervolgens te verwerken in een offline database.

Deze situatie gaat uit van een website waarop een db draait en een intranet met een webserver en database. De keuze voor soort scripttaal (php of asp) en soort database (mysql, mssql of access) is nog niet gemaakt.

Het script dat de gegevens afkomstig uit de online db in de offline db gaat plaatsen draait op het intranet. Dit script wordt aangeroepen vanuit een synchronisatie tool en bevat sql instructies.

Het probleem is dat ik nog niet precies weet wat de meest handige manier is om de gegevens uit de online db naar het offline verwerk script te krijgen. In mijn optiek zijn er een aantal mogelijkheden:

1. Vanuit het intranet de gegevens uit de online db ophalen via ODBC (dat betekent dat de online db mysql of mssql moet zijn)

2. Vanuit het internet de gegevens ophalen met een online script en deze data posten naar het intranet. Op het intranet staat een script dat de data verder verwerkt.

3. Vanuit het intranet een online bestand (met een script) includen waarin alle gegevens al opgehaald zijn. (dit werkt volgens mij niet met asp)

4. Een frameset neerzetten met daarin twee frames, een met een online bestand dat de data uit de database haalt en een met een offline bestand dat met javascript alle data uit het andere frame haalt en doorgeeft aan een ander offline bestand.

De verschillende mogelijkheden die ik zie hebben ieder hun voors en tegens. Misschien zijn er nog meer mogelijkheden. Heeft iemand een idee wat de beste optie is, of misschien een beter idee?

[Verwijderd]

Hoewel je verhaal uitgebreid is, weet ik toch niet wat je precies wil.

Je hebt het over 2 websites, met ieder een eigen database en bovendien praat je over een online en offline database. Bedoel je nu dat de Internetsite aan de online database is gekoppeld en de intranetsite aan de offline database?

Vervolgens moet gegevens uit 1 database naar een andere database worden gezet. Wil je de gegevens werkelijk verwijderen van de oorspronkelijke database, of repliceren? Op welke basis moeten de gegevens worden omgezet? Real-time, 1 keer per dag, etc.

Misschien is het ook zinvol ongeveer te beschrijven over wat voor toepassing en gegevens we praten, want dat helpt vaak bij de beeldvorming.

Succes

[Verwijderd]

Wellicht is dit ook nog zinvolle info: niet alle data uit een db moet realtime benaderbaar zijn. MS SQL kan ook (periodiek) HTML resultaten generen, dit is met name handig voor data die niet vaak wijzigd (bijv adressenlijst). Dit scheelt een hoop verwerkingstijd/snelheid en toch houd je je gegevens centraal in je db. Kost alleen wat meer HD ruimte. Ik had voorheen alles via een db lopen maar ben nu gedeelten aan het omzetten naar boven beschreven methode.
Wellicht helpt het, suc6

[djack]

synchroniseren van gegevens is vrij complex al je het goed wilt doen.
denk maar eens aan een sales organisatie, 2 personen 1 db, persoon 1 en 2 halen in de vroege uurtjes alle gegevens op, in de dag werken ze er bijde me locaal op de pc, bijde aan dezelfde klanten, als die in de avond gaan syncen, .... welke gegevens gaat de centrale db bijhouden, als je geen controles doet, die van de laatste persoon die synct.
We hebben er vrij lang onze kop over aan het breken geweest, nu zijn we er eindelijk uitgeraakt, met de hoop dat het een fail save systeem is, maar zeer complex en dat wil ik jullie besparen, maar op field level zou het in theory mogelijk moeten zijn om te checken, lets hope :-)

[Janoz]

djack schreef op 20 september 2002 @ 13:03:
synchroniseren van gegevens is vrij complex al je het goed wilt doen.
denk maar eens aan een sales organisatie, 2 personen 1 db, persoon 1 en 2 halen in de vroege uurtjes alle gegevens op, in de dag werken ze er bijde me locaal op de pc, bijde aan dezelfde klanten, als die in de avond gaan syncen, .... welke gegevens gaat de centrale db bijhouden, als je geen controles doet, die van de laatste persoon die synct.
We hebben er vrij lang onze kop over aan het breken geweest, nu zijn we er eindelijk uitgeraakt, met de hoop dat het een fail save systeem is, maar zeer complex en dat wil ik jullie besparen, maar op field level zou het in theory mogelijk moeten zijn om te checken, lets hope :-)

Wat dacht je van een vooraad van 1 die door 2 mensen verkocht wordt

Maar ik krijg het ID dat het in dit geval maar 1 kant op gaat.. Online is de meest recentste en af en toe moeten de gegevens van de locale worden aangevult zodat deze weer gelijk is aan de online versie...

Als de topicstarter hier nu eens uitsluitsel over kan geven, dan kunnen we ook wat gerichter advies geven .

[Verwijderd]

Ten eerste bedankt voor de reacties

De offline database is een Exact database. Via ODBC is deze db te benaderen op een afgeschermd deel van het Intranet. Op het Intranet draait een asp script waarmee het mogelijk moet zijn om orders uit de online database op te halen. bijv. een overzicht met alle orders die online geplaatst zijn. Op dit overzicht kunnen orders aangevinkt worden, de aangevinkte orders worden dan ingevoerd in de Exact database. Via sql instructies kunnen de online gegevens dan in de goede tabellen van de exact db geplaats worden.

Synchroniseren is dus niet veel meer dan de online orders ophalen en verwerken in de administratie. Synchronisatie de andere kant op, dus nieuwe artikelprijzen vanuit Exact naar de online db plaatsen is minder ingewikkeld, omdat deze gegevens vanuit het intranet geppost kunnen worden naar een asp pagina op de website die de data vergelijkt met de data uit de online db en met sql de online gegevens update.

De beheerder van de website moet met behulp van een button op het intranet kunnen zegeen "ik wil de nieuwe prijzen zoals ze in Exact staan verwerken in de website" of "ïk wil een overzicht van alle orders uit de online db en deze verwerken in Exact "

Ik hoop dat het nu iets duidelijker is.

[Verwijderd]

Okay, er is dus sprake van 2 synchronisaties, die allebei maar 1 kant opwerken, namelijk:
1) online orders --> exact database
2) exact prijzen --> online prijzen

In allebei de gevallen is het heel erg belangrijk dat het goed gaat, want je wil geen orders verliezen of dubbel overnemen, en je wil ook niet dat de online prijzen niet kloppen. Foutafhandeling zal dus erg belangrijk zijn. Hierbij een voorstel van hoe je het zou kunnen doen.

1) Online orders -> Exact database
Je moet de volgende stappen doen:
a) vraag alle online orders op met status 'open'
b) laat de gebruiker selecteren welke orders in behandeling moeten worden genomen
c) zet de status van deze orders naar 'in behandeling', en haal de gegevens op
d) probeer de gegevens van de orders geautomatiseerd te verwerken in de Exact database
e) als het lukt, zet de status van de order op 'bevestigd'
f) als het niet lukt, zet de status op 'mislukt'
g) zorg dat er een functionaliteit komt om alle orders net status 'mislukt' te bekijken, zodat de gegevens handmatig aangepast kunnen worden, of handmatig verwerkt munnen worden, waarna de status van de order handmatig gewijzigd kan worden

Om dit technisch te realiseren zou je een XML interface kunnen maken op je online database, waarbij je je data via parameters meegeeft, en de resultaten in XML formaat terugkrijgt. Zorg wel dat deze XML interface goed in beveiligd (username/password erop, liefst ook SSL).

2) exact prijzen --> online prijzen
Hierbij moeten de volgende stappen genomen worden:
a) toon scherm 'voer prijswijzigingen door' met knop 'ok'
b) ga voor ieder artikel de prijs aanpassen
c) als er een fout is, bewaar die, inclusief artikel- en prijsinformatie
d) toon alle mislukte prijswijzigingen

Evt. zou je hierbij ook kunnen checken of er artikelen online zijn waarvan er helemaal geen prijs in Exact aanwezig is.

De technische implementatie zou ik ook weer via een XML interface doen. De achterliggende database is dan niet belangrijk. plus je kunt heel goed 'audit' fasciliteiten toevoegen (wie heeft wat wanneer gedaan) om te kunnen debuggen en andere (organisatorische) problemen boven water te krijgen.

Succes