DBGrid und Count(*)

[Sidorion]

Folgendes Problem: Ich habe ein Memo, ein ADODataSet und eine DBGrid. Gibt man nun im Memo ein select-statement ein, wird dieses an das DataSet übergeben und die Grid stellt das Ergebnis dar.

Heisst nun eine Spalte 'Count(*)', wird die entsprechende Ergebnisspalte dermaßen breit, dass nichtmal meine 1600er Auflösung mitkommt.
Bei normalen Datenbankspalten macht ers richtig.

Nun die Frage: Kann man die DBGrid oder das DataSet irgendwie veranlassen, diese Spalte in vernünftiger Breite anzuzeigen, und wenn ja, wie?

[hoika]

Hallo,

Select Count(*) As Cnt ?


Heiko

[Sidorion]

negativ. Hat nix mit dem Namen des Kindes zu tun. Sind wohl alle Aggregatsfunktionen betroffen. Also sobald ein Statement eine beliebige Aggregsatsfunktion enthält, wird die Spalte eeeewig lang.

[mkinzler]

Schon mit CONVERT probiert?

[Sidorion]

Ich hab jetzt anders gelöst: Nach dem Ausführen des SQL-Statements weden alle Spalten auf eine einstellbare Maximalbreite beschränkt.
Die manipulation des Statements wäre viel zu umständlich gewesen, trotzdem Danke für die Ideen.

[Bernhard Geyer]

Gehst Du über den MS Provider (viel Spaß damit)?

Hier wird (bei meinem Test) als Datentyp ftBCD mit der Länge 0 zurückgeliefert.

Bei verwendung eines nativen Treibers (ist eh empfehlenswert) bekomme ich ftFloat zurück.
Ich Tippe darauf das hier der MS Provider einfach Müll produziert.

[Jasocul]

Ich habe das Problem nicht. Benutze allerdings auch kein ADO, sondern native Komponenten. Außerdem habe ich Oracle 10. Aber wie Bernhard schon andeutet, dürfte das am Daten-Provider liegen.

[Sidorion]

Ich denke mal schon, dass ich den Oracle-Treiber nehm:
Provider=OraOLEDB.Oracle

..und ADO deshalb, weils beim Kunden laufen muss und da ist nur der Oracle-Client installiert.

[Jasocul]

Bei den Arbeitsplätzen, wo meine Anwendungen laufen, ist auch nur der Client installiert.
Probier doch mal mit dem DBTools den Zugriff. Das arbeitet auch mit nativen Komponenten.
Dort kannst Du SQL-Statements eingeben. Ist zwar nicht der aktuelle Programmstand, aber ein Versuch ist es Wert.

[Sidorion]

Schicke Geschichte, die DBTools, aber leider nicht brauchbar für unsere Datenbank, da wir oft CLOB Felder haben, in denen Text steht. Diesen müssen wir aber ansehen können (kann auch der dbexplorer nicht wenns mehr als ein Feld ist).

Aber wie gesagt, ich hab jetzt ne Standardfeldlängenbegrenzung (puh langes Wort) drin.

[Jasocul]

Zitat:

Zitat von Sidorion

Schicke Geschichte, die DBTools, aber leider nicht brauchbar für unsere Datenbank, da wir oft CLOB Felder haben, in denen Text steht.

Nehme ich mal als Anregung in meine Liste auf. :wink:
Mir ging es aber im Moment nur darum, dass Du siehst, dass count(*) eine relativ kleine Spalte produziert. Dein Problem muss also etwas mit Deinen Komponenten zu tun haben.

[Sidorion]

Ich nutze die Standard ADO-Komponenten, die 'normalen' Datensensitiven kann ich nicht nutzen, da ich nicht davon ausgehen kann, dass die BDE installiert ist. Im moment werden jetzt alle Spalten auf eine Maximlabreite beschränkt, ich bin aber davon nicht wirklich begeistert, da so ja auch 'normale' Spalten begrenzt werden.

Vielleicht noch als Abregung für die DBTools: Bei meinem 'Explorer' ist unter der Ergebnisliste nochmal ein Memo, in dem der Inhalt der aktuell markierten Zelle angezeigt wird, damit kann man dann den Wert in die Zwischenablage kopieren.

[Jasocul]

Zitat:

Zitat von Sidorion

Ich nutze die Standard ADO-Komponenten, die 'normalen' Datensensitiven kann ich nicht nutzen, da ich nicht davon ausgehen kann, dass die BDE installiert ist.

Daher die Empfehlung native Komponenten zu verwenden. Die kommen ohne BDE aus.
Ich benutze Direct Oracle Access von Allround Automations in DBTools.

[mkinzler]

Zitat:

Zitat von Sidorion

Ich nutze die Standard ADO-Komponenten, die 'normalen' Datensensitiven kann ich nicht nutzen, da ich nicht davon ausgehen kann, dass die BDE installiert ist.

Davon kannst du bei ADO aber auch nicht ausgehen. Außerdem ist der direkte Weg immer der Beste.

[Sidorion]

Das Problem beim direkten Weg ist, dass ich nicht garantieren kann, dass das System auf einer Oracle-Datenbank läuft. Will heissen: Wir empfehlen unseren Kunden Oracle, aber wenn der Kunde partout eine andere Datenbank haben will, müssen wir damit leben.