Access Formular als Postgres Frontend erzeugt falsche Daten

Guten Morgen zusammen,

ich nutze aktuell Access 2010, um über dort erstellte Formulare Daten in eine Postgres Datenbank einzutragen. Aus meiner Sicht ist das Konstrukt sehr simpel. Ich habe in der Postgres eine Tabelle erzeugt mit verschiedenen Spalten, davon eine Spalte als ID (Primärschlüssel), die automatisch einen neuen Wert für jeden Datensatz generiert auf Basis einer Sequence in der Datenbank. Das funktioniert dort auch problemlos, wenn ich wenn ich die Daten dort bearbeite.

Die Tabelle habe ich per ODBC mit Access verknüpft und dort ein einfaches Formular erstellt, aber dabei die Spalte ID ausgeblendet. Um mir das Ganze deutlicher zu machen habe ich das gleiche Formular noch mal erstellt, diesmal mit der ID Spalte, um zu sehen, was dort passiert. Das Verhalten ist bei beiden Formularen gleich.

Wenn ich dort nun Daten eintrage, passiert folgendes:

  1. Ich positioniere am Ende auf die Zeile für einen neuen Datensatz und fülle im Formular die erste Spalte des neuen Satzes mit einem Wert aus. Die anderen Felder lasse ich leer.
  2. Ich verlasse mit der Maus den neuen Datensatz, so dass dieser geschrieben wird. In diesem Moment werden die übrigen Felder des neuen Datensatzes mit Werten eines anderen Satzes gefüllt. Auch die ID wird übernommen und ich habe im Formular faktisch ein Duplikat erzeugt.
  3. In der Postgres taucht dieser Datensatz nirgendwo auf. Dort sehe ich einen neuen Satz mit der richtigen (nächsten) ID und leeren ID.
  4. Drücke ich F5 um das Fomular zu aktualisieren, verschwindet das Duplikat und der neue Satz taucht in dem Formular auf.

Habt ihr eine Idee wie ich das Problem lösen oder zumindest weiter eingrenzen kann?

Danke und Gruß
Matthias

Ich wollte fragen, bist Du sicher, dass es nicht ein Bedienfehler ist oder so, aber Blödsinn, Du fragst ja, wie es gehen soll.
“Leider” kann ich nur mit meiner Erinnerung aushelfen. Wer nutzt heute noch Access? (Ich kann mich daran erinnern, dass das Eingeben neuer Daten in der “Fußzeile” etwas eigenartig ist. Trägt man dort einfach Werte ein, kommt genau so ein komischer Zeilensprung. Benutzt man die letzte Zeile bzw. das Sternsymbol oder so, dann wird erst ein leerer Datensatz angelegt und es zappelt nicht so, irgendwie so war das…

Aber zunächst:
Es war beim Insert wichtig, dass Access den Primärschlüssel erkennt. Ich weiß nicht mehr, wie man das anhand der Darstellung in einer verlinkten Tabelle erkennen kann. Wichtig ist natürlich, dass die Tabelle auch wirklich einen PK hat.

Es auch wichtig, dass Access (oder andere Werkzeuge) irgendwie “mitbekommen”, dass hier ein Schlüsselwert auf dem Server generiert wird und dieser nur geholt werden muss. Das klassische Problem dabei ist, wie man diesen Mechanismus konstruiert, Dateneingabe und (aktualisierte) Anzeige mit einem zunächst unbekannten Schlüsselwert.
Eigentlich kann man das nur sauber lösen, wenn die Programmierumgebung dafür passende, konfigurierbare Eigenschaften anbietet oder wenn man den ganzen Vorgang zu Fuß selbst programmiert.

  • post der neuen Werte
  • Handling der ID Rückgabe
  • Refresh der Anzeige mit Berücksichtigung der neuen ID

Wie das in Access (heute) geht, weiß ich nicht (will ich auch nicht wissen), müsste man entsprechend raussuchen.

Neben irgendwelchen Properties, die man vielleicht bei der Linked Table dazu verwenden kann, gäbe es noch die SQL Seite, die bei modernen Servern z.B. soetwas wie “returning” bietet.
Die Returning Clause liefert (beliebige) Rückgabewerte aus einem Insert. Diese kann man dann weiterverarbeiten (s.o.)
Ich vermute ganz stark, dass auch MS SQL Server das kann und dafür vielleicht Beispiele zur Anwendung in Access existieren, die man auf PG übertragen könnte.

Insgesamt scheint mir Kombi Postgres Access relativ ungewöhnlich. Der Gedanke, Daten nicht in Access selbst, sondern auf einem richtigen Server zu speichern ist aber vollkommen richtig.
Da wäre die Frage, ob Du vielleicht auch etwas anderes als Access nehmen könntest?

Ich betreue ein solches Konstrukt. Access als Frontend mit über ODBC eingebundenen Tabellen. Beim einrichten hatte ich den Tipp befolgt, in jeder Tabelle eine zusätzliche Spalte mit timestamp Datentyp default now() sowie ein Trigger before update, der die timestamp Spalte mit now() versorgt. Es wurde behauptet, dass Access so eine Spalte zum korrekten Abgleich braucht. Ich habs nicht durchgetestet sondern einfach verwendet. Die Anwendung läuft damit.
Mal grob gesagt: Access schickt deine Daten zu postgres, ist aber nicht schlau genug (keine Ahnung was ODBC kann) beim insert die ID zu holen. Mit einer timestamp Spalte scheint das zu funktionieren.
Alternativ: Lies in Access das nextval der sequence und setze den Wert ins ID Feld.

Hallo,

danke für eure Antworten. Ich bin zunächst mal dem Vorschlag gefolgt eine Spalte mit dem Timestamp zu füllen. Das scheint aber kein anderes Verhalten zu bringen. Habe es so gemacht, wie hier beschrieben:

a) Default now()
b) Trigger nach Update

Was ich als alternatives Frontend einsetzen kann, ist mir nicht klar. Ich bin kein Entwickler und bräuchte etwas einfaches, das ich wie Access zusammenklicken kann.

Gruß
Matthias

Hallo!
Ich hatte früher auch so ein Konstrukt, allerdings hatte ich mehrspaltige Keys, die ein Trigger gefüllt hat, und mehrere Unterformulare. Es hatte eigentlich gut funktioniert, ist aber auch schon ewig her (Access 2003 war das letzte, das ich verwendet hab). Nach deiner Beschreibung, wenn ich sie verstanden habe, verhält sich die Datenbank eigentlich wie vorgesehen. Kann es sein, das Access da irgendwelche Sachen cached?
Als Alternative in ähnlicher Weise kenn ich nur Libreoffice Base, das hatte ich mal ausprobiert, aber nicht produktiv eingesetzt.

Gruß Uwe

Ich habe den Verdacht, dass sich sogar Access “normal” verhält. Es ist halt etwas seltsam, in die leere Zeile reinzutippeln und dann einen neuen Datensatz zu erhalten (also Zeilensprung) und dort weiterzuschreiben.
Hast Du Erfahrung mit Access oder ist das für Dich auch neu?
Hast Du mal versucht, in der Linked Table Datensätze einzufügen? Ich bin mir nicht sicher, worauf sich “mit den Tabellen geht es” bezieht. PG naked oder Access Tabellen?
Die Sache mit den Sequenzen von UliScherrer dürfte ziemlich sicher funktionieren (Wenn nicht wirklich grundlegende Fehler im Treiber sind. Das umständliche Beschaffen der generierten Datensatz ID wird so jedenfalls straight forward erledigt und fällt als Problem raus.)

Ich habe nun tatsächlich über einen Hinweis aus einem anderen Forum die Lösung für das Problem gefunden.

Es gibt in der Konfig des ODBC einen Parameter, der die Erkennung des ID Feldes beeinflusst. Dadurch erkennt Access das ID Feld als AutoNumber. Und dann klappt auch die Dateneingabe ohne Probleme.

Extra Opts: combination of the following bits.
0x2: Fake MS SQL Server so that MS Access recognizes PostgreSQL’s serial type as AutoNumber type.

Vielleicht hat in der Zukunft mal jemand ein ähnliches Problem und sucht nach der Lösung.