Tabellenindices bestimmen

[Brainshock]

Hallo,

kann mir bitte einer mal ein paar Hinweise geben, wie man über Delphi Tabellenindices bestimmen kann? Also ich brauche die Namen der Indice, deren Spalten, Sortierung, ...

Gruß

[mkinzler]

Es kommt hier auf das verwendete DBMS an

[Bernhard Geyer]

Um es genauso genau anzugeben wie der Poster: Kann man alles aus den Systemtabellen abfragen :-)

[marabu]

Hallo Matthias,

du hast ODBC als deine Zugriffsmethode angegeben. In diesem Fall erhältst du die gewünschten Informationen über die ODBC Catalog Functions - allen voran SqlStatistics(). Voraussetzung ist ein funktionierender (compliant) ODBC 1.0 Treiber.

Gute Nacht

[Brainshock]

@marabu

Danke für die schnelle Anwort ich schau es mir mal an.

@DieAnderen

Die DBMS die abgefragt werden sollen wären z.B. Oracle, MS SQLServer, Firebird bzw. Interbase. Ich hätte natürlich gerne was, was unabhängig von Systemtabellen ist, da die ja nun mal von DBMS zu DBMS unterschiedlich sind.

Gruß

[Bernhard Geyer]

Soll es 'ne umfangreichere zu verteilenden Anwendung würde ich nicht über ODBC gehen. Die SQL-Unterschiede werden eh durch ODBC nicht gekapselt und ODBC hat auch mit nötige Installation und der vorhandenen DLL-Hölle so sein "Graues Haar bekommen"-Potential

[Brainshock]

Zitat:

Soll es 'ne umfangreichere zu verteilenden Anwendung würde ich nicht über ODBC gehen. Die SQL-Unterschiede werden eh durch ODBC nicht gekapselt und ODBC hat auch mit nötige Installation und der vorhandenen DLL-Hölle so sein "Graues Haar bekommen"-Potential

Deine Bedenken sind schon berechtigt. Nur momentan gibt es bei meiner Anwendung 2 Probleme:

1. Es basiert momentan alles auf der Komponentensammlung mODBC und eine Umstellung auf eine andere Komponete kommt auf die Schnelle nicht in Frage.
2. Ich habe noch keine richtige Alternative gefunden. (Sollte ohne BDE laufen und der Treibersupport sollte vorhanden sein).

Gruß,

[Bernhard Geyer]

Zitat:

Zitat von Brainshock

2. Ich habe noch keine richtige Alternative gefunden. (Sollte ohne BDE laufen und der Treibersupport sollte vorhanden sein).

Hast du schon mal die Kompos von Core Labs angeschaut? Sind z.B. für MySQL das schnellste was ich bisher gefunden habe. :thumb:

[shmia]

[quote="Brainshock"]

Zitat:

2. Ich habe noch keine richtige Alternative gefunden. (Sollte ohne BDE laufen und der Treibersupport sollte vorhanden sein).

Wenn du möglichst viele verschiedene Datenbank ansprechen möchtest, dann ist ADO der beste Weg.
(Ab Delphi 6 Prof. aufwärts; bei Delphi 5 Prof/Ent muss man löhnen)
Für die Datenbanken, für die es keinen ADO Treiber (OLE DB Provider) gibt, gibt es eine Art "Gateway" von ADO nach ODBC.
Durch die vielen Treiberschichten muss man natürlich mit Performanceverlusten rechnen aber man braucht nur eine Art von Komponenten (TADOQuery, TADODataset, TADOConnection).

Du kannst dir ja mal mein Programm ADO Desk anschauen.
Programmiert in Delphi 5 + ADO Komponenten.

[Bernhard Geyer]

Zitat:

Zitat von shmia

Wenn du möglichst viele verschiedene Datenbank ansprechen möchtest, dann ist ADO der beste Weg.

Da muß ich mal wiedersprechen. Mit ADO hast du genau die gleichen Probleme: DLL-Hölle und Installationsaufwand. Ist zwar geringer als bei BDE aber immer noch vorhanden. ADO ist optimal für MS SQL Server und Access. Für andere DB's gibt es bessere Lösungen (vor allem wenn spezialfeatures verwendet werden die über ADO mehr schlecht als recht herüberkommen).
Dies ist auch ein Grund wieso MS unter .NET mit ADO.NET wieder einen etwas anderen Ansatz gewählt hat.

[shmia]

Zitat:

Zitat von Bernhard Geyer

Da muß ich mal wiedersprechen...

Nun unbestritten ist, das ADO alles andere als perfekt ist.
Die Grundidee aber: "ein Zugriffsschicht für alle Datenbanken" bleibt denoch ein erstrebenswertes Ziel.
Die Windows Druckertreiber haben sich auf breiter Front durchgesetzt obwohl die Druckermodelle und Druckersprachen (PCL5, Esc-P, ...) sehr unterschiedlich sind.
Leider trifft das nicht auf Datenbanktreiber zu.
Es hängt alles nur von den Treibern ab.
Das Programmiermodell hinter ADO ist auf jeden Fall ausreichend, alle Arten von Datenbanken (auch nicht-relationale) anzubinden.
MS beweist ja mit seinem "Data Transformation Services" dass es möglich ist.
(wobei ich vermute, dass MS auf die darunterliegende OLE-DB Schicht zugreift)

Was wäre also die Alternative: jeweils eine eigene API zu jeder Datenbank ?
Schnell, wenig Installationsaufwand, aber immer begrenzt auf einen DB-Hersteller.
Für jede Programmiersprache das Rad (den Zugriff auf die API) erneut erfinden ?

[Bernhard Geyer]

Zitat:

Zitat von shmia

Die Grundidee aber: "ein Zugriffsschicht für alle Datenbanken" bleibt denoch ein erstrebenswertes Ziel.

Ja. Unter unter Java wird da ja auch nicht alle 2-3 Jahre alles über den Haufen geworfen. Und da MS ja eh nur noch .NET sieht ist auch ADO.Win32 ein sterbendes Modell.

Zitat:

Zitat von shmia

Was wäre also die Alternative: jeweils eine eigene API zu jeder Datenbank ?
Schnell, wenig Installationsaufwand, aber immer begrenzt auf einen DB-Hersteller.
Für jede Programmiersprache das Rad (den Zugriff auf die API) erneut erfinden ?

Nicht ganz. Borland hat ja seit D3 (oder wars D4) mit TDataset eine Basisklasse geschaffen worauf viele Native-DB-Access-Hersteller aufsetzen. Da als Basis und darauf aufsetzend mittels Bridge-Pattern auch noch die SQL-Unterschiede gekapselt und gut ist es. Haben für jede unterstützte DB ca. 1000-2000 Zeilen DB-Spezifischen Code und schaffen problemlos sehr hohe Geschwindigkeiten da wir trotzdem optimierte Queries erzeugen können.

[mkinzler]

Eine Alternativen wäre u.U Zeos oder dbExpress

[Brainshock]

Naja, wir werden hier leider ein bisschen Offtopic.

Ich glaube das ist mal wieder eine Glaubensfrage, welche Art der Datenbankanbindung man nutzt.
ODBC und DLL Hölle kann ich eigentlich nicht bestätigen. ODBC Treiber installiert, DSN Eintrag angelegt und fertig.
Die anderen Alternativen sollte man vielleicht mal in einem extra Thread diskutieren. Für die Zukunft würde mich schonmal interessieren, welche die sicherste in Bezug auf Treiberunterstützung und flexibelste (schnellste) Art der Datenbankanbindung ist.

Gruß,