Office Forum
www.Office-Loesung.de
Access :: Excel :: Outlook :: PowerPoint :: Word :: Office :: Wieder Online ---> provisorisches Office Forum <-
Erfahrungsaustausch: Access und SharePoint
zurück: Grundlagen Datenbankeinbindung weiter: Anzeigen Anzahl Datensätze im Bericht Unbeantwortete Beiträge anzeigen
Neues Thema eröffnen   Neue Antwort erstellen     Status: Information Facebook-Likes Diese Seite Freunden empfehlen
Zu Browser-Favoriten hinzufügen
Autor Nachricht
gNNY
Access-Noob


Verfasst am:
15. Mai 2012, 11:18
Rufname: Andreas

Erfahrungsaustausch: Access und SharePoint - Erfahrungsaustausch: Access und SharePoint

Nach oben
       Version: Office 2010

Hallo,

bei meinen Bemühungen, das Backend meiner Datenbank auf SharePoint umzustellen, habe ich festgestellt, dass das Unterfangen nicht gerade trivial ist. Die Diskussionen, die sich hier um das Thema drehen, gehen oft nicht sehr in die Tiefe, meist wird zu einer Kombination zu einem waschechten SQL-Server nebst PHP oder ähnlicher Skriptsprache geraten.

Aber manchmal kann man sich seine Werkzeuge nicht aussuchen. Daher möchte ich an dieser Stelle einen Ort schaffen, an dem sich Interessierte in gebündelter Form über dieses doch recht spezielle Thema austauschen können.

Meine Datenbank
Und damit steig ich auch gleich mal ein: meine Datenbank basiert auf Access 2010 und ist in ein Frontend und ein Backend gesplittet. Bisher liegt das Backend auf einem Netzlaufwerk, was für die Kollegen im eigenen Haus auch ok ist, aber für Auswärtige ist die Geschwindigkeit untragbar. Daher spiele ich nun mit den Möglichkeiten, die mit SharePoint gegeben sind - oder eben nicht.

Vorbereitungen
Wenn man ein funktionierendes Backend auf SharePoint hebt, fällt einem u.U. auf, dass Access "Designfehler" verzeiht, die SharePoint nicht hinnimmt. So habe ich dummerweise einen Default-Wert von "0" für ein auf Autowert gesetztes ID-Feld vergeben. Dies funktionierte ok, ergab aber bei der Umstellung auf SharePoint Fehlermeldungen. Daher musste ich vorher den Default-Wert wieder löschen und die bereits gemachten Einträge aus den Tabellen nehmen, bevor das Hochladen klappte.

Über "File > Save & Publish > Run Compatibility Checker" kann man eine Prüfung der Datenbank anstoßen und sich somit schnell die bestehenden Problemfelder anzeigen lassen.

Da ihr sicherlich von vornherein solche Fehler nicht macht, wird das bei euch vielleicht nicht auftauchen, aber als Hinweis, dass man eventuell in Fehler tappen kann, die einem "auf dem Desktop" nicht auffallen, ist dies allemal gut genug.

Versuch 1: Export nach SharePoint
Mein erster Versuch, das Backend auf SharePoint zu transferieren, habe ich über "Database Tools > SharePoint" unternommen. Der Menüpunkt liegt direkt neben dem "Teile eine Datenbank in Front- und Backend"-Button. Und da dieser mir bereits gute Dienste geleistet hatte, war ich zuversichtlich, dass es auch hier klappen würde. Leider war dem nicht so. Nachdem die oben genannten Probleme behoben wurden, klappte zwar der Upload in SharePoint. Dort konnte ich dann auch die Tabellen sehen. Aber beim verlinken zum Frontend wurde klar, dass die Tabellen "zerschossen" waren: es wurden zusätzliche Spalten eingetragen und die verlinkten Beziehungen waren zerstört worden. Insgesamt habe ich damit keine lauffähige Lösung gefunden. Hat jemand anders bessere Erfahrungen gemacht?

Versuch 2: Publish to Access Services
Über einen Umweg bin ich dann doch noch zu einem lauffähigen Backend gekommen. Ich habe die Datenbank als Access Service auf SharePoint hochgeladen. Eigentlich ist dieser Punkt dazu gedacht, um eine Datenbank in eine Web-Datenbank umzuwandeln, allerdings hat dies die Einschränkung, dass man Web-Formulare benutzt haben muss und auch kein VBA nutzen kann. Beides also Dinge, die für mich den Export uninteressant machen, da ich stark auf VBA angewiesen bin.

Allerdings werden damit die Tabellen korrekt auf SharePoint abgelegt und somit bin ich eher durch Zufall zu einem funktionierenden Backend auf SharePoint gelangt. Nach dem Verlinken mit dem Frontend hatte ich eine funktionierende Datenbank, die Sharepoint als Backend nutzt.

Update-Problematik
Nun muss ich leider die Struktur des Backends ändern und laufe in Probleme: SharePoint bietet mir einen Link, mit dem ich die Datenbank ändern können soll. Herunter geladen wird eine .accdw-Datei, mit der ich die Datenbank wohl bearbeiten kann. Allerdings bin ich schnell an Grenzen gestoßen: Zwar kann ich neue Tabellen hinzufügen, jedoch kann ich nur schwer eine Tabelle erstellen, die per Lookup auf andere Tabellen verweist. Wenn ich versuche, diese Tabelle zu importieren, bekomme ich einen Fehler (ACCWeb107007). Auch ein manuelles Anlegen der Tabelle brachte keine Besserung, weil ich nicht in die Design-Ansicht wechseln kann. Über das eingeschränkte UI komme ich darüber hinaus beim Versuch, die Lookups manuell einzustellen, nicht an die bereits vorhandenen Tabellen ran.

Was bleibt ist dann wahrscheinlich ein umständlicher Import-Export-Workaround, den ich allerdings nicht getestet habe. Ich stelle mir das so vor, dass ich die ganzen Daten aus dem SharePoint lokal vorhalte, sie dann in eine leere Datenbank importiere, dort die Änderungen vornehme, die Datenbank auf dem SharePoint lösche und die neue, geänderte Datenbank neu hochlade. Das klingt zwar alles abenteuerlich und gefährlich, aber so könnte es vielleicht funktionieren.

Aufgeblähtes Frontend
Nachdem Frontend und Backend miteinander verheiratet waren, viel mir auf, dass das Frontend um fast das achtfache angewachsen war. Statt knapp 5 Mbyte waren es nun fast 40 Mbyte, die das Frontend auf die Waage brachte. Da mein Test allerdings auf meinen "Ich lad mal die komplette Datenbank inkl. VBA und Formularen"-Daten basierte, muss ich noch testen was passiert, wenn ich allein das Backend hochlade. Eventuell wird das Endergebnis dann doch kleiner.

Soweit also meine Erfahrungen und Probleme. Ich würde mich freuen, wenn ihr euch mit euren Erfahrungen oder Fragen an der Diskussion beteiligen würdet.

Gruß,
Andreas
gNNY
Access-Noob


Verfasst am:
16. Mai 2012, 08:59
Rufname: Andreas


Web-Kompatibilität - Web-Kompatibilität

Nach oben
       Version: Office 2010

Gerade lädt meine Datenbank zum SharePoint hoch. Aber vorher musste ich einige Probleme beheben, die Access bisher sang- und klanglos geschluckt hat:
  • falsche Default-Werte bei einigen Lookups wurde von mir oder Access (kann es nicht mehr genau sagen) '0' als Default-Wert eingetragen. Verlinkt wurde auf einen Autowert, der nie '0' sein wird, daher der Fehler
  • ungültige Werte durch die falschen Default-Werte waren einige Datensätze bereits "verunreinigt", die nicht erlaubten Werte mussten entfernt werden
  • fehlende Beziehungen in der Ansicht der Tabellenbeziehungen fehlten einige Verknüpfungen, die ich in der "Relationship"-Ansicht nachziehen musste
  • nicht unterstütze Zahlenformate für einige Währungsfelder waren Zahlenformate eingetragen, die nicht unterstützt wurde.
Der Kompatibilitäts-Check generiert bei Fehlern eine Tabelle mit allen Problemen. Jedes Problem beschreibt die Tabelle und das Feld, in der etwas unkorrekt ist und bietet neben Beschreibungen noch einen Link auf eine Liste von Problembeschreibungen auf der Webseite von Microsoft. Jedoch sind die Hilfestellungen dort manchmal etwas zu allgemein gehalten, so dass ich bei einigen Fällen etwas gebraucht habe, um auf die richtige Spur zu gelangen.

Das Hochladen hat bei meinem knapp 8,5 Mbyte großem Backend ca. 25 min gedauert, am längsten hat die Synchronisation der Daten gebraucht.
gNNY
Access-Noob


Verfasst am:
21. Mai 2012, 15:15
Rufname: Andreas

Operation am offenen Herzen - Operation am offenen Herzen

Nach oben
       Version: Office 2010

Seit heute ist die Datenbank im Betabetrieb. Das Frontend rolle ich über den "Packaging Solution Wizard" aus.

Beim Testen des Backends ist mir aufgefallen, dass ein Offline-Zugriff möglich ist. Mir war das nicht klar. Das Frontend versucht beim Start sich mit SharePoint zu verbinden. Gelingt dies nicht, kann man trotzdem auf alle Daten zugreifen. Ist die Verbindung wieder hergestellt, popt ein Warnhinweis auf mit der Möglichkeit, die Daten zu synchronisieren. Gibt es dabei Konflikte, werden diese mit einen Dialog angezeigt.

Die Offline-Nutzung ist auch der Grund, weshalb der Client plötzlich um ein Vielfaches angewachsen ist (s. o.). Die Daten müssen ja schließlich irgendwo vorgehalten sein... Smile

Offline-Nutzung hat also seine Licht- und Schattenseiten. Hier mal ein paar Schatten:
  • Negative IDs: im Offline-Betrieb werden neue Datensätze mit Autonum-IDs mit negativen Werten belegt. Beim Synchronisieren werden diese in die nächst-freien positiven Werte geändert. Allerdings ist mir noch nicht klar, ob dies auch für die Verknüpfungen gilt, die ich per VBA erstelle.
  • "Was nun?" Bisher weiß ich noch nicht, wie ich den Sync-Dialog programmatisch abfangen kann, denn zur Zeit werden die Benutzer noch ins kalte Wasser geschmissen, wenn so etwas passiert. Ich hätte es lieber, dass ich den Hinweis selber abfangen und "anmoderieren" kann, damit der Benutzer weiß, was da passiert
  • Alles grau: zum Synchronisieren müssen alle Objekte geschlossen werden, was ja ok ist. Nur leider wird das Startformular anschließend nicht noch einmal aufgerufen. Es kommt auch ein "Fertig"-Hinweis. Stattdessen starrt der Nutzer auf ein graues, leeres Fenster. Nach einem Neustart ist wieder alles gut, das muss man aber erst wissen
Insgesamt halte ich die Offline-Fähigkeit für eine gute Sache, weil es die Einsatzmöglichkeit erweitert. Allerdings wünsche ich mir etwas mehr Kontrolle über den ganzen Prozess.

Hat jemand von euch damit schon Erfahrungen gemacht? Kann man z.B. diese Synchronisationsmeldung irgendwie abgreifen und darauf reagieren?
gNNY
Access-Noob


Verfasst am:
22. Mai 2012, 11:04
Rufname: Andreas

Hybrid! - Hybrid!

Nach oben
       Version: Office 2010

Auf einer Microsoft-Seite habe ich ein sehr informatives Video zum Thema "Access und SharePoint" gefunden. Und dabei hab ich auch gleich gelernt, dass ich hier im Grunde eine Hybrid-Anwendung gebaut hab. Ohne vorher genau zu wissen, was das eigentlich ist. Und damit bin ich plötzlich beim dem "ganz heißen Sch***" gelandet Smile Denn das scheint grad für meine Zwecke eine recht neue aber dafür sehr praktikable Methode zu sein, um Access-Anwendungen zu bauen.

Das Video hat mir noch ein paar weitere Ideen gegeben, die ich als nächstes versuche umzusetzen. Dafür muss ich zwar den Split zwischen Front- und Backend aufgeben, was noch ein wenig Anstrengung mit sich bringt. Aber das zu erwartene Resultat ist es auf jedenfall Wert.
gNNY
Access-Noob


Verfasst am:
12. Jun 2012, 11:03
Rufname: Andreas

erste Praxiserfahrungen - erste Praxiserfahrungen

Nach oben
       Version: Office 2010

und weiter geht es in meinem Monolog Smile

Mittlerweile ist das Projekt seit einer Woche offiziell ausgerollt. Es musste plötzlich sehr schnell gehen, weil in dem bis dahin genutzten System ein Bug drin war, der eine wichtige Funktion beeinflusste. Da ein Fix für das alte System nicht mehr rentabel war, musste der roll-out des neuen System etwas vorgezogen werden.

Was mir dabei schon mal aufgefallen ist:
  • Inserts gehen nicht mehr so einfach: wenn neue Produkte hinzugefügt werden, wird auch ein Update von angehangenen Tabellen durchgeführt. Dabei geht das tool durch die Schlüssel einer Hilfstabelle und aktualisiert eine Kreuztabelle. Bisher konnte ich mir die Schlüssel mit einem einfachen SELECT holen und dann durch das RecordSet gehen. Problem bei einer Hybrid-Anwendung: wenn die Tabelle zuvor noch nicht genutzt wurde, stehen nicht alle Datensätze zur Verfügung und das Skript läuft nicht durch alle Schlüssel. Als Lösung bot sich ein vorangestelltes "rs.MoveLast", "rs.MoveFirst" an. Jetzt scheint alles zu gehen
  • 0-Wert in Autowert-Spalten: durch schlampigen Code habe ich 0 als Wert für einen Fremdschlüssel eingetragen, der sich aus einer Autowert-Spalte (die ja nicht 0 wird) speist. Wenn also ein Wert nicht bekannt war, habe ich einfach 0 genommen, um wenigstens irgend etwas einzutragen. Das ging im "tranditionellen" Access noch gut, SharePoint verzeiht dies aber nicht. Leider kommt eine sehr ominöse Fehlermeldung "Data cannot be inserted because there is no matching record." Es hat etwas gebraucht, bis ich verstanden habe, was mir das System damit sagen wollte. Ein "if tempID > 0 then rs!ProductID_f = tempID" hat für Abhilfe gesorgt
  • Update-Paradies: neue Versionen auszurollen ist nun sehr einfach geworden. Ich baue lediglich meine Datenbank um, synchronisiere hoch und schon haben meine Nutzer die neue Version. So einfach war es bei meinem alten Frontend/Backend-System nicht.
  • Update-Leid: allerdings habe ich noch nicht so recht für mich entschieden, wie ich das Produktiv- und das Entwicklersystem handhaben will. Im Prinzip scheint es keinen Unterschied mehr zu geben, weil bei jedem Start des Systems ein Synch mit SharePoint vorgenommen wird. Zumindest werden die Inhalte von SharePoint runter synchronisiert, die Änderungen an meinem lokalen System nur, wenn ich auf "Sync" klicke. Allerdings habe ich gestern eine Version mit kleinen Änderungen dadurch verloren, indem sie von der Version auf SharePoint überschrieben wurden. Wahrscheinlich muss ich einfach eine separate Kopie vorhalten, die ich für Entwicklungen nutze. Aber einen richtigen Arbeitsmodus habe ich noch nicht gefunden, weil die Grenzen zwischen Produktiv- und Entwicklerversion so schwammig sind.
  • Bugs und Seltsamkeiten: es gab (oder gibt?) den Fall, dass das Tool beim Beenden Access zum Absturz bringt ("Access has stopped working..."). Angeblich muss man auf eine aktuelle Version der VBE7.dll umsteigen, Version 7.0.16.25 ist wohl der Heilsbringer. Aber so recht zu Ende getestet habe ich das noch nicht mit allen Benutzern. Auch gibt es einen seltsamen Fehler, bei dem Tabelleninhalte, genauer Zahlenwerte, komplett falsch auf den Rechner synchronisiert werden. Statt "1" steht dann dort vielleicht "100.000.000.000" o.ä. und sorgt dann für einen Overflow Error, da ich eigentlich Integers erwarte und dort auch nichts anderes als Integers erscheinen sollten. Auch hier steht eine genaue Analyse des Problems noch aus.
  • Offline-Ungewissheit: eigentlich kann das System auch Offline funktionieren. Voraussetzung ist allerdings, dass alle Tabellen einmal lokal herunter synchronisiert wurden. Das geschieht entweder durch fleißige Nutzung oder per Skript. Letzteres habe ich noch nicht implementiert. Um zu verhindern, dass meine Nutzer das Tool ohne Netz benutzen, habe ich an zentraler Stelle ein Skript eingebaut, welches die Datenbank beendet, sollte keine Verbindung mehr bestehen. Das ist leider etwas holzhammer-artig, aber besser als ein kaputtes System oder unzufriedene und verwirrte Nutzer. Für die Zukunft bau ich vielleicht noch eine Offline-Funktion ein. Die will aber ausgiebig getestet sein.
Soweit also der aktuelle Stand. Auch wenn die Fehler und Probleme vielseitig zu sein scheinen, bin ich dennoch mit dem System ansich sehr zufrieden. Ich habe Nutzer, die in Europa verteilt sind und davon berichten, dass die Datenbank in ihren lokalen Büros, bei ihnen zu Hause via VPN und sogar vom Flughafen aus via Smartphone Tethering flüssig läuft. Auch klappen Updates, soweit ich das beurteilen kann, gut. Jetzt konzentriere ich mich auf das Ausbügeln von kleinen Fehlern und beobachte die Performance weiter.

Was mir noch ein wenig fehlt ist eine Anlaufstelle, bei der ich genau über solche Hybrid-Datenbanken diskutieren kann. Ich weiß natürlich, dass dies eine sehr spitze Zielgruppe ist, aber ein wenig Austausch unter Leidensgenossen wäre schon schön Smile Hat jemand vielleicht noch einen Tipp, wo man sich über solche Anwendungen austauschen kann?
Nachtrag: gNNY am 12. Jun 2012 um 14:48 hat folgendes geschrieben:
gerade hatte ich einen Anruf von einem Nutzer. Ihm war ein Feld bzw. dessen Bezeichnung unklar. Ich hab ihm erklärt, was es eigentlich meint und er hat einen Vorschlag gemacht, wie es besser benannt werden könnte. Daraufhin habe ich die Änderung vorgenommen, er hat seine Version des Tools geschlossen und erneut geöffnet und hatte sofort die neue Bezeichnung. Ich sitze in Deutschland, er in der Schweiz. Das Leben kann so einfach sein Smile
gNNY
Access-Noob


Verfasst am:
15. Jun 2012, 19:08
Rufname: Andreas


Diskussion - Diskussion

Nach oben
       Version: Office 2010

In einem anderen Zusammenhang hat sich Bitsqueezer ein paar Gedanken zu dem Hybrid-Ansatz gemacht und ein paar Bedenken zusammen getragen. Meine Antwort möchte ich auch gerne hier einfügen, da ich Bitsqueezers Bedenken für sehr valide halte und glaube, dass sie auch von anderen (inkl. z.T. von mir ;) ) geteilt werden:

Bitsqueezer - 15. Jun 2012, 17:17 hat folgendes geschrieben:
Anpassung von Tabellenstrukturen durch irgendwelche Automatismen von Sharepoint - halte ich für indiskutabel. Wenn ich eine Datenbank designe, will ich nicht, daß irgendwelche Tools daran herumfummeln.
Meinst du damit den Bug, den ich bei einigen Bentutzern beobachtet habe, dass Zahlen falsch dargestellt werden und ich deshalb von einem Zahlen- auf ein Textfeld umstellen musste? Ja, das ist echt seltsam und wirkt nicht sehr vertrauenswürdig. Woran es liegt, kann ich auch noch nicht sagen, denn es taucht nur bei einigen Benutzern auf, während es bei den meisten korrekt funktioniert. Und da ich nur sehr wenig reine Zahlenfelder hatte, konnte ich einfach auf Textfelder umstellen. Wenn man keine Zahlenfelder nutzt, fällt es einem vielleicht auch garnicht auf.

Zitat:
Sicherheit: Du schreibst nur, daß die kompletten Daten offline synchronisiert werden, wenn die Seite also nicht mindestens per https aufgerufen wird, gehen alle Firmendaten mal eben ungesichert über das Internet...(auch beim Upload...)
Ich gehe per https an die Daten ran. Da der SharePoint-Server im Intranet beheimatet ist, kommt zusätzlich noch eine VPN-Leitung zum Einsatz.

Zitat:
Sicherheit II: Access hat seit A2007 keine lokale Benutzersicherheit mehr, es ist also nicht möglich, die Daten, die man nun komplett offline hat, vor unbefugtem Zugriff zu schützen, lediglich über ein Datenbankkennwort.
Das ist aber dann doch ein generelles Problem von A2007 und aufwärts, wenn ich das richtig verstanden habe. Ich bin ja kein Experte, weshalb ich nicht weiß, was mit der Benutzersicherheit früher möglich war. Für meine Datenbank habe ich mir ein einfaches Benutzersystem gebaut, um die Datensichten zu kontrollieren. Zugang zum SharePoint haben nur explizit die Nutzer, die ich auch eingetragen habe. Insofern ist es schon recht gut, da ich per ActiveDirectory direkt eine Nutzerverwaltung habe, über die ich steuern kann, wer generell Zugang zur Datenbank hat. Aber innerhalb des Tools muss ich mir selbst was einfallen lassen. Das muss ich aber generell, wenn ich A2007 und neuer einsetze, wenn ich das recht verstanden habe.

Zitat:
Unterschiedliche Frontends: Wenn Du eine neue Version des Frontends hochlädtst, das auch gleich Tabellenstrukturen ändert, tiltest Du u.U. laufende Frontends. Hier gehört mindestens eine Zwischenschicht in Form von Abfragen zwischen Frontend und Backend, so daß Änderungen am Backend die Abfragen nicht beeinflussen.
Bei dem Punkt bin ich mir auch noch nicht ganz sicher, wie sich das in Zukunft ausnimmt. Aber ich sehe das zunächst nicht als allzu großes Problem.

Beim Start wird die lokale Kopie mit der Serverkopie synchronisiert. Während die lokale Kopie dann offen ist, wird sie nicht aktualisiert, es kann also auch nichts blockieren.

Wenn es nun in einem Update nur kosmetische Änderungen gibt, es z.B. im UI Umbenennungen gibt, ist das nicht weiter schlimm, weil es keine wichtigen Teile der Funktion betrifft.

Wenn neue Funktionen (z.B. neue Formulare) eingefügt werden, ist es auch nicht weiter schlimm. Die Nutzer arbeiten mit der alten Version normal weiter, wenn sie auf die neuen Funktionen zugreifen wollen, müssen sie nur kurz neu starten.

Spannend wird es, wenn bugs gefixt werden sollen, die in der alten Version für korrupte Daten gesorgt hat. Hier muss man dann "irgendwie" den Nutzern Bescheid geben. Email, Rundgang, Telefonat wären ja die Klassiker, schicker geht es über "Bitte starten Sie neu!"-Funktionen in der Datenbank selbst.

Diese Update-Problematik hat man allerdings wahrscheinlich immer, wenn man mit Front- und Backend arbeitet. Früher musste ich das alte Frontend per Flag (bzw. Versionsnummer) deaktivieren und die Nutzer per Email bzw. interner Verlinkung auf den Updateordner dazu bringen, sich das Update zu holen. Im Zweifel hat es sie bei ihrer eigentlichen Arbeit ausgebremst. Mal eben schnell etwas nachschauen, ging dann für sie nicht, weil sie sich erst das Update besorgen mussten. Jetzt bekommen sie beim Start ganz automatisch die neue Version auf den Rechner geschoben, ohne dass sie es im Zweifel überhaupt merken.

Zitat:
Kosten: Man benötigt, wenn man Sharepoint selbst betreiben will, mindestens einen W2003-Server und einen Sharepoint-Server sowie einen SQL Server, die alle nicht unerheblich Lizenzen kosten. Ein Hosting bei einem Internetprovider wäre mir zu gefährlich: Firmendaten liegen hier auf fremdem Equipment, über dessen Sicherheit man nichts weiß und auch nicht über die Verwendung der Daten. Ebenso kann der Provider ohne Weiteres mal eben einen Update von SQL Server oder Sharepoint vornehmen, der Deine Anwendung von einem auf den anderen Tag unbrauchbar macht, womit die Mitarbeiter nun erst weiterarbeiten können, wenn das Frontend angepaßt wurde. Firmendaten bei Fremdprovidern - für mich indiskutabel. Das kann man mit seiner privaten Homepage machen, wo es niemanden interessiert, wenn die ausfällt. Ein Service-Provider kann auch mal eben in die Insolvenz gehen und dann hat man ähnliche Probleme.
Ja, das stimmt, einen Provider braucht man und der wird seine Dienste auch nicht für Lau anbieten. Aber das ist dann ein generelles Kosten-Nutzen-Szenario: leiste ich mir einen Server nebst Lizenzen, VPN, schneller Upload-Leitung, Adminstratoren, etc, um Herr über meine Daten und der Konfiguration zu sein, oder greife ich auf einen Hoster zurück, der mir das alles im Paket anbietet? SharePoint-Hoster gibt es ja, und das auch von etablierten Anbietern. Wie sie in Kombination mit Access funktionieren, kann ich natürlich nicht sagen, da muss man sich mal umschauen und informieren. Aber für ein kleines oder mittelständiges Unternehmen kann dies eine interessante Möglichkeit sein, wie man einen verteilten Zugriff auf eine Datenbank ermögicht. Denn wenn der Zugriff auch von außerhalb möglich gemacht werden soll, wird es eh teuer, weil man dann entweder mindestens in VPNs und Firewalls (nebst Administratoren) investiert oder eben in einen Hoster. Hat alles seine Vor- und Nachteile, die jeder für sich durch gehen sollte. Insofern sind deine Bedenken da genau richtig und sollten wohl bedacht sein.

Noch ein Wort zum Mehrbenutzerbetrieb, der mir grad eingefallen ist. Vorher habe ich ein "klassisches" Front-/Backendsystem genutzt, um verschiedene Teams anzubinden. Da ich kein vernünftiges Backend hatte, war der Zugriff natürlich inakzeptabel, als Teams aus anderen Standorten dazu kamen. Die Hybridanwendung ist nun nicht mehr in Front- und Backend aufgeteilt, sondern nur noch eine Datei, die ich quasi aufgesetzt hab, als würde ich sie nur für mich nutzen. Über die Veröffentlichung auf SharePoint wird die ganze Verwaltung im Mehrbenutzerbetrieb im Hintergrund automatisch erledigt, ich brauch mich nicht darum zu kümmern. Und das ist schon ziemlich nett.

Mich hat der Hybrid-Ansatz sehr fasziniert, weil er es mir ermöglicht, meine Datenbank zu betreiben, ohne SQL-Server-Admin zu sein. Zugriff zu einem Server hätte ich im Unternehmen wohl auch nicht bekommen, eine SharePoint-Site kann ich hingegen mit wenigen Clicks selbst einrichten. Ohne diese Lösung wäre das Projekt gestorben.

Allerdings steh ich ja auch erst selbst am Anfang: die Datenbank in ihrer jetzigen Form läuft nun seit knapp 2 Wochen und bereits jetzt habe ich ein paar interessante Erfahrungen machen dürfen Smile Vielleicht werde ich am Ende doch auf ein anderes System umschwenken müssen, weil irgend etwas nicht klappt, von daher gebe ich dir recht, dass man sich hier mit einer Technologie beschäftigt, die noch nicht so weit verbreitet ist. Hilfe findet sich zu Weilen etwas schwierig. Aber ich hab gemerkt, dass es trotzdem geht und man am Ende ein ziemlich cooles Tool zur Verfügung hat.
Neues Thema eröffnen   Neue Antwort erstellen Alle Zeiten sind
GMT + 1 Stunde

Diese Seite Freunden empfehlen

Seite 1 von 1
Gehe zu:  
Du kannst Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum nicht posten
Du kannst Dateien in diesem Forum herunterladen

Verwandte Themen
Forum / Themen   Antworten   Autor   Aufrufe   Letzter Beitrag 
Keine neuen Beiträge Microsoft Access und andere Datenbank-Server: Access Datenbank von SharePoint trennen 0 Steffi146 903 07. Nov 2012, 09:57
Steffi146 Access Datenbank von SharePoint trennen
Keine neuen Beiträge Microsoft Access und MS SQL Server: Access Berichte und Sharepoint 0 galnar 483 16. Aug 2012, 17:55
galnar Access Berichte und Sharepoint
Keine neuen Beiträge Microsoft Access und andere Datenbank-Server: Sharepoint Services --> Zugriff übers Internet 5 Vampir2000Le 12715 25. März 2010, 11:59
SusiHeinz Sharepoint Services --> Zugriff übers Internet
Keine neuen Beiträge Microsoft Access und MS SQL Server: *.mdb <-> MS SQL mit dem SharePoint synchronisieren 0 Tobi88 2247 16. Dez 2008, 09:12
Tobi88 *.mdb <-> MS SQL mit dem SharePoint synchronisieren
Keine neuen Beiträge Microsoft Access und andere Datenbank-Server: Sharepoint Kalendar anpassung 0 coreT 1610 14. Sep 2007, 10:21
coreT Sharepoint Kalendar anpassung
Keine neuen Beiträge Microsoft Access und andere Datenbank-Server: Daten aus Sharepoint Server 2003 in Visio exportieren 0 Gast 2442 19. Sep 2005, 10:11
Gast Daten aus Sharepoint Server 2003 in Visio exportieren
Keine neuen Beiträge Microsoft Access und andere Datenbank-Server: Windows Sharepoint services 0 Thom 1616 13. Jul 2005, 16:28
Thom Windows Sharepoint services
 

----> Diese Seite Freunden empfehlen <------ Impressum - Besuchen Sie auch: JavaScript