DBGrid schmiert ab bei "SHOW CREATE TABLE"

[Caps]

Guten Tach,

ich verwende das Bordmittel TDBGrid und bin auf folgendes Problem gestoßen:
Beim Ausführen der Query "SHOW CREATE TABLE <Tabellenname>" tritt eine AV auf, und die Anwendung wird beendet.

Aller Wahrscheinlichkeit tritt der Fehler auf in der Methode TCustomDBGrid.DrawCell in der Unit DBGrids, und zwar in der Zeile

Code:

Value := DrawColumn.Field.DisplayText;

beim Schreiben des Inhaltes der zweiten Datenzelle (also der Zelle, wo der SQL zum Erzeugen der Tabelle hineinkommt).

Der Fehler trat zunächst nur bei einer Tabelle (Tabelle 1) auf, weshalb ich vermutete, dass evtl. die Tabelle kaputt sein könnte o.ä., jedoch trat er parallel auch in verschiedenen Versionen der gleichen DB auf, d.h. die Tabelle 1 hätte in jeder DB kaputt sein müssen.
Zu guter Letzt habe ich irgendeine andere Tabelle (Tabelle 2) verbreitert, indem ich einige Felder angehängt habe, so dass Tabelle 2 insg. 210 Felder enthielt; dann ist der Fehler auch bei Tabelle 2 aufgetreten.
Bei Tabelle 1 lässt sich der Fehler zuverlässig dadurch erzeugen bzw. vermeiden, dass man zwischen 157 und 158 Feldern wechselt. D.h. füge ich ein Feld hinzu (insg. 158 Felder), so tritt der Fehler auf; lösche ich das Feld wieder, so tritt der Fehler nicht mehr auf.

Ich vermute also einen Zusammenhang zwischen der Breite der Tabelle und dem Fehler.

Frage: kennt das jemand? Was kann man dagegen tun?
<vorwegnehm>Ja, das CPU-Fenster geht auf, und ja, ich fühle mich wie ein Schwein angesichts eines Uhrwerks. </vorwegnehm>
Frage 2: Das Query.Execute steht bereits in einem try...except-Block. Angenommen ich möchte die Exception fangen, damit nicht das ganze Programm in den Boden gerissen wird - wo sollte ich damit am besten anfangen?

Beste Grüße
Caps

[Bernhard Geyer]

Wenn du wirklich D5 verwendest wird es mal zeit auf eine neuere Delphi-Version zu wechseln.
Ich könnte mir vorstellen das in den Steinzeit-Sourcen von D5 noch einige Uraltfehler mit zu kleinen Puffergrößen vorliegen. Dein nachvollziehbares Fehlverhalten ab 158 Felder deutet ja auch darauf hin das *irgendein* Puffer zu klein dimensioniert ist.

[Caps]

Zitat von Bernhard Geyer:

Wenn du wirklich D5 verwendest wird es mal zeit auf eine neuere Delphi-Version zu wechseln.
Ich könnte mir vorstellen das in den Steinzeit-Sourcen von D5 noch einige Uraltfehler mit zu kleinen Puffergrößen vorliegen. Dein nachvollziehbares Fehlverhalten ab 158 Felder deutet ja auch darauf hin das *irgendein* Puffer zu klein dimensioniert ist.

Jaja, wie Recht Du hast, aber da gibt es ein personelles Ressourcenproblem bei der Umstellung auf eine neue Delphi-Version. Dass das eine Zeitbombe ist, ist mir völlig klar, aber hm - tja.

Aber danke... Puffergröße... klingt nicht so einfach.

Hättest Du noch ne Idee, an welcher Stelle ich die Exception abfangen könnte?
Sollte ich versuchen, die Unit zu hacken, und die betreffende Methode mit try...except zu versorgen?

[sx2008]

Warum hast du denn Tabellen mit so vielen Feldern?
Ist da wirklich alles in der 3. Normalform?

[Caps]

Zitat von sx2008:

Warum hast du denn Tabellen mit so vielen Feldern?
Ist da wirklich alles in der 3. Normalform?

Allerhöchstwahrscheinlich nicht. Aber nehmen wir einmal an es wäre in der 3. Normalform. Dann bestünde das Problem dennoch.

Es gibt gewisse personelle Ressourcenprobleme bzgl. der Umstellung der Tabellen in irgendeine Normalform, weil an gefühlt einer Milliarde Stellen in unserem Programm auf ein bestimmtes Feld einer bestimmten Tabelle zugegriffen wird.

lg Caps

[p80286]

Zitat von Caps:

.....der Tabellen in irgendeine Normalform, weil an gefühlt einer Milliarde Stellen in unserem Programm auf ein bestimmtes Feld einer bestimmten Tabelle zugegriffen wird.

Dann bastelt man einen view der so riecht und schmeckt wie die alte DB und unter der Haube werkelt eine ordentlich designte DB.

Gruß
K-H

[Perlsau]

Probiere doch einmal, ob es mit der Jedi-Variante des DBGrids (TjvDBGrid) funktioniert.

Zitat von Caps:

Die Möglichkeit mit den Views muss ich mal betrachten, obwohl ich mich frage, ob die Verwendung mit Lesen/ Schreiben/ Felder anlegen/ etc. dann so reibungslos auf der View funktioniert...

Ein View kannst du nicht updaten, das ist einfach ein select in der Datenbank und dient lediglich der Darstellung.

[Perlsau]

Zitat von Smut:

Zitat von Perlsau:

Ein View kannst du nicht updaten, das ist einfach ein select in der Datenbank und dient lediglich der Darstellung.

Hier wird etwas geschrieben über updatable views:

http://ibexpert.net/ibe/index.php?n=Doc.View#Updatable

... und auch beim Gockel werde ich da fündig...

Was hast du denn da schönes gefunden? Etwa daß du ein View genau so behandeln kannst wie eine Tabelle? Wie sollte das gehen?

Wenn du mal genau lesen würdest: Ich hatte geschrieben, ein View kannst du nicht updaten. Der Datenbank-Server kann das natürlich und muß das ja auch können. Intern wird dabei einfach der Select-Befehl, der dem View zugrundeliegt, ausgeführt. Ein View ist praktisch ein Select-Konstrukt, das der Client nicht ändern, sondern lediglich abrufen kann – ein aus Sicht des Clienten fest verdrahtetes Select sozusagen.

Du selbst bzw. der Client kann lediglich die Values der dem View zugrundeliegenden Spalten updaten, wenn du/er Zugriff darauf hat. In manchen Arbeitsumgebungen werden nur die Resultate von Views dargestellt, die vorgefertigte (eben fest verdrahtete) Selects ausführen. Das Update des View erfolgt dabei automatisch, sobald ein Client die zugrundeliegenden Tabellen geändert hat. Gegebenenfalls mußt du in deiner Client-Application ein Refresh auf dein View-Query ausführen, um diese Änderungen auch mitzukriegen.