Access <-> SharePoint

[FrankiLi]

Hallo zusammen,

tolles Forum hier, ich habe schon schnelle und kompetente Hilfe zu ein paar Fragen bekommen, vielen Dank.

Ich beschäftige mich im Moment sehr mit dem Zusammenspiel Access (2016) und SharePoint online.

An SharePoint mag ich die Usability und die Tatsache, dass es bei uns schon ganz gut eingeführt ist, plus die Verwaltung von Berechtigungen usw, insbesondere in der Projektarbeit ist hier mit "Listen" eine super Zusammenarbeit möglich. Mit Access hatte hier noch niemand etwas zu tun, weswegen ich das auch nicht als Frontend einsetzen will, soweit möglich.

Nun gibt es aber Dinge, die sind in Access super umsetzbar, aber nicht 1:1 auf SharePoint übertragbar. Und vice versa. Und es gibt ja mehrere Wege, die beiden Systeme zu verbinden, über Verknüpfungen, als Access Web App, mit Anlage der Tabellen in Access führend, oder als Liste in SharePoint führend etc.pp. - ich habe schon x Sachverhalte getestet, irgendwas ist immer..

Meine Frage:
Hat sich hier auch schon jemand intensiver mit dem Thema beschäftigt und irgend eine Art Best Practices?

Gruss
Frank

[Josef P.]

Hallo!

Als Ergänzung zu deiner Aufzählung bezüglich Datenquelle:
Tabellen/Sichten aus einer SQL-Server-Datenbank (z. B. Azure-SQL) als externe Liste im SharePoint und als verknüpfte Tabelle im Access-Client nutzen. Damit hast du dann auf Datenbankseite viel mehr Möglichkeiten.

mfg
Josef

[FrankiLi]

Hallo Josef

Danke Dir.

Ich habe schon mal kurz über SQL nachgedacht, aber aus zu viel Respekt gleich wieder aufgehört.

Vielleicht zu Unrecht. Ich habe keine IT-Abteilung und bin mehr Organisierer, wenn auch sehr IT-lastig, aber ohne entsprechende Ausbildung. Sind das per se schlechte Voraussetzungen für die Konstellation oder lohnt es sich, doch mal gezielt sich damit zu beschäftigen?

Gruss Frank

[Josef P.]

Hallo!

Wenn du Interesse und Zeit hast, kann ein Reinschnuppern nicht schaden. ;-)
Die Basisfunktionalitäten sind nicht so schwierig zu verstehen - ist nicht viel anders als bei Access-Tabellen.

Die Frage ist eher, was du vom Zusammenspiel zw. Access und SharePoint erwartest bzw. welche Anforderungen du hast. Davon hängt es ab, ob der SQL-Server ein passendes Bindeglied sein kann.

mfg
Josef

[FrankiLi]

Hallo Josef,

Die Frage ist eher, was du vom Zusammenspiel zw. Access und SharePoint erwartest bzw. welche Anforderungen du hast. Davon hängt es ab, ob der SQL-Server ein passendes Bindeglied sein kann.

Das ist der Punkt.

Habe mir Azure SQL mal eingerichtet, das Connectieren per externer Liste von Sharepoint aus ist ja schon nicht ganz trivial, abgesehen davon, dass ich von SQL-Administration keine Ahnung habe - ich habe allerdings auch kein Problem, mich einzuarbeiten und darauf zu bauen, allerdings würde es schon einige Zeit und Know-How-Aufbau kosten, um überhaupt zu erfahren, ob das für mich/uns zielführend ist oder nicht, oder oversized, oder whatever.

Bei uns geht es um den Aufbau einer "kleinen" Produktdatenbank mit ca. 10.000 Grundartikeln und 200.000 Varianten (bestellbaren Artikeln), als Basis für die Fütterung der ERP (Schnittstelle per csv), die wiederum einen Webshop füttert.

An der Anreicherung der Artikeldaten sollen mehrere Personen beteiligt sind, einer weist Bilder zu, der nächste macht Preise, der andere Produktexte usw. - und genau dafür finde ich eben SharePoint ideal, quasi manuelles Doing mit "Kopf".

Andererseits gibt es dann die Massenänderungen: Mal eben alle Preise umrechnen nach verschiedenen Kriterien, typische Aktualisierungsabfragen-Aufgaben halt. Dazu Kreuztabellen etc., alles Themen, die ich Stand jetzt in Access hinkriege. Eventuell auch das Ausmultiplizeren von Varianten (Artikel hat 5 Variantendimensionen wie Farbe, mit jeweils bis zu 10 Werten wie weiß, erstelle daraus alle verfügbaren bestellbaren Artikel), was massiv Zeit sparen würde.

Und deshalb ist seit Tagen (und Nächten) mein Thema, die idealste Konstellation zu finden, wie ich die Vorteile der beiden Systeme kombinieren kann. Aber, wie gesagt, irgendwas ist immer.

Kannst Du anhand dieser Infos etwas besser einschätzen, ob sich das Unterfangen "SQL" hier lohnt?

Gruss
Frank

[PhilS]

Hat sich hier auch schon jemand intensiver mit dem Thema beschäftigt und irgend eine Art Best Practices?

Du solltest dir unbedingt die Folien zum Vortrag von Karl Donaubauer zu Sharepoint+Access von der letzten AEK anschauen.
-> donkarl.com/?aek und dann Downloads anklicken.

[FrankiLi]

Oh, vielen Dank! Ich bin bei meinen nächtlichen Recherchen da schon mal drauf gestoßen, habs aber in den 94 Tabs nicht mehr gefunden

Meintest Du jetzt ganz generell, oder spielst Du auf eine explizite Erkenntnis darin an?

[PhilS]

Meintest Du jetzt ganz generell, oder spielst Du auf eine explizite Erkenntnis darin an?

Eher generell, weil darin (aus meiner Sicht als Sharepoint-Laie) ein ziemlich umfassender Überblick geliefert wird.

[Josef P.]

Hallo!

Ich bin mir nicht sicher ob die SharePoint-Liste für die Menge der Datensätze geeignet ist.
Die 10k werden eher noch kein Problem sein. Bei 200k (falls die Varianten auch als Datensätze gespeichert werden) ist möglicherweise ein Umstieg auf einen DB-Server zu überlegen.
Eine externe Listen ist zwar am SharePoint etwas umständlich zu erstellen, aber mit passender Anleitung auch kein so großes Problem - und die findet man mit Google & Co.

Falls die 200k DS aber gar nicht im SharePoint bezüglich Datenwartung benötigt werden, kann ein Access-Client mit verknüpften SharePoint-Listen eine Lösung sein.
Datenänderungen über Aktualisierungsabfragen sind damit kein Problem.

Vielleicht ist auch eine Kombination denkbar: die Grundartikel im SharePoint, die restlichen Daten über den Access-Client gewartet.

Natülich ist auch die Bearbeitung der Grundartikel mit einem Access-Client möglich - vermutlich sogar komfortabler als im SharePoint, da sich die Eingabemasken etwas einfacher gestalten lassen. Wenn man im SharePoint von der Standarddarstellung abweichen will, wird es schnell aufwendig - zumindest im Vergleich zu einem Access-Formular.

Eine Access-Web-App ist meiner Meinung nach nur sinnvoll, wenn keine Client-Anwendung möglich ist. Ansonsten ist mit einem "normalen" Access-Client mehr machbar - vor allem, wenn man auch ein wenig VBA einsetzen will. Auch hier wäre eine Zweiteilung denkbar - die Web-App für die einfache Datenwartung und der "große Client" für die komplexeren Abläufe.

mfg
Josef

[FrankiLi]

Hallo Josef,

vielen Dank.

Wir sprechen von ca. 10.000 Grundartikeln und > 1 Mio bestellbaren Varianten. Ich habe mich schon an den Gedanken gewöhnt, für die einzelnen Aufgabenstellungen per Abfragen in Access einzelne SP-Listen zu erstellen, quasi nur temporär bis die Aufgabe erledigt ist - also SP nicht als generelles Frontend. Das mit den WebApps gefällt mir nicht: Hat ja mit SP nur bedingt zu tun, von der Usability her gar nicht, da kann ich dann auch gleich ein Access-Frontend einsetzen.

Aber nochmal zu SQL, und zwar unabhängig von den Vorteilen einer externen Liste:
Wann lohnt sich denn der Einsatz von SQL (Azure) tatsächlich als Alternative zu reinem Access? Wir haben wenige User-Zugriffe, das System ist nur zur Stammdatenpflege (ist also im Live-Betrieb nicht gefordert, das ist dann die ERP) und falls das von der Performance her ein grundsätzlicher Unterschied wäre, würde da doch (Azure/Cloud) eher die Internetleitung der Engpass sein.

Übersehe ich etwas, spricht etwas deutlich für den Datenbank-Aufbau per SQL statt Access? Und/oder ist es praktikabel, das Ganze in Access aufzubauen und ggf. später über den Migration Assistent (https://www.microsoft.com/germany/technet/news/show.aspx?id=msdn_de_55539) zur SQL-Datenbank "zu machen"?

Gruss
Frank

[Josef P.]

Hallo!

spricht etwas deutlich für den Datenbank-Aufbau per SQL statt Access?

Access ist nicht schlecht, aber aktive DBMS können mehr - das hilft aber nur, wenn man es nutzt.
Wenn du den SQL-Server verwendest, kannst du beispielsweise im laufenden Betrieb sichern. Es wird auch keinem User gelingen das Backend zu beschädigen.

Und/oder ist es praktikabel, das Ganze in Access aufzubauen und ggf. später über den Migration Assistent ...

Möglich ist das schon. Die Tabellenerstellung ist im SQL-Server Managementstudio aber auch nicht komplizierter.
Warum sollte es überhaupt ein Azure SQL und kein eigener installierter SQL-Server sein?

Wenn du dich mit einem Access-Backend wohler fühlst, spricht meiner Meinung nach mit den von dir beschriebenen Anforderungen (nur temporäre Datenhaltung) nichts dagegen.

mfg
Josef

[FrankiLi]

Wegen Azure:
Wir haben keinen brauchbaren Server und setzen komplett auf Office365, da dachte ich, macht doch auch Azure Sinn. Ist die Konstellation nicht prädestiniert für Azure?

[Josef P.]

Wir haben keinen brauchbaren Server und setzen komplett auf Office365

Wo würdest du ein Access-Backend ablegen?

Ist die Konstellation nicht prädestiniert für Azure?

Solange die Internetverbindung schnell genug ist und du den Server arbeiten lässt (Datenoperationen mit vielen Datensätzen nicht im Client durchführen), wird das kein Problem sein.

An deiner Stelle würde ich eine kleine Testanwendung bauen und ausprobiere, welche Variante am besten für dein Vorhaben geeignet ist.

mfg
Josef

[FrankiLi]

In dem Fall würde ich ja nur SP Listen als Frontend verwenden. Access-DB als Dokument in SP. Die Daten aus den Listen laufen dabei nicht direkt in die Tabellen, sondern werden in Access manuell eingespielt.

Ich muss dazu sagen, dass maximal 3-4 Leute an der Front arbeiten, und ein bis zwei Leute im Backend. dafür werden es wohl ein bis 2 Millionen Artikel

[FrankiLi]

Aktuell erhalte ich bei externen Listen (Azure-SQL) in Sharepoint die Meldung

Der Datenbankconnector hat die Antwort eingeschränkt. Die Antwort der Datenbank enthält mehr als 2000 Zeilen. Die maximale Anzahl von Zeilen, die durch den Datenbankconnector gelesen werden kann, beträgt 2000.

Dabei hatte ich die Listen ja eingerichtet, um nicht das Problem mit den max. 5000 bei internen Listen zu haben, jetzt habe ich es schon bei 2000.... was mache ich ggf. falsch?