[.NET + MSSQL + VBA] Access applicatie <--> Website + Versie

Pagina: 1
Acties:

Acties:
  • 0 Henk 'm!

  • Josvds
  • Registratie: November 2004
  • Laatst online: 26-08 20:42
Ik ben bezig met de ontwikkeling van een uitbreiding op een bestaand pakket.
Het bestaande pakket is gebouwd in Access en daarbij gebruik maakend van een Access database.
Het systeem is wel multi user opgezet en locks bij eventuele wijzigingen.

Synchronisatie
Nu moet ik de applicatie uitbreiden met een web kant waarop bestellingen geplaatst kunnen worden. Echter vraag ik me nu af wat de beste manier is voor communicatie/synchronisatie en versie beheer.

Zelf hadden we gedacht aan een website welke is aangesloten op een MSSQL server, deze is vervolgens verbonden met een Webservice waar de gegevens van af te lezen zijn, echter kunnen gebruikers aangemaakt worden vanaf de Access applicatie dus kunnen deze ook via de webservice worden ingevoerd.

Op de client klant (waar ook de Access applicatie staat) willen zouden we eventueel een client applicatie kunnen installeren, welke een notify krijgt (dmv observer patroon) als er een bestelling geplaatst is.

Zover we nu hadden gekeken zouden deze bestellingen dan in een tussen database komen, waarbij de Access applicatie het dan kan uitlezen en verwerken. Ook kan de Access applicatie gebruikers die zijn aangemaakt in deze database plaatsen zodat deze ook weer door de client verzonden worden.

Hiermee wordt voorkomen dat mocht het internet er uit vallen alle gebruikers toch gesynchroniseerd worden als de verbinding wel beschikbaar is.

Versie beheer
Daarnaast zaten we er mee hoe kunnen we versies goed onderhouden, dat als je een nieuwe versie beschikbaar maakt, met database veranderingen, hoe kan je dan zorgen dat de gegevens altijd weg geschreven kunnen worden.

Daarbij hadden we gedacht om voor elk bedrijf 1 database aan te maken met deze op de versie zoals zijn client applicatie werkt. Wanneer de client upgrade, wordt d.m.v. hibernate de gehele database geconvert naar de nieuwe versie.

Samengevat

Client
- 1 Acces database
- +1 Access applicaties
- 1 Tussen database
- 1 Client listener

Server
- 1 Webservice per versie
- 1+ Database (1 per bedrijf)
- 1 Website per versie

De vraag
Echter zijn we benieuwd naar andere ideen, want we brainstormen hier met verschillende medewerkers over maar alles heeft voor en nadelen en hebben we nog niet echt een manier gevonden waarop dit goed kan gebeuren?

Acties:
  • 0 Henk 'm!

  • Boss
  • Registratie: September 1999
  • Laatst online: 10:56

Boss

+1 Overgewaardeerd

Waarom zet je op de client niet ook alles over naar MS SQL (Express)? Als je vervolgens via ODBC weer de koppelingen maakt met de tabellen hoef je aan de clientapplicatie bijna niets te wijzigen. Dan kan je daarna een webservice maken die de data uit MS SQL kan lezen / schrijven.

The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it is an aesthetic experience much like composing poetry or music.


Acties:
  • 0 Henk 'm!

  • Hydra
  • Registratie: September 2000
  • Laatst online: 21-08 17:09
Access kan inderdaad in princiepe prima via ODBC naar de MS SQL tables refereren. Dus in plaats van een locale Access DB gebruik je alleen de 'remote' tables. Dan kun je gewoon de Access forms als UI blijven gebruiken.

https://niels.nu


Acties:
  • 0 Henk 'm!

  • Boss
  • Registratie: September 1999
  • Laatst online: 10:56

Boss

+1 Overgewaardeerd

Mocht je Access niet kunnen / willen overzetten naar SQL Server: ik heb vorig jaar ergens een synchronisatiemechanisme gemaakt waarbij SQL Server eerst alle data uit Access importeert, vervolgens lokaal een synchronisatie uitvoert en de updates (update/insert/delete) doorgeeft aan een remote server. Dat kan natuurlijk ook weer andersom, de bijgewerkte data terugpompen naar Access.

Maar als het even kan zou ik (in deze situatie) Access vervangen door SQL Server.

The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it is an aesthetic experience much like composing poetry or music.


Acties:
  • 0 Henk 'm!

  • Josvds
  • Registratie: November 2004
  • Laatst online: 26-08 20:42
Nou inderdaad op de server van de klant willen ze eventueel de access database gaan vervangen door een verwijzings access naar SQL. Echter lost dat nog niet alle synchronisatie problemen op binnen de applicatie want op beide locaties werk je met relaties die verbonden zijn aan het ID. Wanneer je dus op beide lokaties ID`s genereerd dan komt dit later niet overeen.

Hoe lossen andere dit normaal op?

Acties:
  • 0 Henk 'm!

  • Boss
  • Registratie: September 1999
  • Laatst online: 10:56

Boss

+1 Overgewaardeerd

Kan op verschillende manieren. Je kan een centrale generator gebruiken voor het uitgeven van ID's. Andere mogelijkheid is om replicatie/synchronisatie op te zetten tussen verschillende servers. Of je kan de ID's als een GUID laten genereren. Of je kan voor verschillende servers verschillende 'start'-nummers opgeven (1xxxxxxxx en 2xxxxxxxx).

Er zijn een hoop mogelijkheden. Je moet in ieder geval het idee uit je hoofd zetten dat ID's in deze situatie een netjes opeenvolgende reeks van getallen zijn :-)

Makkelijkste is misschien om gewoon eens wat te 'spelen' met de replicatie/synchronisatie van SQL Server.

The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it is an aesthetic experience much like composing poetry or music.


Acties:
  • 0 Henk 'm!

  • arnob
  • Registratie: Juli 2000
  • Niet online
Josvds schreef op dinsdag 23 maart 2010 @ 10:22:
<snip>
op beide locaties werk je met relaties die verbonden zijn aan het ID. Wanneer je dus op beide lokaties ID`s genereerd dan komt dit later niet overeen.

Hoe lossen andere dit normaal op?
indien de ID een autonummer (identity) veld is kan je een offset instellen. Let wel op het data type voor het mogelijk maximum aan id's. En een job schedulen die controleerd of je niet richting het maximum van de range komt.
Een nettere manier is de primairy key uitbreiden met een lokatie veld oid maar dan zit je wel aan aanpassingen in je code. De lokatie code moet dan meegenomen worden in de where clausules.
Het gebruik van een GUID is niet altijd zo handig. Het voordeel van de index op de primairy key valt weg bij een normale GUID omdat de waardes niet opvolgend zijn. Er is vanaf SQL2008 (dacht ik) een oplopend GUID. Die kan evt wel gebruikt worden met index voordeel maar deze is een karakter veld van tig karakters...

edit:
oeps, verkeerd gelezen. Je zit in de situatie dat op beide lokaties tegelijkertijd een klant oid aangemaakt wordt en acties gerelateerd worden en vervolgens wil je die laten mergen? Heb ik het zo goed begrepen?
dat gaat niet lukken met standaard replicatie en synchronisatie tools. Je primairy key is in de sync niet de primairy key maar de klantnaam is de PK. Daar moet je zelf een merge routine en conflict hantering voor maken.
Dat kan je in combinatie met het standaard replicatie mechanisme gebruiken maar je zal zelf alles dus moeten regelen. (conflict feedback/afhandeling?)

[ Voor 21% gewijzigd door arnob op 24-03-2010 16:05 ]


Acties:
  • 0 Henk 'm!

  • Josvds
  • Registratie: November 2004
  • Laatst online: 26-08 20:42
Hartelijk dank voor jullie reacties, omdat ik bij programmeren een andere vraag stond in dezelfde richting had ik daar mijn vraag ook geplaatst. Ik weet niet of iemand kan zorgen dat hierop dan een lock komt of mogen beide berichten door gaan?

[MSSQL] over internet: Direct, Replica of Webservice is het andere topic

Het gaat idd over twee verschillende locaties, heb daarbij gekeken naar verschillende opties:

- Rechtstreeks verbinding tussen Access en remote SQL
++ Dit vertraagd de verwerking van het aanmaken van een nieuwe gebruiker
++ Dit vertraagd het laden van bestellingen
++ Men heeft hierbij direct toegang tot de gehele database

- Rechtstreeks verbinding tussen Access en remote Web Service
++ De bestaande applicatie is erg uitgebreid, hierdoor wordt deze alleen maar groter men wil overstappen rustig aan naar .NET
++ Geeft echter wel weer externe bedrijven de mogelijkheid ook gebruik te maken van de applicatie

- Verbinding tussen SQL Express lokaal en SQL Standaard remote
++ Tot hoe ver werkt de replicatie van SQL goed?
++ Hoe lossen ze conflicten op?
++ Wat als een van beide offline raakt, hoe synchroniseren die dan later?

- Verbinding d.m.v. .NET Client applicatie (zelf ontwikkelen) en remote SQL
++ Er moet hierbij een client worden geschreven, extra onderhoud
++ Ook hierbij is de SQL server extern benaderbaar en volledig bereikbaar
++ Data moet ergens verwerkt worden, ook gesynchroniseerd

- Verbinding d.m.v. .NET Client applicatie (zelf ontwikkelen) en remote Web Service
++ Er moet hierbij een client worden geschreven, extra onderhoud
++ Er moet ook een webservice ontwikkeld worden, extra onderhoud
++ Data moet ergens verwerkt worden, ook gesynchroniseerd
++ Geeft echter wel weer externe bedrijven de mogelijkheid ook gebruik te maken van de applicatie

- Iets nieuws gevonden net ASO.NET Sync Services
++ Hoe gaat dit om met conflicten?
++ Hoe gaat dit om met offline?
++ Etc.

Daarnaast de keuze voor:
- Directe verwerking op de server
- Gebruik maken van tussen database voor synchroonisatie
- Gebruik maken van een replica database lokaal

Echter heeft alles voor en nadelen, denkend aan wachttijd bij inladen van bestellingen, conflicten bij dubbelzijdige aanpassingen, nieuwe records met ID`s, updates, installatie, versie verschillen, etc.
Wat kan ik het beste gebruiken? Zijn er nog andere technieken?

Bedankt.
Pagina: 1