none
Access-Web-App auf verknüpften Sharepointlisten erlaubt die Bearbeitung von Daten nicht und unterstützt Kombinationsfeld nicht

    Frage

  • Hallo liebe Forumleser!

    mein Arbeitsumfeld ist Office365 mit Sharepointonline und Access 2016 Desktopanwendung und beim Erstellen einer WebApp bin ich nun auf einige Probleme gestoßen. Folgendermaßen bin ich vorgegangen:

    Aus einer Access 2016 -Desktopdatenbank habe ich Tabellen nach Sharepoint auf meine Teamwebsite exportiert, so dass verknüpfte Sharepointlisten entstanden sind. Die Sharepointlisten wurden auch online korrekt erstellt. Nachschlagefelder in den Access - Tabellen sind in die Sharepointlisten übernommen worden und sind jetzt ebenfalls Nachschlagfelder in den SP-Listen. Allein die Id's in Access Auto-Werte wurden umbenannt in _OldID und es wurde ein neues Sharepointfeld aber mit derselben Bezeichnung erzeugt wie zuvor die Id in der Access-Desktoptabelle.

    Nun habe ich ein Webpart Access App erstellt auf der Teamwebsite und diese dann mit Access geöffnet. In diese habe ich die Sharepointlisten, die ja nun auf der Teamwebsite vorhanden waren wieder als Verknüpfung übernommen. Dies hat funktioniert, es wurden auch Listen u. Datenblattansichten erstellt in Access.

    Allerdings habe ich jetzt das Problem, wenn ich die App ausführe, dass die App zwar die Datenblatt und Listenansichten anzeigt, aber keine Bearbeitung der Datensätze zulässt und auch nicht das Zufügen neuer Datensätze, obwohl ich der Besitzer von allem bin das man überhaupt berechtigen kann. Es werden nur vorhandene Daten angezeigt.

    Weiteres Problem: wenn ich in Access lokal eine Ansicht der App bearbeite und ein Datenfeld austausche durch ein Kombinationsfeld, bei dem ich die Verknüpfungen zur Referenztabelle korrekt angebe, so kann ich bei Ausführen der App im Browser die ganze Ansicht nicht mehr anzeigen, sondern bekomme die Fehlermeldung:
    "Die Elemente die hier aufgelistet werden sollen konnten nicht abgerufen werden."

    Wenn ich mir im lokalen Access die eingebundenen Sharepointlisten in der Entwurfsansicht ansehe, so sind die in der Tabelle ehemaligen Nachschlagfelder, die vorher alle vom Typ Zahl waren jetzt "Langer Text" und eine Nachschlagereferenz ist nicht mehr zu finden. Die Tabelle (SP-Liste) ist in Access aber auch nicht editierbar, der Datentyp kann nicht mehr geändert werden.

    Vielen Dank schon mal für jeden Tipp, der mir irgendwie weiterhilft!


    • Bearbeitet Seemeonmsdn Dienstag, 16. Februar 2016 18:25
    Montag, 15. Februar 2016 23:05

Antworten

  • Hallo!

    Problem 1:

    This is by design. Eingebundene Sharepointlisten sind in einer Web App immer schreibgeschützt. Das ist eine der vielen offiziellen Einschränkungen. s. z.B. diesen Artikel (drittletzter Absatz) oder diese Gegenüberstellung, in der der Schreibschutz sogar als Grund genannt wird, keine Web App sondern eine Desktop-Anwendung mit Access zu erstellen (suche im Text nach "SharePoint-Listen").

    Ergänzung: Ich habe gerade auf UserVoice gesehen, dass das Feature zumindest "Under Review" ist. Kannst ja deine Stimme dafür abgeben, um es zu beschleunigen. ;-)

    Problem 2:

    Ich habe selber so eine Konvertierung zu Sharepointlisten noch nie gemacht (nach Web App schon) und verwende auch nie Nachschlagefelder in Tabellen. Klingt nach einem der vielen durch sie vorprogrammierten Probleme. Sie sind schon im Desktop-Access eine Pest, weil sie vieles verunklaren, anscheinend auch für Sharepoint.

    Wenn du diese Tabellen weiterhin als Sharepointlisten vorhalten willst - statt sie in Web App-Tabellen (d.h. SQL Azure) zu konvertieren - dann solltest du sie entweder vor der Konvertierung "bereinigen" oder nachträglich in Sharepoint Typ und Daten anpassen. Entweder direkt in O365 d.h. Sharepoint Online, oder evtl. z.T. auch über eine Verlinkung der beteiligten Sharepointlisten in eine Access-Desktop-Datenbank und entsprechende Aktualisierungsabfragen. Jedenfalls sicher nicht in der Web App (s.o.).


    cu
    Karl
    Access FAQ (de/it): donkarl.com
    Access Lobby: AccessDevelopers.org





    Dienstag, 16. Februar 2016 10:12
  • Hallo IchsehdichaufMSDN,

    >... Web App-Tabellen ...festgestellt, dass ich hier keine Möglichkeiten
    > hatte Berechtigungen auf die Tabellen/Daten zu vergeben.

    Richtig.

    > Es ist ja nicht möglich, dass ein User in der App Daten der Tabelle A und B
    > bearbeiten kann und ein anderer User kann dann nur Daten der Tabelle A lesen,

    Man kann/muss sich eine eigene Berechtigungsverwaltung basteln. Dazu blendet man z.B. die reinen Tabellennamen in der Liste links aus bzw. ersetzt sie durch etwas anderes. Den Zugriff auf die Daten regelt man dann über die Webformulare (Views/Ansichten).

    Mithilfe der beiden Funktionen BenutzerEMailAdresse() und BenutzerAnzeigename() ermittelt man den aktuellen Benutzer und je nachdem, was er (sehen) darf, öffnet man bestimmte Ansichten, regelt die Sichtbarkeit von Steuerelementen usw. Alles per Makro.

    > Außerdem kann man auch keine 2. App mit anderen Ansichten auf die gleichen Daten erstellen.

    Richtig. Jede Access Web Apps (AWA) hat ihre eigene Azure Datenbank. Man kann zwar auf diese Azure DB von außen zugreifen, z.B. mit dem SQL Server Management Studio oder per ODBC mit einer Access Desktop Anwendung (mache ich mehrfach), aber nicht aus einer anderen AWA heraus.

    > Tut mir leid, wenn meine Fragen nicht gerade professionell sind,
    > ich fange gerade erst an mit Access und Sharepoint Online.

    Die Einarbeitung für ernsthafte Anwendungen mit AWAs ist nicht ohne, die wenigen Bücher dazu lesen, herumprobieren, in Foren herumfragen etc. Ich persönlich habe die Arbeit damit bald wieder reduziert. Sie sind in vielerlei Hinsicht beschränkt, für mich werden sie bisher von MS bestenfalls halbherzig unterstützt und weiterentwickelt. Ihre Verbreitung ist dürftig, ihre Zukunft ungewiss, solange es keine deutlichen Ansagen und Taten von MS dazu gibt.

    Sharepoint Online ist hingegen schon fast auf dem Niveau der lokalen Vollversion, ist aber auch nicht ganz einfach zu lernen und hat auch seine Probleme, z.B. die ersatzlose Abkündigung der Client-Instrumente Designer und InfoPath. In dem Sinne: Viel Spaß!


    cu
    Karl
    Access FAQ (de/it): donkarl.com
    Access Lobby: AccessDevelopers.org

    • Als Antwort markiert Seemeonmsdn Freitag, 19. Februar 2016 13:14
    Mittwoch, 17. Februar 2016 11:56

Alle Antworten

  • Hallo!

    Problem 1:

    This is by design. Eingebundene Sharepointlisten sind in einer Web App immer schreibgeschützt. Das ist eine der vielen offiziellen Einschränkungen. s. z.B. diesen Artikel (drittletzter Absatz) oder diese Gegenüberstellung, in der der Schreibschutz sogar als Grund genannt wird, keine Web App sondern eine Desktop-Anwendung mit Access zu erstellen (suche im Text nach "SharePoint-Listen").

    Ergänzung: Ich habe gerade auf UserVoice gesehen, dass das Feature zumindest "Under Review" ist. Kannst ja deine Stimme dafür abgeben, um es zu beschleunigen. ;-)

    Problem 2:

    Ich habe selber so eine Konvertierung zu Sharepointlisten noch nie gemacht (nach Web App schon) und verwende auch nie Nachschlagefelder in Tabellen. Klingt nach einem der vielen durch sie vorprogrammierten Probleme. Sie sind schon im Desktop-Access eine Pest, weil sie vieles verunklaren, anscheinend auch für Sharepoint.

    Wenn du diese Tabellen weiterhin als Sharepointlisten vorhalten willst - statt sie in Web App-Tabellen (d.h. SQL Azure) zu konvertieren - dann solltest du sie entweder vor der Konvertierung "bereinigen" oder nachträglich in Sharepoint Typ und Daten anpassen. Entweder direkt in O365 d.h. Sharepoint Online, oder evtl. z.T. auch über eine Verlinkung der beteiligten Sharepointlisten in eine Access-Desktop-Datenbank und entsprechende Aktualisierungsabfragen. Jedenfalls sicher nicht in der Web App (s.o.).


    cu
    Karl
    Access FAQ (de/it): donkarl.com
    Access Lobby: AccessDevelopers.org





    Dienstag, 16. Februar 2016 10:12
  • Hallo Karl,

    vielen Dank für deine Antworten!

    Tut mir leid, dass ich das mit dem schreibgeschützten Öffnen der Tabellen in Web Apps nicht selber gefunden habe. Hatte gestern Abend schon im Netz danach geschaut aber diese Seiten nicht gefunden. Allerdings hatte ich es mir schon fast gedacht, dass es so ist.

    Liebend gerne würde ich Web App-Tabellen verwenden, hatte auch schon eine App erstellt mit Web App-Tabellen, aber dann festgestellt, dass ich hier keine Möglichkeiten hatte Berechtigungen auf die Tabellen/Daten zu vergeben. Es ist ja nicht möglich, dass ein User in der App Daten der Tabelle A und B bearbeiten kann und ein anderer User kann dann nur Daten der Tabelle A lesen, er kann dann auch immer die Daten von Tabelle B lesen, oder irre ich mich da? Außerdem kann man auch keine 2. App mit anderen Ansichten auf die gleichen Daten erstellen.

    Tut mir leid, wenn meine Fragen nicht gerade professionell sind, ich fange gerade erst an mit Access und Sharepoint Online.

    Dienstag, 16. Februar 2016 18:43
  • Hallo IchsehdichaufMSDN,

    >... Web App-Tabellen ...festgestellt, dass ich hier keine Möglichkeiten
    > hatte Berechtigungen auf die Tabellen/Daten zu vergeben.

    Richtig.

    > Es ist ja nicht möglich, dass ein User in der App Daten der Tabelle A und B
    > bearbeiten kann und ein anderer User kann dann nur Daten der Tabelle A lesen,

    Man kann/muss sich eine eigene Berechtigungsverwaltung basteln. Dazu blendet man z.B. die reinen Tabellennamen in der Liste links aus bzw. ersetzt sie durch etwas anderes. Den Zugriff auf die Daten regelt man dann über die Webformulare (Views/Ansichten).

    Mithilfe der beiden Funktionen BenutzerEMailAdresse() und BenutzerAnzeigename() ermittelt man den aktuellen Benutzer und je nachdem, was er (sehen) darf, öffnet man bestimmte Ansichten, regelt die Sichtbarkeit von Steuerelementen usw. Alles per Makro.

    > Außerdem kann man auch keine 2. App mit anderen Ansichten auf die gleichen Daten erstellen.

    Richtig. Jede Access Web Apps (AWA) hat ihre eigene Azure Datenbank. Man kann zwar auf diese Azure DB von außen zugreifen, z.B. mit dem SQL Server Management Studio oder per ODBC mit einer Access Desktop Anwendung (mache ich mehrfach), aber nicht aus einer anderen AWA heraus.

    > Tut mir leid, wenn meine Fragen nicht gerade professionell sind,
    > ich fange gerade erst an mit Access und Sharepoint Online.

    Die Einarbeitung für ernsthafte Anwendungen mit AWAs ist nicht ohne, die wenigen Bücher dazu lesen, herumprobieren, in Foren herumfragen etc. Ich persönlich habe die Arbeit damit bald wieder reduziert. Sie sind in vielerlei Hinsicht beschränkt, für mich werden sie bisher von MS bestenfalls halbherzig unterstützt und weiterentwickelt. Ihre Verbreitung ist dürftig, ihre Zukunft ungewiss, solange es keine deutlichen Ansagen und Taten von MS dazu gibt.

    Sharepoint Online ist hingegen schon fast auf dem Niveau der lokalen Vollversion, ist aber auch nicht ganz einfach zu lernen und hat auch seine Probleme, z.B. die ersatzlose Abkündigung der Client-Instrumente Designer und InfoPath. In dem Sinne: Viel Spaß!


    cu
    Karl
    Access FAQ (de/it): donkarl.com
    Access Lobby: AccessDevelopers.org

    • Als Antwort markiert Seemeonmsdn Freitag, 19. Februar 2016 13:14
    Mittwoch, 17. Februar 2016 11:56
  • Hallo Karl!

    Das Thema AWA habe ich gerade ein bißchen zur Seite gelegt und dann mal wegen Access-Desktopanwendung m. Sharepoint-Online geschaut. Dabei aber festgestellt, dass die Access - Runtime nicht gleichzeitig mit Klick-und-Los-Installationen funktioniert, also meine Anwender Access haben müssten (schade!).

    Aus diesem Grund schaue ich mir die Möglichkeiten an, die mir die Sharepoint-Listen schon alleine bringen. Ich denke, da kann ich für meine Bedürfnisse schon einiges mit machen.Bin selber gespannt wie es sich weiterentwickeln wird...

    Vielen Dank für deine Rückmeldung!

    See you, bye Silvia

    Freitag, 19. Februar 2016 13:25
  • Hallo, Silvia!

    ...Access - Runtime nicht gleichzeitig mit Klick-und-Los-Installationen funktioniert, also meine Anwender Access haben müssten (schade!).

    Das stimmt für die Runtime 2016 und wird hoffentlich noch behoben. Der aktuelle Workaround ist, stattdessen die Runtime 2013 zu verwenden, denn die lässt sich trotz Klick-Los installieren und die beiden Access-Versionen unterscheiden sich nur geringfügig (Download-Links s. meine Webseite).


    cu
    Karl
    Access FAQ (de/it): donkarl.com
    Access Lobby: AccessDevelopers.org

    Freitag, 19. Februar 2016 16:54