Hi!

Folgendes Problem:

Ich würd mir gerne meine Tabellnnamen aus C++ mittels einer ADO-Connection auslesen!

alle Tabellennamen stehen in MsysObjects drinnen!

Die Tabelle kann ich von Access ohne probleme aufrufen, aber von C++ nicht!

Fehlermeldung:

Record(s) cannot be read; no read permission on 'MsysObjects'.

Man kann im Access die Leserechte umstellen, dann funktioniert es für meine Datenbank am PC.

Nur wenn ich dass Porgramm dann wen anders schicke mit einer anderen Datenbank, funkt es wieder nicht!

also muss ich wohl irgendwelche Properties im Connection-String angeben, oder?

hat da jemand eine Idee??

bzw:

wenn es eine andere möglichkeit gibt, kann ich auch diese verwenden, ....

ich brauche hat meine Tabellennamen, wie ist mir egal

thx für tipps

lg Taranga

keiner ne idee?

hab jetzt die tabellen mit openschema bekommen!

nur brauch ich die beziehungen, da scheint openschema nen bug zu haben, funktioniert einfach nicht so wie es soll, ich bekomme den falschen spalten-name!

daher brauch ich jetzt unbedingt die Tabelle "MSysRelationships"

lg Taranga

hab jetzt die tabellen mit openschema bekommen!

das sollte auch die bevorzugte methode via ADO sein, mit welcher man weit mehr als nur tabellen "bekommt".

nur brauch ich die beziehungen, da scheint openschema nen bug zu haben

was führt dich zur auffassung, das wäre ein bug? was übergibst du dem ersten parameter von openschema, dem querytype?

suchst du vielleicht adSchemaForeignKeys, oder AdSchemaReferentialConstraints?

funktioniert einfach nicht so wie es soll, ich bekomme den falschen spalten-name!

wieso spaltenname? was funktioniert nicht? kannst du mal auszugsweise deinen code posten?

daher brauch ich jetzt unbedingt die Tabelle "MSysRelationships"

brauchst du die wirklich, wenn du über ADO ohnehin auf dieselben relationen zugreifen kannst?

ansonsten: äusserst konfus dein posting :floet:

s'Amstel

kk, mal danke für die antwort

werd jetzt mal versuchen etwas genauer mein problem zu beschreiben:

als Query-Type verwende ich: adSchemaKeyColumnUsage

ich brauche von dort dann CONSTRAINT_NAME, TABLE_NAME und COLUMN_NAME

ein teil meiner access-db:

Mission(MIS_ID, ....) 1 zu n ControlStation(CST_ID, CST_Mission_ID, ...)

Mission(MIS_ID, ....) 1 zu n HPSegment (HPS_ID, HPS_Mission_ID, ...)

beides sind die gleichen beziehungen. ==> beides müsste den gleichen COLUMN_NAME zurückgeben, oder?!

tut es aber nicht!

beim ersten steht richtigerweise im COLUMN_NAME "MIS_ID"

beim zweiten steht im COLUMN_NAME "HPS_Mission_ID" :confused:

irgend eine ahnung?

hab ich es wieder zu kompliziert beschrieben, oder kennt sich da keiner aus?

Wie sieht denn dein Connetionstring aus?

"Provider=Microsoft.Jet.OLEDB.4.0;Jet OLEDB:Database Password=xxx;User ID=Admin;Data Source=" + (LPCTSTR)udlpath + ";Mode=Share Deny Read|Share Deny Write"

Hast du schon probiert was passiert wenn du "Mode=Share Deny Read|Share Deny Write" mal weglässt, weil hier habe ich die Vermutung dass du dem anwender die Lese/Schreibrechte entziehst

nö, kommt die gleiche fehlermeldung, ...

hmm, raff ich nicht. wie sieht dein SQLstring aus? Oder greifst du direkt mit ADO auf ACCESS zu? Oder hast du die Abfragen in Access gespeichert und nutzt sie wie Storend Procedures?

ich schick über ado ein command mit dem sql-string raus

der string sieht ganz normal aus "select * from MSysRelationships"

so, ich poste mal wie ich mir das Tabellenschema vorstelle, allerdings in PostgreSQL, da ich grade kein Access zur hand habe. Ist ja nur ein Beispiel:

create table MISSION (

MIS_ID serial primary key, irgendwas varchar(12)

);

Create table ControlStation(

CST_ID serial primary key, CST_Mission_ID int references MISSION

);

Create table HPSegment (

HPS_ID serial primary key, HPS_Mission_ID int references MISSION

) ;

jetzt mal den Verknüpfungstypen beiseite gelassen, sind die beiden letzten Tabellen jetzt mit MIS_ID verknüpft. Wenn ich jetzt den zuständigen view aufrufe, mit

select * from information_schema.referential_constraints

Dann bekomme ich das richtige Ergebnis

[B]constraint_name[/B]

"controlstation_cst_mission_id_fkey"     

"hpsegment_hps_mission_id_fkey"          


[B]unique_constraint_name[/B]

"mission_pkey"

"mission_pkey"

Der Fehler der bei dir auftritt, sollte eigentlich nicht auftreten, es sei denn, du hast die Tabellen falsch verknüpft, oder es ist ein Access Bug. Da du die tabellen aber sicher grafisch verknüpft hast, tippe ich eher auf das letzte.

jo, genau so ist es, ich hab die tabellen sicher nicht falsch verknüpft, da es in der access tabelle ja richt drinnen steht! (MSysRelationships)

doch im schema ist es falsch!!

also ich kann mir auch keine andere antwort mehr vorstellen außer einen bug, ...

daher muss ich jetzt auf die MSysRelationships zugreifen, ...

das was ich noch immer net weiß wie es geht

ich würde jetzt spontan versuche die Tabelle mal mit einer anderen Sprache aufzurufen, z.B. PHP, CF, VB oder Python. Dann kannst du sehen, ob es an Access liegt oder an der Schnittstelle in C++. Da passt dann besonders VB, da du ja hier auch ADO nehmen kannst. Für PHP nimmst du ODBC, ich denke für Python auch, bin ich nicht so fit drin. Das Freie ColdFusionderivat IgniteFusion, braucht auch nur die ODBC Schnittstelle.

Na jedenfalls wenn der Fehler über ADO und über ODBC auftritt sollte der Fehler bei Access liegen. Wenn er aber schon in VB (das richtige nicht VBA) nicht auftritt liegt dein Fehler im C++ Code, da ja beide die selbe ADOSchnittstelle verwenden.

Und wenn du ganz Hardcore bist, probiers in Assembler.

hab das problem jetzt total anders (auch umständlicher) gelöst, ...

falls doch noch wer ne idee hat plz melden

@isardor

hab es mit einer anderen sprache noch nicht probiert, kann mir aber auch net vorstellen, das da klappt