MS Access ODBC "#GELÖSCHT"

[iseries_user]

Hallo zusammen,

ich habe das Problem, dass ich auf eine AS/400 Datei (DDL beschreiben) nicht mit MS Access zugreifen kann.

Es werden zwar alle spalten angezeigt allerdings mit dem Wert '#GELÖSCHT'.

Ich habe nun schon etwas im Internet gesucht und herausgefunden, dass es daran liegt, dass Access keinen Primary Key findet. Allerdings werde ich auch nicht danach gefragt.

Ich vermute dass Access Probleme mit der Dateidefinition hat.

Ich habe folgende Definition:



CREATE TABLE Table1
(
T1_Feld1 BIGINT NOT NULL UNIQUE GENERATED ALWAYS AS IDENTITY ,
T1_Feld2 BIGINT NOT NULL,
T1_Feld3 numeric(8) DEFAULT 0 NOT NULL) RCDFMT RCD01;

CREATE TABLE Table2
(
T2_Feld1 BIGINT NOT NULL UNIQUE GENERATED ALWAYS AS IDENTITY ,
T2_Feld2 numeric(8) DEFAULT 0 NOT NULL) RCDFMT RCD02;

ALTER TABLE Table1
ADD CONSTRAINT Table1_2_Table2 FOREIGN KEY (T1_Feld2)
REFERENCES Table2 (T2_Feld1)
ON UPDATE NO Action
ON DELETE RESTRICT
;



Wir haben das Release V7R1.
Microsoft Access 2010.


Vielen Dank für eure Hilfe

iseries_user

[Fuerchau]

Du solltest auf die IDENTITY-Felder einen Constraint mit Primary Key legen, damit Access auch mit Schlüssel zugreifen kann.

Der Verknüpfungsmanager fragt normalerweise nach den zu verwendenden Schlüsselfeldern wenn kein Primary-Key oder Unique-Key gefunden wird.
In diesem Fall wird eine Feldliste angezeigt zum anclicken der Schlüssel.

Ob Access-2010 BIGINT unterstützt kann ich nicht sagen, ggf. hilft eine Reduzierung auf INTEGER (2^31 Werte sollten doch auch ausreichen).

[iseries_user]

Hallo,

Ich habe das ganze nun einmal vereinfacht. und nur eine Tabelle genommen. Auch hier habe ich das gleiche Problem.

Ich habe also

CREATE TABLE Table1
(
T1_Feld1 BIGINT NOT NULL UNIQUE GENERATED ALWAYS AS IDENTITY ,
T1_Feld2 BIGINT NOT NULL,
T1_Feld3 numeric(8) DEFAULT 0 NOT NULL) RCDFMT RCD01;

erstellt.

Auch hier wieder alles "gelöscht".

Wenn ich nun

ALTER TABLE Table1
ADD CONSTRAINT TABLE1_UNIQUE PRIMARY KEY (T1_Feld1)
ausführe bekomme ich die Fehlermeldung SQL0541
Doppelte Integritätsbedingung der Art UNIQUE für Tabelle TABLE1 in "LIB".

[Fuerchau]

Möglicherweise ist IDENTITY automatisch ein Primary key.
Versuche es doch mal mit einfachem INTEGER an stelle von BIGINT!

[iseries_user]

Hallo,

habe versäumt zu schreiben, dass es mit BigInt geht. Daran liegt es nicht.

Gruß iseries_user

[Fuerchau]

Ggf. kommt Access nicht mit IDENTITY zurecht.
Mach mal eine einfache Tabelle mit BIGINT als Primary Key OHNE Identity.

Zumal beim GENRATED ALWAYS ja beim Insert die Nummer vergeben wird und Access dann den generierten Wert nicht zurückbekommt.
Einen "select fx from insert ..." (so ähnlich) kennt Access ja nicht.

Über Access musst du die Nummer dann schon selber verwalten, da bei verknüpften Tabellen Auto-Keys nicht verwendet werden können.

[iseries_user]

Hallo,

es scheint wirklich am Identity zu liegen. Eine Tabelle mit BIGINT ist kein Problem. Sobald ich ein IDENTITY einfüge wird "#GELÖSCHT" angezeigt.
Ich habe gestern eine View mit "Select *" erstellt und es hat funktioniert.

Ich werde heute mal die Windows Admins fragen, wie Access eingestellt ist. Da die ANwender Access eigentlich nur für Abfragezwecke nutzen sollen!

Danke für deine hilfe Fuerchau.

Gruß iseries_user

[Fuerchau]

Sobald jemand mit Access auf deine DB kommt, musst du über Berechtigungen auf der AS/400 nachdenken, da in Access nichts einstellbar ist um Updates zu verhindern.
Verknüpfungsmanager und SQL-Passthru-Abfragen (die auch Updates, Deletes und Inserts enthalten können) können vie ODBC ohne Einschränkungen durchgeführt werden.
Das Hauptproblem ist ja meistens so, dass ein User mit seiner Anmeldung für die AS/400-Anwendungen (5250) eben auch per ODBC/FTP zugreifen kann.
Erschwert wird das auch noch mit Usern/Gruppenprofilen mit *ALLOBJ wo sich kein Zugriff ausschließen lässt.

Wenn man keine Lust hat über Konzepte nachzudenken hilft dann wohl nur ein Tool wie PCSACC/400, dass sich in diverse Eintritspunkte einklinkt um eben diese Berechtigungen dann zu prüfen.