Access als Frontend - Problem mit einem Formular

[zachy 10]

Hallo Forumsmitglieder, 

 

ich nutzte seit längerer Zeit Access 2013 als Datenbank und Frontend. Aus bestimmten Gründen habe ich mich dazu entschlossen, die Datenbanklogik auf SQL Server 2014 zu verschieben und Access nur noch als Frontend zu benutzen. 

 

Gesagt getan. Zunächst einmal habe mit Hilfe des Migration Wizzard alle meine Access-Tabellen auf den SQL-Server kopiert (ich habe die Link-Funktion des Wizzards nicht verwendet).

 

In Access hatte ich mehrere Formulare erstellt, u.a. eines welches als Datenquelle eine Abfrage auf vier Access-Tabellen benutzt. Das Formular läuft schnell und absolut einwandfrei.

 

Ich habe nun die Datenquelle dieses Formulars in eine Pass-Trough-Abfrage geändert, mit der ich auf die gleichen vier Tabellen zugreife, diesmal aber die im SQL Server. Das Formular zeigt mir nun auch brav alle Datensätze an (wobei das Laden merklich länger dauert, als wenn auf Access-Tabellen zugegriffen wird. Ist das normal?). Sobald ich aber versuche Daten zu ändern oder hinzuzufügen, erscheint in der Statusleiste von Access folgende Meldung:

 

"Diese Datensatzgruppe kann nicht aktualisiert werden."

 

 

Laut Microsoft Support Seite hat das folgende Ursache:

"Die Tabelle, die Sie aktualisieren, ist eine verknüpfte Tabelle, die keinen Primärschlüssel oder eindeutigen Index besitzt. Die Abfrage oder das Formular basieren auf einer verknüpften Tabelle, die keinen Primärschlüssel oder eindeutigen Index besitzt."

 

("Statusleiste zeigt die Meldung "Datensatzgruppe kann nicht aktualisiert werden" an, wenn Sie versuchen, eine verknüpfte Tabelle in Access 2000 zu aktualisieren", URL: https://support.microsoft.com/en-us/kb/304179/de Stand: 08.02.2008)

 

 

Die SQL-Server-Tabellen besitzen aber einen Primärschlüssel. Es handelt sich auch nicht um eine aggregierte Abfrage. Ich habe die Abfrage sogar auf dem SQL Server getestet. Alles wunderbar, man konnte auch Daten hinzufügen oder ändern.

 

Hier einmal die Abfrage:

SELECT        dbo.tblFirmen.FrmID, 
dbo.tblFirmen.FrmNr, dbo.tblFirmen.FrmName, dbo.tblFirmen.FrmNamenszusatz, 
dbo.tblFirmen.FrmStrasse, 
dbo.tblFirmen.FrmAdresszusatz,                         
dbo.tblFirmen.FrmPLZ, dbo.tblFirmen.FrmOrt, dbo.tblBundeslaender.BdlBezeichnung, 
dbo.tblLaender.LndBezeichnung, 
dbo.tblFirmen.FrmMemo,                         
dbo.tblFirmen.FrmTel, dbo.tblFirmen.FrmFax, dbo.tblFirmen.FrmMail, 
dbo.tblFirmen.FrmHomepage, dbo.tblFirmen.FrmIBAN, 
dbo.tblFirmen.FrmBIC,                         
dbo.tblFirmen.FrmBank, dbo.tblFirmen.FrmLetzterKontakt, 
dbo.tblFirmen.FrmWiedervorlage 
FROM            
dbo.tblLaender RIGHT OUTER 
JOIN                         
dbo.tblBundeslaender RIGHT OUTER 
JOIN                         
dbo.tblOrte ON dbo.tblBundeslaender.BdlID = dbo.tblOrte.OrtBdlIDFK ON 
dbo.tblLaender.LndID = dbo.tblOrte.OrtLndIDFK RIGHT OUTER 
JOIN                         
dbo.tblFirmen ON dbo.tblOrte.OrtID = dbo.tblFirmen.FrmOrt

Woran kann es liegen, dass Access nicht in die Abfrage schreiben oder Daten aus ihr ändern kann? Hat jemand eine Idee?

 

Vielen Dank und beste Grüße

zachy

 

[Cybquest 36]

Wenn ich das richtig verstehe, sind die Tabellen selbst nun gar nicht in Access eingebunden sondern werden nur über PassThrough abgefragt? M.W. kann Access Daten nicht aktualisieren, wenn's den Primärschlüssel selbst nicht kennt. Ich würde vorschlagen, die Tabellen zu verknüpfen! Der Tabellenverknüpfungsassistent fragt ggf. nach dem Primärschlüssel, wenn er ihn selbst nicht ermitteln kann... 

[Sunny61 806]

Eine PassThrough Abfrage ist out of the Box nicht aktualisierbar. Du mußt das zukünftig anders lösen.

 

Datensätze anfügen/aktualisieren mittels Stored Procedure auf dem SQL Server. Die rufst Du dann aus Access heraus auf und schreibst deine Daten so weg.

Für das anfügen/aktualisieren von Datensätzen benutze ich eigene Formulare, beim klick auf Speichern werden dann die passenden SPs auf dem SQL aufgerufen. Das funktioniert sehr gut und sehr schnell.

 

EDIT: Hier noch ein Link zu dem Thema:

 

http://support.microsoft.com/de-de/kb/184749

bearbeitet 26. März 2015 von Sunny61

[zachy 10]

Hi, danke für eure Antworten.

 

Ja natürlich, die Tabellen müssen natürlich in Access 2013 verknüpft werden. Da hätte ich auch drauf kommen können. :P

 

Ich habe die Tabellen jetzt verknüpft und verwende nun diese als Datenquelle für mein Formular. Trotzdem dauert das Laden dieser Daten unfassbar lange.

 

Ist das bei euch auch so?

[Sunny61 806]

Ja natürlich, die Tabellen müssen natürlich in Access 2013 verknüpft werden. Da hätte ich auch drauf kommen können. :p

Ich gehe schon wieder den anderen Weg, die Tabellen nicht mehr zu verknüpfen, sondern alles per SP zu erledigen.

 

 

 

Ich habe die Tabellen jetzt verknüpft und verwende nun diese als Datenquelle für mein Formular. Trotzdem dauert das Laden dieser Daten unfassbar lange.

Dann weiß Access nichts vom PK. Wenn Du die Tabellen verknüpfst, vergibst Du beim verknüpfen einen PK?

[zachy 10]

Ich verwende zum verknüpfen der Tabellen immer das Tool ODBC-Datenbanken von Access. Ich bin davon ausgegangen, dass Access dann den PK kennt.

 

Allerdings werde ich jetzt auch versuchen, alles über SPs zu lösen. Das scheint mir der vernünftigste Weg zu sein. Dazu habe ich dann aber auch schon wieder ein Problem, welches ich aber in einem anderen Thread beschreiben werde.

 

Vielen Dank erst mal für Eure Hilfe!

 

Beste Grüße

zachy

[Sunny61 806]

Ich verwende zum verknüpfen der Tabellen immer das Tool ODBC-Datenbanken von Access. Ich bin davon ausgegangen, dass Access dann den PK kennt.

Du wrist beim Verknüpfen der Tabellen gefragt welches Feld Du als PK definieren möchtest. Wurdest Du gefragt? Hast Du eine Timestamp-Spalte in jeder Tabelle? Auch wenn hier SQL 2000 steht, sobald Tabellen von einem SQL Server in ein Access-FE eingebunden werden, sind Timestampspalten ein absolutes Muss. https://technet.microsoft.com/en-us/library/aa260631%28v=sql.80%29.aspx

 

Allerdings werde ich jetzt auch versuchen, alles über SPs zu lösen. Das scheint mir der vernünftigste Weg zu sein.

Vor allem äußerst unabhängig.