Gibt es einen bestimmten Grund dafür, dass bei einem TDBNavigator der Refreshbutton disabled ist, wenn das Dataset Readonly ist? Wie ich da einen Workaround machen kann ist mir klar (siehe http://delphi.about.com/od/adptips20...tnbrefresh.htm), mich würde nur interessieren warum das by design so ist.

Zitat von baumina:

Gibt es einen bestimmten Grund dafür, dass bei einem TDBNavigator der Refreshbutton disabled ist, wenn das Dataset Readonly ist? Wie ich da einen Workaround machen kann ist mir klar (siehe http://delphi.about.com/od/adptips20...tnbrefresh.htm), mich würde nur interessieren warum das by design so ist.

Ich vermute, darüber hat der Entwickler nicht nachgedacht. In dem entsprechenden Code-Abschnitt sind schlichtweg alle Buttons an das CanModify des DataSets gebunden. Bei Refresh macht das natürlich überhaupt keinen Sinn.

Mach doch ein QC dazu auf. Andernfalls wird sich das wohl nicht ändern.

Viele ReadOnly-Datasets machen bei einem Refesh genau gar nichts - von daher dürfte der Button auch wenig bringen.

Zitat von joachimd:

Viele ReadOnly-Datasets machen bei einem Refesh genau gar nichts - von daher dürfte der Button auch wenig bringen.

Andererseits tun viele ReadOnly-Datasets schon etwas bei einem Refresh - z.B. was die Doku sagt:

Zitat:

Aktualisiert eine Datenmenge durch erneutes Abrufen der Daten aus der Datenbank.

Insofern finde ich es schon etwas einschränkend, wenn diese Funktionalität komplett geblockt wird. Es wäre ja auch denkbar, dies von den Möglichkeiten des aktuellen DataSets abhängig zu machen.

Schon mal den DBNavigator der Jedis ausprobiert? Vielleicht hat der den Fehler ja nicht ...

Den DBNavigator verwende ich aus etlichen Gründen so gut wie gar nicht mehr bzw. habe ihn lediglich früher in Übungsprojekten, als ich mich noch ins Datenbankthema einarbeitete, eingesetzt. Wenn ich ein Refresh benötige, dann geschieht das gewöhnlich automatisiert im Hintergrund überall dort, wo die jeweilige Datenmenge tatsächlich aktualisiert werden muß (z.B. nach SQL-Statements wie Insert oder Update). Zur Not würde ich mir einen Button mit der Aufschrift Refresh auf die Form legen und in dessen Ereignisbehandlung einfach Dataset.Refresh ausführen. Auch die Buttons für First, Last, Prior und Next benötige ich nicht wirklich, da stelle ich dem Anwender lieber gleich eine entsprechende Tabelle, ein Suchformular oder ein tastengesteuertes Locate zur Verfügung.

Zitat von Perlsau:

Schon mal den DBNavigator der Jedis ausprobiert? Vielleicht hat der den Fehler ja nicht ...

Den DBNavigator verwende ich aus etlichen Gründen so gut wie gar nicht mehr bzw. habe ihn lediglich früher in Übungsprojekten, als ich mich noch ins Datenbankthema einarbeitete, eingesetzt. Wenn ich ein Refresh benötige, dann geschieht das gewöhnlich automatisiert im Hintergrund überall dort, wo die jeweilige Datenmenge tatsächlich aktualisiert werden muß (z.B. nach SQL-Statements wie Insert oder Update). Zur Not würde ich mir einen Button mit der Aufschrift Refresh auf die Form legen und in dessen Ereignisbehandlung einfach Dataset.Refresh ausführen. Auch die Buttons für First, Last, Prior und Next benötige ich nicht wirklich, da stelle ich dem Anwender lieber gleich eine entsprechende Tabelle, ein Suchformular oder ein tastengesteuertes Locate zur Verfügung.

Ich habe mich vor einiger Zeit gegen die Jedis entschieden, an die Gründe kann ich mich nur noch dunkel erinnern, war sowas wie zu viel Krimskrams, zu nervige Installation oder so, spielt ja auch keine Rolle. Fakt ist, ich habe keine Jedis.

Was den DBNavigator angeht, so habe ich den in meinen vorherigen Firmen niemals benutzt, weil er mir immer irgendwie bescheuert vorkam. In der Firma, in der ich nun seit 6 Jahren bin, kriege ich meinen Chef leider nicht (auch nicht mit Gewalt) dazu diesen abschaffen zu dürfen. *stöhn*

Sicherlich kommen auch irgendwann die Zeiten, in denen ich wieder Abstand von solchen DBNavigatoren nehmen darf.

Wenn mehrere Leute an der selben Datenbank arbeiten, ist so ein Refreshknopf kaum wegzudenken. Außer ich mache mir mal die Mühe und beschäftige mich damit, wie ich vom SQL-Server aus die Clients über Änderungen der Daten informiere und diese dann automatisch refreshe. Über dieses Thema habe ich ehrlich gesagt bislang noch gar nicht nachgedacht. Für Tipps bin ich was das angeht immer offen

Etwas OT, aber irgendwie doch auch noch zum Thema:

Den Navigator aus FMX wollte ich für meine Zwecke etwas anpassen.
Das war quasi nicht möglich. Das Teil ist so geschlossen und verzweigt aufgebaut, dass man (ich) da nicht sinnvoll aufbauen kann.
"Over-engineered" würde ich es aber auch nicht nennen, jedenfalls nicht wenn man damit Perfektionismus oder besonders hohe Qualität verbindet.

Ich habe das daher komplett und mit recht einfachem und übersichtlichem Code neu gebaut.
Die Unit sieht zwar unspektakulär aus, die Komponente lässt sich aber gut weiter ausbauen. Optisch ist sie mit dem Original identisch.

Zitat von baumina:

Sicherlich kommen auch irgendwann die Zeiten, in denen ich wieder Abstand von solchen DBNavigatoren nehmen darf.

Wie viele verschiedene hast du denn? Bei mir in der Toolpalette gibt's nur die zwei, einer von Delphi und einer von den Jedis. Übrigens hatte ich noch nie Probleme damit, die Jedis zu installieren, und auf einige Komponenten wie TJvRichEdit und DJvDBRichEdit möchte ich nicht mehr verzichten (AdvancedTypography).

Zitat von baumina:

Wenn mehrere Leute an der selben Datenbank arbeiten, ist so ein Refreshknopf kaum wegzudenken.

Was nützt der, wenn er nicht funktioniert? Ich bastle mir immer meinen eigenen DB-Navigator, da weiß ich, was ich habe bzw. was der tut.

Zitat von baumina:

Außer ich mache mir mal die Mühe und beschäftige mich damit, wie ich vom SQL-Server aus die Clients über Änderungen der Daten informiere und diese dann automatisch refreshe. Über dieses Thema habe ich ehrlich gesagt bislang noch gar nicht nachgedacht. Für Tipps bin ich was das angeht immer offen

Ich kann dir das jetzt auch nicht im Einzelnen sagen, weiß aber, daß SQL-Server zahlreiche Funktionen, Proceduren und Trigger gespeichert hat. Letztere sind dafür zuständig, daß z.B. nach Datenmanipulation irgend was geschieht, z.B. eine Message an Clients versenden. Bei Firebird weiß ich, wie ich solche MGSs sende und empfange, bei SQL-Server muß ich mir das auch erst noch aneignen, z.B. da.

Einen großen Vorteil haben meine eigenen DB-"Navigatoren" auf jeden Fall: Ich hab z.B. etliche Projekte, in denen der Anwender mehrere Tabellen via Formular pflegen kann/soll/darf/muß. Für all diese Tabellen, deren Formulare auf TabSheets eines TPageControls liegen, hab ich nur einen einzigen DBNavigator. Abhängig vom PageIndex des PageControls wird dann diese oder jene Tabelle bearbeitet, erweitert usw. Das ist ungemein praktisch, weil ich so immer dieselben Funktionen verwenden kann und nicht x-mal Dataset.Edit, Dataset.Append, Dataset.Post, Dataset.Cancel und Dataset.Delete schreiben muß. Bei Append, Edit und Delete wird einfach das Dataset festgelegt, auf das dann auch Post und Cancel zugreifen. Natürlich muß man dafür sorgen, daß der Anwender nach Append und Edit nicht die Tabelle (bzw. das Tabsheet mit dem Formular) wechseln kann.