Abfrage Sharepoint-Liste gesperrt?

[Xlsibb]

Hallo Leute,

ich hänge gerade an etwas: ich habe meine Datentabellen in Sharepoint verschoben.
Ich kann in der Abfrage Werte aktualisieren. Von Hand oder per Makro. Das geht, solange die Datentabellen auf dem Laufwerk liegen.
Mit dem Verschieben in Sharepoint geht das nun nicht mehr. Unten im Status steht "diese Datensatzgruppe kann nicht aktualisiert werden.

Es ist dieselbe Abfrage wie vorher, ich habe nichts geändert außer dass ich die Tabellen nach Sharepoint verschoben habe. Weiß jemand, woran das liegt?
Öffne ich die Listen in Sharepoint, muss ich noch extra auf "Bearbeiten" klicken. Liegt es ggf. daran? Muss ich das irgendwo einstellen, dass man das bearbeiten kann? Bisher habe ich nichts gefunden, als Owner wird angezeigt "Vollzugriff".

Weiß da von euch jemand mehr und kann mir helfen?
Danke schonmal!!

[mmarkus]

Weiß jemand, woran das liegt?

Hast du dich mit der Kompatibilität beider Systeme beschäftigt - vor allem welche Datentypen ein Problem sind?

https://support.microsoft.com/de-de/off ... movewizard

[Xlsibb]

Hi.

Danke schonmal, ich hab versucht, es mir genau anzugucken. (Nur für den Fall, dass ich was übersehen habe).

- Datenkonflikte sehe ich nicht, ich habe immer nur einfache Felder (Zahl, kurzer Text, langer Text, Ja/Nein, Datum, Währung), und Nachschlagespalten, Ordner, OLE o.dgl. verwende ich nicht.
- Access hat die Tabellenverknüpfungen gelöscht. Ich kann auch die Verknüpfungen mit referenzieller Integrität und Löschweitergabe nicht wieder herstellen, nur Verknüpfungen ohne all das. Beim Anzeigen aller Verknüpfungen sehe ich, dass alles auf die Userinfo-Tabelle verknüpft ist, was m.E., wenn ich Sharepoint richtig verstehe, auch OK ist.
- Es gab "Fehler beim Autospeichern von Objektnamen" in 3 Tabellen. Hier habe ich schon festgestellt, dass Daten fehlen. Der Vergleich mit dem Ursprungszustand gibt aber nur eines her (siehe nächster Punkt).
- Die Felder, in die zur Verknüpfung ID geschrieben wurden, wurden von Sharepoint in der Reihenfolge nach hinten verschoben und, wie gesagt, die Verknüpfung gelöscht.
- innerhalb eines Datensatzes fehlen keine Infos.

[Bitsqueezer]

Hallo,

Access ist recht großzügig darin, Abfragen aktualisierbar zu halten.

Normalerweise kann immer nur genau eine Tabelle zur gleichen Zeit aktualisiert werden, wenn es eine Abfrage über mehrere Tabellen ist (JOINs), ist das bei anderen Datenbanken oft nicht möglich. Was dann nichts mit Sharepoint zu tun hat, sondern mit Deiner Abfrage.

Gruß

Christian

[Xlsibb]

Hallo Christian,

kurz: OK, kaum macht man's richtig, tut's...

Keine Ahnung, was ich da für ne Abfrage gebastelt hatte. Jedenfalls, bei näherer Betrachtung war die ziemlich wirr, und es waren Hilfstabellen für Auswahlfelder drin, mit denen, nach Migration in Sharepoint, die Abfrage nicht mehr sauber war. Habe ich nun so konsolidiert.
Allerdings: um die Felder aus den besagten Tabellen trotzdem zu erhalten, habe ich viel mit "DomWert" gearbeitet. Eine Unterabfrage, wie z.B.

Feldname: (SELECT [xyz] FROM tabA WHERE [A.[ID]=tabB.[AID])

scheint die Tabelle wiederum zu blockieren. Nun denke ich aber, sind zu viele "DomWert"e nicht gerade Performance-förderlich. Hier vielleicht noch irgendwelche Tipps??

Vielen Dank!

[mmarkus]

Hier vielleicht noch irgendwelche Tipps??

Wie soll man bei solchen Angaben Tipps geben?

Datenmodell und aktuelle Abfrage könnten weiterhelfen.

[Bitsqueezer]

Hallo,

ja, das ist leider so bei Access, wenn man Unterabfragen in der Feldliste verwendet per SELECT, wie es normal wäre, macht Access die Abfrage dicht.
DLookup dagegen wird als Funktionsaufruf gewertet und dann bleibt die Abfrage editierbar.

Performance bekommt man natürlich am besten, indem man die Unterabfragen auf den Server in eine View verlagert. Problem dürfte aber hier Sharepoint sein, auch wenn ein SQL Server zugrundeliegt, kannst Du bei Sharepoint normalerweise nicht direkt auf dessen Datenbank, um dort eine View zu erstellen.

Frage wäre eher, ob Du die Unterabfragen tatsächlich brauchst - in einem Formular wäre etwa eine Kombobox geeignet, die Unterabfrage zu übernehmen und den betreffenden Wert anzuzeigen/zu editieren. Das kommt aber halt auf den Einsatzzweck Deiner Abfrage an.

Für einen Report müßte die Abfrage nicht editierbar sein.
Für eine UPDATE-Abfrage brauchst Du wiederum die Unterabfragen i.d.R. nicht...

Gruß

Christian

[Xlsibb]

Hallo Christian,

vielen Dank für Deine Ausführungen! Damit komme ich auf jeden Fall vollends zum Ziel.

Grüßle!
xlSibb

[Xlsibb]

Eine Sache noch: wie ist das mit den Beziehungen, wie ich's beschrieben hatte:

- Access hat die Tabellenverknüpfungen gelöscht. Ich kann auch die Verknüpfungen mit referenzieller Integrität und Löschweitergabe nicht wieder herstellen, nur Verknüpfungen ohne all das. Beim Anzeigen aller Verknüpfungen sehe ich, dass alles auf die Userinfo-Tabelle verknüpft ist, was m.E., wenn ich Sharepoint richtig verstehe, auch OK ist.

Muss ich jetzt in die Untertabelle per Makro die ID der Muttertabelle eintragen oder passiert das weiterhin automatisch?

[Bitsqueezer]

Hallo,

auch das ist von Access so vorgegeben und macht auch nur so Sinn.

Referentielle Integrität wird von der Datenbankengine überwacht und Löschungen/Updates entsprechend automatisiert durchgeführt.
Entsprechend funktioniert das natürlich nur mit Tabellen, die in der Datenbankengine vorhanden sind, hier also lokale Access-Tabellen. Wenn Du ein Access-Backend verwendest und auf dessen Tabellen verlinkst, kannst Du auch dann nur im Access-Backend die RI einstellen, nicht im Frontend.

Das hat auch nichts speziell mit Access zu tun, das ist auch in anderen Datenbanken so.

Die DB-Engine von Access führt hier ja nur einen Download der Daten aus einer entfernten Datenbank durch und ist selbst nur noch der "Datensklave", aber nicht die verantwortliche DB-Engine für Deine Datenbank.

Wenn Du also mit "Makro" eigentlich VBA meinst, dann ja, Du mußt alle Operationen bezüglich referentieller Integrität im Frontend erledigen, wenn Du das nicht im Backend einstellen kannst. In SQL Server, auf dem Sharepoint basiert, geht das natürlich, ob Sharepoint als "aufgepropftes Frontend" allerdings so eine Einstellung zuläßt, weiß ich nicht, ich kenne Sharepoint nur oberflächlich und habe mich entschieden, es niemals einzusetzen, weil zu teuer, zu langsam, zu unflexibel.

Wenn es denn schon eine Netzwerkdatenbank sein soll, würde ich Dir eher empfehlen, über eine Azure-SQLServer-Datenbank nachzudenken, da hast Du die volle Freiheit, alles zu machen, was Du willst, und sehr viel performanter ist es auch. Sharepoint ist höchstens noch sinnvoll, wenn man z.B. Dokumentenmanagement verwenden will und im Unternehmen halt überall Sharepoint verwendet wird. Als Datenbank-Backend würde ich es nie einsetzen.

Beachte, daß das "manuelle" Sicherstellen von RI per Code sehr aufwendig werden kann und bei weitem keine 100%-Zuverlässigkeit garantiert werden kann. Beispielsweise könnte der betreffende Frontendrechner auf irgendeinen Fehler stoßen bei der Ausführung oder auch einfach der Rechner abstürzen. Dann ist die RI-Sicherheit, die die DB-Engine garantiert, schon futsch...

Gruß

Christian

[Xlsibb]

Hallo Christian,

*verneig*
Vielen herzlichen Dank für deine Ausführungen.

OK, dann muss das Thema die Firmen-IT für mich lösen. Ich bin eigentlich im Vertrieb tätig und mache solche Tools nur nebenher. Access kenne ich in der Zwischenzeit ganz gut, aber alles andere müsste ich mich erst einarbeiten, und dafür fehlt mir die Zeit.
Thema war bei uns, dass ich eine Access-DB habe mit Backend und Frontend, und bei einer Kollegin ist die Performance unterirdisch schlecht. Bei testweise Migration in Sharepoint funktioniert es aber wieder topp. Scheint aber an den verwendeten Servern zu liegen, die Kollegin sitzt in einem anderen Gebäude, da ist's bei mir auch langsamer. Das sind Themen, die ich bisher nicht auf dem Schirm hatte und die auch außerhalb meiner Kompetenz liegen. Wenn nun eine Migration in Sharepoint einen deutlichen zusätzlichen Progammier- & Testaufwand bedeutet, muss ich die Segel strecken.

Aber dann habe ich wenigstens alle Möglichkeiten eruiert.