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

[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...
Es gibt leider keine Persistenzschicht oder irgendein erkennbares Entwurfsmuster o.ä.

Ich frage dennoch nochmal nach: wo könnte ich die auftretende Exception anfangen?

lg Caps
ps Unser Programm ist über 20 Jahre (Windows-Version über ca. 13 Jahre "historisch gewachsen" - is there anything more to say?)


Edit: Hm, aber man müsste die originale DB ja dennoch anpassen, und da hätten wir wieder das Ressourcenproblem.

[Bernhard Geyer]

Zitat von Caps:

ps Unser Programm ist über 20 Jahre (Windows-Version über ca. 13 Jahre "historisch gewachsen" - is there anything more to say?)

Da wurde dann über die 20 Jahre vergessen grundlegende Anpassungen durchzuführen. Unsere SW ist auch schon 10++ Jahre alt und wir haben hin und wieder Umbauten durchgeführt die uns vor solchen Stoppern bewahrt haben. Was wäre wohl VW wenn Sie ihren aktuellen Golf immer noch auf dem Grundrahmen eines Golf I entwickeln würden?

[Caps]

Ja, da hast Du recht. Ein Glück, dass ich erst seit 4 Jahren dabei bin...

Hat vielleicht irgendjemand doch eine Idee, wie ich die Exception abfangen kann?

[sx2008]

Exception abfangen bringt ja nix, weil bei jeder Cursorbewegung im DBGrid könnte die Exception erneut ausgelöst werden, was zur Folge hat, dass das Grid bestenfalls nur halb angezeigt wird.
Ausserdem müsstest du die Exception innerhalb der VCL abfangen und dazu die VCL verändern.

Nein, du musst die Exception verhindern.
Im Event [TDataset].AfterOpen alle Felder die nicht interessieren mit Visible:=False unsichtbar machen.
Dann zeigt das DBGrid weniger Spalten an und verhält sich ruhig (wenn du Glück hast).