Taranga Geschrieben 23. Mai 2006 Teilen Geschrieben 23. Mai 2006 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Taranga Geschrieben 29. Mai 2006 Autor Teilen Geschrieben 29. Mai 2006 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Amstelchen Geschrieben 29. Mai 2006 Teilen Geschrieben 29. Mai 2006 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Taranga Geschrieben 29. Mai 2006 Autor Teilen Geschrieben 29. Mai 2006 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? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Taranga Geschrieben 30. Mai 2006 Autor Teilen Geschrieben 30. Mai 2006 hab ich es wieder zu kompliziert beschrieben, oder kennt sich da keiner aus? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
isardor Geschrieben 30. Mai 2006 Teilen Geschrieben 30. Mai 2006 Wie sieht denn dein Connetionstring aus? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Taranga Geschrieben 31. Mai 2006 Autor Teilen Geschrieben 31. Mai 2006 "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" Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
isardor Geschrieben 31. Mai 2006 Teilen Geschrieben 31. Mai 2006 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Taranga Geschrieben 31. Mai 2006 Autor Teilen Geschrieben 31. Mai 2006 nö, kommt die gleiche fehlermeldung, ... Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
isardor Geschrieben 1. Juni 2006 Teilen Geschrieben 1. Juni 2006 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? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Taranga Geschrieben 1. Juni 2006 Autor Teilen Geschrieben 1. Juni 2006 ich schick über ado ein command mit dem sql-string raus der string sieht ganz normal aus "select * from MSysRelationships" Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
isardor Geschrieben 1. Juni 2006 Teilen Geschrieben 1. Juni 2006 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. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Taranga Geschrieben 2. Juni 2006 Autor Teilen Geschrieben 2. Juni 2006 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
isardor Geschrieben 2. Juni 2006 Teilen Geschrieben 2. Juni 2006 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. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Taranga Geschrieben 13. Juni 2006 Autor Teilen Geschrieben 13. Juni 2006 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.