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. :gruebel:</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:

Zitat von Bernhard Geyer (Beitrag 1223492)

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:

Zitat von sx2008 (Beitrag 1223518)

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. :lol:

lg Caps

[p80286]

Zitat:

Zitat von Caps (Beitrag 1223519)

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

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?):kotz:


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

[Bernhard Geyer]

Zitat:

Zitat von Caps (Beitrag 1223528)

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

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... :mrgreen:

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

Delphi-Quellcode:

Visible:=False

unsichtbar machen.
Dann zeigt das DBGrid weniger Spalten an und verhält sich ruhig (wenn du Glück hast).

[Caps]

Ja, das blöde ist, dass eigentlich nur zwei Spalten angezeigt werden sollen:

Spalte1: "Table"
Spalte2: "Create Table"

Beim Zeichnen der zweiten Spalte knallt es. Keinen Schimmer warum. Die CREATE-TABLE-Anweisung ist eigentlich auch nicht besonders lang. Es kann höchstens sein, dass er im Hintergrund die Spalten der Tabelle auflistet und irgendwo hineinschreibt, wo dann ein Überlauf auftritt o.ä.

Ich hab die kritische Zeile schon zwischen try und except gepackt - die Anwendung wurde dennoch beendet.

Hmpf! :wall:

[Bernhard Geyer]

Zitat:

Zitat von Caps (Beitrag 1223562)

Beim Zeichnen der zweiten Spalte knallt es. Keinen Schimmer warum. Die CREATE-TABLE-Anweisung ist eigentlich auch nicht besonders lang. Es kann höchstens sein, dass er im Hintergrund die Spalten der Tabelle auflistet und irgendwo hineinschreibt, wo dann ein Überlauf auftritt o.ä.

Was für Feldtypen haben die zurückgemeldeten Spalten und wie lange sollen diese laut Delphi TFields-Klasse sein?

Bei MySQL wir öfter mal MySQL-interne Strukturen geändert so das hier mist zurück kommt (Gab mal eine Version in der alle varchar-Spalten als blob gemeldet wurde).

[Perlsau]

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

Zitat:

Zitat von Caps (Beitrag 1223528)

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:

Zitat von Smut (Beitrag 1223591)

Zitat:

Zitat von Perlsau (Beitrag 1223587)

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.

[Caps]

Ja, ähm, danke auch für die späteren Antworten gestern...

Also in Bezug auf Views habe ich erfahren, dass nur bei einer eindeutigen Zuordenbarkeit eines Feldes zu einer physischen Tabelle ein Update ausgeführt werden kann. Das ist in meinem Fall im allgemeinen nicht gegeben. Außerdem wollen wir nicht unsere 10^42 Tabellen umstrukturieren, genausowenig wie die Sprache wechseln oder die Sprachversion - leider. Ich kann da nichts ausrichten, das muss jemand anders entscheiden.

Ich fasse mal zusammen:
- Komponente austauschen muss ich probieren (MDBGrid, Jedi, etc)
- Views sind keine Lösung
- Ich habe noch nicht ganz aufgegeben an der Exception-Front. Das Ding muss doch zu fangen sein! (*)

So far.
Thx, Caps

(*) Also: ich weiß, dass es eine dumme Idee ist, die VLC-Units zu ändern, aber man muss sehen, welcher Weg praktikabel ist...