DBGrid sortieren (SQL)
Ralf Schmitt
in einer Anwendung (Delphi 5) verwende ich ein DBGrid (bzw. RXDBGrid), das
von einem Query beliefert wird.
Zum Sortieren übermittel ich in "OnTitleClick" per SQL "select * "blabla.db"
ORDER BY <FELD> ASC (oder DESC).
Klappt alles wunderbar ...
Nur kann ich nun keine Datensätze mehr bearbeiten, denn die Daten werden im
"Nur-Lesemodus" geliefert.
Nun suche ich einen Rat, wie ich jetzt am besten vorgehe, um die Daten
editierbar zu machen, ohne per "select * "blabla.db" alle Datensätze
anzeigen zu lassen (denn dann sind seltsamerweise die Daten editierbar).
Zuvor hatte ich mit TTable gearbeitet, aber da ich nun auf 25 Felder einen
Index setzen musste, damit ich das DBGrid sortieren konnte, aber dieses
vielen Indizies nicht gerade zur Stabilitä beitrugen, bin ich nun auf TQuery
umgestiegen ....
Besten Dank schon mal für alle Tipps und jeden Schubs in die richtige
Richtung!
Gruß
Ralf
--
Ralf Mimoun
Ralf Schmitt wrote:
> Hallo Menschen hier im Forum,
>
> in einer Anwendung (Delphi 5) verwende ich ein DBGrid (bzw.
> RXDBGrid), das von einem Query beliefert wird.
> Zum Sortieren übermittel ich in "OnTitleClick" per SQL "select *
> "blabla.db" ORDER BY <FELD> ASC (oder DESC).
> Klappt alles wunderbar ...
>
> Nur kann ich nun keine Datensätze mehr bearbeiten, denn die Daten
> werden im "Nur-Lesemodus" geliefert.
Logisch. Wenn kein entsprechender Index existiert, kann das DB-System keine
lebende Datenmenge zurückliefern. Und auch wenn es den Index gibt, kann es
nicht jedes DB-System. Und bei einigen sind auch nicht-lebende Datenmengen
nicht per se schreibgeschützt. Wieso verrätst Du uns nicht einfach, was Du
einsetzt?
> Nun suche ich einen Rat, wie ich jetzt am besten vorgehe, um die Daten
> editierbar zu machen, ohne per "select * "blabla.db" alle Datensätze
> anzeigen zu lassen (denn dann sind seltsamerweise die Daten
> editierbar).
Nichts ist da seltsam. Du kannst z.B. ein Grid nehmen, das selbst sortieren
kann (z.B. ExpressQuantum Grid), aber dann muß es alle Daten ziehen. Bei ein
paar 100 Datensätzen ist das noch kein Problem, bei ein paar 1000 meistens
schon.
Oder Du erzeugst die fehlenden Indizes. Oder Du baust Komponenten zum
Editieren ein und koppest deren Dataset an das Query. Wahrscheinlich gibt es
noch ein paar mehr gangbare Möglichkeiten.
Ach ja, und wenn Du BDE/Paradox benutzt, ist sowieso jede weitere Diskussion
sinnfrei, denn dann solltest Du erstmal dieses Problem lösen :-)
Bye, Ralf
Ralf Schmitt
news:d823gq$5dm$1...@newsreader3.netcologne.de...
> Moin!
[...]
> Ach ja, und wenn Du BDE/Paradox benutzt, ist sowieso jede weitere
> Diskussion sinnfrei, denn dann solltest Du erstmal dieses Problem lösen
> :-)
>
> Bye, Ralf
Hallo Ralf,
danke für deine schnelle Antwort!
Jau, ich verwende tatsächlich Paradox und die BDE. Ist wohl in der heutigen
Zeit eine Straftat?!?!? :-)
Was würdest du sinnvollerweise einsetzen, ohne die gesamte Anwendung neu
schreiben zu müssen?
Ist ADO eine Alternative? Ist der Aufwand für den "Umbau" sehr groß. Also
unterscheidet sich das System sehr von BDE/TTable usw?!
Welche Angaben bräuchtest du, um eine sinnvolle Empfehlung zu geben?
Gruß
Ralf
Erich Günthner
ich habe früher mit Paradox und DBase gearbeitet.
Jetzt setze ich MSQL ein (ADO).
Wenn du ADO verwendest, musst du alle Tabellen und Querys gegen TADOTable
und TADOQuery austauschen.
Ferner brauchst du für deine VDB-Verbindung eine TADOConnection.
Ich bin mit ADO recht zufrieden.
Geht das Sortieren zum Beispiel bei einer TADOTable-Komponente über die
Eigenschaft "Sort".
(TabAdressen.Sort := 'Vorname; Nachname')
In wieweit hier die zugrundliegende Datenbank einen Einfluss hat weiß ich
nicht.
Wie gesagt, wir verwenden MSQL, und geht prima.
Gruß
Erich
"Ralf Schmitt" <ra...@schmittbit.de> schrieb im Newsbeitrag
news:d823qv$1822$1...@ulysses.news.tiscali.de...
Ralf Mimoun
Ralf Schmitt wrote:
...
> Jau, ich verwende tatsächlich Paradox und die BDE. Ist wohl in der
> heutigen Zeit eine Straftat?!?!? :-)
Wenn nicht, sollte es eine werden. Ernsthaft. Du holst Dir tonnenweise
Probleme ins Haus (insbesondere Stabilität und Datensicherheit), die Du
bestimmt nicht haben willst.
> Was würdest du sinnvollerweise einsetzen, ohne die gesamte Anwendung
> neu schreiben zu müssen?
Es gibt einige DB-Systeme, auf die man von Paradox recht schnell wechseln
kann, z.B. DBISAM und NexusDB. Ich bevorzuge DBISAM (www.elevatesoft.com).
Das Umstellen einer größeren Anwendung kann man mit etwas Übung innerhalb
einiger Stunden hinter sich bekommen. Danach noch weitere Tests, ich würde
das Programm nicht am selben Nachmittag auf den Kunden loslassen.
Einige Vorteile von DBISAM: integriert sich komplett in die EXE (keine BDE
oder sonstwas), schnell, stabil, ist innerhalb von Minuten auf C/S
umgestellt (wenn man will, man muß nicht), perfekter Support und so weiter.
Ich nutze es seit Jahren ohne Probleme.
> Ist ADO eine Alternative?
ADO ist "nur" eine Zugriffsschicht, kein DB-System (ich laß man den
Namensspaß, den sich MS gegönnt hat, außen vor). Du mußt dafür sorgen, daß
auf dem Zielrechner alles installiert ist, was Du so benötigst. In der
richtigen Version. Macht nicht jedem Spaß.
...
> Welche Angaben bräuchtest du, um eine sinnvolle Empfehlung zu geben?
Wenn Du von Paradox kommst, kann ich blind DBISAM empfehlen. Was bei Paradox
geht, geht mit DBISAM allemal - nur besser.
Bye, Ralf
Joachim Duerr
> Wenn kein entsprechender Index existiert, kann das DB-System keine
> lebende Datenmenge zurückliefern.
warum denn nicht?
--
Joachim Dürr
Advantage Database Server Support Lead (EMEA)
Advantage[at]extendsys.de
Joachim Duerr
> in einer Anwendung (Delphi 5) verwende ich ein DBGrid (bzw.
> RXDBGrid), das von einem Query beliefert wird.
> Zum Sortieren übermittel ich in "OnTitleClick" per SQL "select *
> "blabla.db" ORDER BY <FELD> ASC (oder DESC).
> Klappt alles wunderbar ...
>
> Nur kann ich nun keine Datensätze mehr bearbeiten, denn die Daten
> werden im "Nur-Lesemodus" geliefert.
eventuell RequestLive der Query auf false?
Ralf Mimoun
Joachim Duerr wrote:
> Ralf Mimoun schrieb in <d823gq$5dm$1...@newsreader3.netcologne.de>:
>
>> Wenn kein entsprechender Index existiert, kann das DB-System keine
>> lebende Datenmenge zurückliefern.
>
> warum denn nicht?
Ok, es kann keine Datenmenge zurückgeliefert werden, dessen Änderungen dann
in den Quelltabellen landen. Sowas wie
SELECT SUM(a.x) AS Summe, b.y FROM a INNER JOIN b ON b.aID=a.ID GROUP BY...
[man füge nach Belieben noch UNION u.ä. hinzu]
usw. dröselt wohl kaum ein DB-System soweit auf, daß beim Editieren per
TDBEdit wirklich etwas Sinnvolles in a oder b landet. Daß die
zurückgelieferte Datenmenge editiert weren kann, solange das Query nicht
geschlossen wird, hilft in den wenigsten Fällen weiter.
Bye, Ralf
Joachim Duerr
> Ok, es kann keine Datenmenge zurückgeliefert werden, dessen
> Änderungen dann in den Quelltabellen landen. Sowas wie
>
> SELECT SUM(a.x) AS Summe, b.y FROM a INNER JOIN b ON b.aID=a.ID GROUP
> BY... [man füge nach Belieben noch UNION u.ä. hinzu]
>
> usw. dröselt wohl kaum ein DB-System soweit auf, daß beim Editieren
> per TDBEdit wirklich etwas Sinnvolles in a oder b landet. Daß die
> zurückgelieferte Datenmenge editiert weren kann, solange das Query
> nicht geschlossen wird, hilft in den wenigsten Fällen weiter.
das ist jetzt aber was anderes. Vorhin ging es noch um
SELECT * FROM mytable ORDER BY feld_da_wo_kein_index_drauf_existiert
<OT>...und wenn wir schon bei SQL und komischen Gebilden sind: ADS wird
in der nächsten Version komplexe VIEWS (so wie oben) über Trigger
beschreibbar bekommen...</OT>
Ralf Mimoun
Joachim Duerr wrote:
...
> das ist jetzt aber was anderes. Vorhin ging es noch um
> SELECT * FROM mytable ORDER BY feld_da_wo_kein_index_drauf_existiert
Ok. Einige DB-Systeme können es, andere nicht. ADS kann es wohl :-) Ist ja
auch ein gutes System, nur nicht das, was ich einsetze. Es wäre auch zu
langweilig (außer für Extended Systems natürlich :-), wenn alle das gleiche
nehemn würden...
Bye, Ralf
Dietmar Brueckmann
> "Ralf Mimoun" <nos...@rad-on.de> schrieb im Newsbeitrag
> Jau, ich verwende tatsächlich Paradox und die BDE. Ist wohl in der heutigen
> Zeit eine Straftat?!?!? :-)
Es ist keine Straftat, sondern schon die Strafe selbst.
> unterscheidet sich das System sehr von BDE/TTable usw?!
Das entscheidende Problem ist der excessive Gebrauch von TTable. Mit
Paradox total praktisch - bei kleinen Projekten.
In "richtigen" Projekten (SQL-Datenbanken wie Oracle, Interbase ...)
beschafft man fast alle Daten mit SELECT. Du stößt jetzt mit Paradox an
die Grenze, wo du editierbare Datenmengen mit SELECT beschaffen möchtest.
Borland bietet dafür das TClientDataset-Konzept an. Passend für alle(?)
Datenbanken. Ein TClientDataset ist editierbar, sortierbar und kann alle
Änderungen puffern, bis Du speichern sagst. Ein Haufen Arbeit ein
Projekt umzustellen - man muß nämlich radikal die Konzepte ändern, sonst
wird es nur Krampf. Macht man das konsequent, lohnt sich die Arbeit.
Neue Projekte werden einfacher und komfortabler.
Da man sich mit theoretischen Ansätzen befassen muß, merkt man mit
einmal, dass die Frage nach der Datenbank sekundär wird. Irgendwann
stolpert man über Ansätze wie "Object Persistence Framework".
In dieser Gruppe ist aktuell grade dazu ein Thread "OO-Schicht ..."
(Christian Gudrian, 2007-06-07), der ein paar Beispiele andeutet, wie
man die Objekte von der Datenbank trennt.
--
Mit freundlichen Gruessen
Dietmar Brueckmann
Ralf Schmitt
"Joachim Duerr" <jojo....@gmx.de> schrieb im Newsbeitrag
news:3gl8o2F...@individual.net...
>> werden im "Nur-Lesemodus" geliefert.
>
> eventuell RequestLive der Query auf false?
> --
> Joachim Dürr
> Advantage Database Server Support Lead (EMEA)
> Advantage[at]extendsys.de
[.....]
Hallo und moin ihr alle!
Danke euch für eure rege Teilnahme an der Diskussion.
@Joachim
RequestLive ist auf "true".
Trotzdem sind die Daten nur editierbar, wenn ich die alle Datensätze mit
"select * from table" durchführe.
Sobald ich auch nur ein "where feld=xxx" einfüge ist's mit der
Editierbarkeit dahin.
Also mein Verständnis und Wissen reicht nicht dazu aus, dies
nachzuvollziehen, zumal die Abfrage sich rein auf eine einzige Tabelle
beschränkt.
Schade eigentlich, denn mir hätte dieses "System" eigentlich erstmal
gereicht und ich hätte mich dan immer noch in aller Ruhe um einen
kompletten Umbau kümmern können. So stehe ich nun doof da, bin etwas unter
Zeitdruck und habe leider schon alles auf SQL umgestrickt. Okay, ich hätte
micht vorher informieren können, aber an sowas, dass sich Daten plötzlich
nicht mehr editieren lassen hatte ich nicht gedacht.
@Ralf
Habe mir nun mal DBISAM heruntergeladen und werde mir das mal ansehen.
Vielleicht war ja mein Geheule umsonst und ich finde darin die Lösung meines
Problems?!
Werde berichten ... :-)
@all
Sollte aber doch jemand noch eine Idee haben, wie ich mein jetziges System
erstmal beibehalten kann, so wäre ich für jeden weiteren Tipp überaus
dankbar!
Grüße an euch und den Rest der Welt
Ralf
Ralf Schmitt
> Ok. Einige DB-Systeme können es, andere nicht. ADS kann es wohl :-) Ist ja
> auch ein gutes System, nur nicht das, was ich einsetze. Es wäre auch zu
> langweilig (außer für Extended Systems natürlich :-), wenn alle das
> gleiche nehemn würden...
[...]
Hallo,
nach dem Rat von Ralf habe ich mir vorhin DBISAM geladen und installiert.
Also die Installation ging in Sekunden und konnte auch recht schnell das
query einbauen.
Mit dem Erfolg, dass der Datensatz sich zwar beim Ändern der Daten in z.B.
einem DBEdit in den Editiermodus schaltet und nach dem Speichern auch alles
fein übernommen scheint. Nachdem ich die Daten aber neu lade, ist alles
wieder beim alten.
Ich verweifel langam. ....
Also bitte helft mir mal auf die Sprüngen, denn irgendwie kriegt mein
kleines Hirn das alles nicht auf die Reihe ...
Gruß
Ralf
Ralf Mimoun
Ralf Schmitt wrote:
...
> nach dem Rat von Ralf habe ich mir vorhin DBISAM geladen und
> installiert. Also die Installation ging in Sekunden und konnte auch
> recht schnell das query einbauen.
> Mit dem Erfolg, dass der Datensatz sich zwar beim Ändern der Daten in
> z.B. einem DBEdit in den Editiermodus schaltet und nach dem Speichern
> auch alles fein übernommen scheint. Nachdem ich die Daten aber neu
> lade, ist alles wieder beim alten.
Ach. Ich habe doch geschrieben, daß ohne entsprechenden Index viele
DB-Systeme (unter anderen DBISAM) eben keine lebende Datenmenge liefern.
Schau Dir mal RequestLive und ResultIsLive an.
Bye, Ralf
Ralf Schmitt
> Moin!
> Ach. Ich habe doch geschrieben, daß ohne entsprechenden Index viele
> DB-Systeme (unter anderen DBISAM) eben keine lebende Datenmenge liefern.
> Schau Dir mal RequestLive und ResultIsLive an.
>
> Bye, Ralf
Hallo,
also mal ganz klar gefragt:
Die eine Tabelle der Datenbank hat etwa 35 Felder.
Muss ich nun wieder für jedes Feld einen Index anlegen?
Woebi ich es schon mit Sekundärindex versucht hatte, ohne Erfolg jedoch.
So hatte ich das mal, was aber dazu führte, dass das Speichern eines
Datensatzes bei einer Tabellengröße von z.B. 50.000 Datensätzen ewig lange
dauerte. Da die Anwendung aber sehr viele Datensätze innerhalb kürzester
Zeit programmseitig zugespielt bekommt (insert und edit), haut das eben
alles nicht hin.
Wo bitte ist mei Denkfehler an der ganzen Sache????
Gruß
Ralf
Ralf Mimoun
Ralf Schmitt wrote:
...
> also mal ganz klar gefragt:
>
> Die eine Tabelle der Datenbank hat etwa 35 Felder.
> Muss ich nun wieder für jedes Feld einen Index anlegen?
Für jedes, nach dem Du sortieren willst, ja. Zumindest, wenn Du den von Dir
genannten Weg gehen willst. Es geht auch per TClientDataset, wird von DBISAM
unterstützt. Oder Du läßt nicht im Grid editieren, sondern in einem 2.
Dataset, das Du an das erste bindest. Wie schon geschrieben.
> Woebi ich es schon mit Sekundärindex versucht hatte, ohne Erfolg
> jedoch.
Inwiefern? Du benötigst einen Index für jedes Feld, nicht einen mit allen
Feldern. Und der Index muß passen, d.h. wenn Du im Query case-insensitiv
sortierst, brauchst Du einen entsprechenden Index. Ein case-sensitiver nutzt
Dir dann nichts. Und Du mußt RequestLive auf True setzen.
Oder Du läßt das alles und überläßt das Sortieren dem Grid. Habe ich auch
schon geschrieben.
> So hatte ich das mal, was aber dazu führte, dass das Speichern eines
> Datensatzes bei einer Tabellengröße von z.B. 50.000 Datensätzen ewig
> lange dauerte.
Bei DBISAM? Sicher? 35 Indizes sind da, wenn auch selten sinnvoll, kein
Problem.
...
> Wo bitte ist mei Denkfehler an der ganzen Sache????
Keine Ahnung, ohne Sourcen kann man dazu nicht viel sagen. Also: welches
Statement setzt Du beim Klicken auf den Gridheader ab? Wie sieht der Query
Plan für ein solches Statement aus?
Bye, Ralf
Dietmar Brueckmann
>
> Sollte aber doch jemand noch eine Idee haben, wie ich mein jetziges System
> erstmal beibehalten kann, so wäre ich für jeden weiteren Tipp überaus
> dankbar!
Erfahrung mit Paradox, nutze diese Lösung mit TQuery für Oracle).
Wenn es nur um ein SELECT geht, ist das auch kein Aufwand. Es sieht nur
beim ersten Mal ziemlich übertrieben aus:
TQuery --> TDatasetProvider --> TClientDataset --> TDatasource.
TQuery übernimmt das SQL, TClientDataset wird editiert und bietet die
Daten zum Zeigen an.
Frage, falls Dich das interessiert.
Joachim Duerr
> Sollte aber doch jemand noch eine Idee haben, wie ich mein jetziges
> System erstmal beibehalten kann, so wäre ich für jeden weiteren Tipp
> überaus dankbar!
Nachdem Ralf nicht helfen kann, mach ich halt auch mal Werbung;)
Beim Advantage Database Server sind solche Queries auf jeden Fall
editierbar. Der Local Server kommt mit den Komponenten, beides ist
kostenlos (http://www.extendedsystems.de/getadvantage).
Für die BDE-Komponenten gibt es entsprechenden Ersatz
(TTable->TAdsTable, TQuery->TAdsQuery, TStoredProc->TAdsStoredProc,...)
und der Umbau braucht somit nicht länger als zu DBISAM...nur mit dem
Vorteil, dass Du viel mehr Features hast. Auf
http://ads.extendsys.de/main.php?page=publications gibt es einige
Artikel aus Entwickler und Toolbox zur Einführung.
Ach ja: Redistribution sind nur 3 DLLs und ein paar Config-Dateien
(kopieren ins Programmverzeichnis reicht).
Ralf Schmitt
"Dietmar Brueckmann" <Dietmar.B...@lycos.de> schrieb im Newsbeitrag
news:42a68...@news.arcor-ip.de...
> Eine Zwischenlösung sollte mit TClientdataset gehen (Ich habe keine
> Erfahrung mit Paradox, nutze diese Lösung mit TQuery für Oracle).
> Wenn es nur um ein SELECT geht, ist das auch kein Aufwand. Es sieht nur
> beim ersten Mal ziemlich übertrieben aus:
> TQuery --> TDatasetProvider --> TClientDataset --> TDatasource.
> TQuery übernimmt das SQL, TClientDataset wird editiert und bietet die
> Daten zum Zeigen an.
> Frage, falls Dich das interessiert.
Hallo Dietmar,
nun habe ich es auf diesem Wev versucht, allerdings mit dem gleichen
"Erfolg", dass die Daten sich zwar editieren lassen, nach dem erneuten Laden
aber wieder die alten Werte haben.
Also entweder bin ich zu blöd, dass alles zu vestehen oder aber zu doof!?
Aber ist meine Anwendung denn so exotisch?
Es gibt ein DBGrid, in dem die abgerufenen Datensätze angezeigt und sortiert
weren können. Und dann gibt es Edits, in denen man den aktuell markierten
datensatz angezeigt bekommt. Und in den edits soll man einfach die Daten
ändern können.
Das muss doch irgendwie ohne große Probleme machbar sein ...
Gruß
Ralf
Ralf Schmitt
>> So hatte ich das mal, was aber dazu führte, dass das Speichern eines
>> Datensatzes bei einer Tabellengröße von z.B. 50.000 Datensätzen ewig
>> lange dauerte.
>
> Bei DBISAM? Sicher? 35 Indizes sind da, wenn auch selten sinnvoll, kein
> Problem.
Hallo!
Sinnvoll dann, wenn es dem Anwender ermöglicht werden soll (muss), dass er
nach allen Feldern sortieren kann.
Wenn ich nun für jedes Feld einen Index erstelle, muss es diesen dann sowl
für abwärts als auch aufwärts sortiert geben?
Darf/soll der jeweilige Index gewartet sein?
Was für einen Vorteil bringt mir dann ein Query? Wäre dann nicht auch
TTable mit entsprecheden Filtern (wie ich es urspsrünglich mal hatte) die
bessere Wahl?
Ich lerne gerne dazu ... :-)
Gruß
Ralf
Ralf Mimoun
Ralf Schmitt wrote:
...
> Sinnvoll dann, wenn es dem Anwender ermöglicht werden soll (muss),
> dass er nach allen Feldern sortieren kann.
Wenn ein Benutzer nach 35 Feldern sowohl aufwärts als auch abwärts sortieren
will, ist das normalerweise nicht sinnvoll. Ich nehme dann das EQGrid und
habe meine Ruhe.
...
> Was für einen Vorteil bringt mir dann ein Query? Wäre dann nicht auch
> TTable mit entsprecheden Filtern (wie ich es urspsrünglich mal hatte)
> die bessere Wahl?
Ganz einfach: falsche Erwartungen. Wenn der Benutzer wirklich alle
Freiheiten haben will (z.B 100.000 Datensätze im Grid "gleichzeitig" sehen,
nach allen Feldern beliebig sortieren und auch noch dadrin editieren), dann
ist das schlicht mit einer Zeitstrafe verbunden. Ist es unbedingt notwendig,
daß der Benutzer wirklich im Grid editiert? Weiterhin wurdest Du schon aut
TClientDataset hingewiesen.
Bye, Ralf
Ralf Mimoun
Ralf Schmitt wrote:
...
> Es gibt ein DBGrid, in dem die abgerufenen Datensätze angezeigt und
> sortiert weren können. Und dann gibt es Edits, in denen man den
> aktuell markierten datensatz angezeigt bekommt. Und in den edits soll
> man einfach die Daten ändern können.
>
> Das muss doch irgendwie ohne große Probleme machbar sein ...
Natürlich. Aber dazu hättest Du eben schreiben sollen, daß Du nicht im Grid
editierst. Was Du hinbekommen willst ist simpel zu erreichen. Die Sortierung
erschlägst Du über ein Query. Indexe brauchst Du nur, wenns zu langsam wird.
Dann nimmst Du ein Table oder ein Live Query, das Du per Master/Detail an
das erste Query hängst, und zwar über Deinen Primärschlüssel. In diesem
zweiten Dataset editierst Du, d.h. Du verbindest Deine Edits über eine
DataSource mit diesem Dataset. Nach jedem Post mußt Du das Query neu
ausführen und zum letzten Datensatz springen. Deletes betreffen das
Detail-Dataset, auch danach Query neu ausführen.
Es gibt elegantere Wege, aber der oben beschriebene ist schnell umgesetzt.
Bye, Ralf
Ralf Schmitt
> Ganz einfach: falsche Erwartungen. Wenn der Benutzer wirklich alle
> Freiheiten haben will (z.B 100.000 Datensätze im Grid "gleichzeitig"
> sehen, nach allen Feldern beliebig sortieren und auch noch dadrin
> editieren), dann ist das schlicht mit einer Zeitstrafe verbunden. Ist es
> unbedingt notwendig, daß der Benutzer wirklich im Grid editiert? Weiterhin
> wurdest Du schon aut TClientDataset hingewiesen.
Salve!
Zunächst hatte ich ja bereits erwähnt, dass die Daten nicht im Grid selbst
geändert werden sollen, sondern sie werden dort nur angezeigt. Geändert
werden sie in entsprechenden TEdit's usw, in denen dann die Daten des
markierten datensatzes angezeigt werden.
Der Hinweis auf TClientDataset hat mich irgendwie nicht weitergebracht.
Mir wäre ein Beispiel ganz recht, aus dem ich ersehen kann, was womit
verbunden wird etc.
Also ausgehend davon, dass es eben dieses DBGrid und die TEdit's gibt.
Danke und Gruß
Ralf
Ralf Schmitt
> Natürlich. Aber dazu hättest Du eben schreiben sollen, daß Du nicht im
> Grid editierst.
Hatte ich das nicht!? Dumm gelaufen .... schlag' mich! :-)
> Was Du hinbekommen willst ist simpel zu erreichen. Die Sortierung
> erschlägst Du über ein Query. Indexe brauchst Du nur, wenns zu langsam
> wird. Dann nimmst Du ein Table oder ein Live Query, das Du per
> Master/Detail an das erste Query hängst, und zwar über Deinen
> Primärschlüssel. In diesem zweiten Dataset editierst Du, d.h. Du
> verbindest Deine Edits über eine DataSource mit diesem Dataset. Nach jedem
> Post mußt Du das Query neu ausführen und zum letzten Datensatz springen.
> Deletes betreffen das Detail-Dataset, auch danach Query neu ausführen.
Das klingt mal nach einem sehr konkreten Ansatz, den ich gleich mal
versuchen werde.
Danke an dieser Stelle!
> Es gibt elegantere Wege, aber der oben beschriebene ist schnell umgesetzt.
Hat dieser "unelegante" Weg ernsthafte Nachteile?
Wie im DETAIL würde dein kompletter Weg aussehen, in Anbetracht der
Tatsache, dass nicht im Grid editiert werden muss?
Tschö
Ralf
Ralf Mimoun
Ralf Schmitt wrote:
...
> Hat dieser "unelegante" Weg ernsthafte Nachteile?
Ein Umstieg auf andere DB-Systeme wäre aufwendig.
> Wie im DETAIL würde dein kompletter Weg aussehen, in Anbetracht der
> Tatsache, dass nicht im Grid editiert werden muss?
Genau wie beschrieben. Tut mir leid, Sourcecode schreibe ich normalerweise
gegen Bezahlung. Wie man eine Master/Slave-Beziehung per Primärschlüssel
hinbekommt mußt Du selbst herausbekommen.
Bye, Ralf
Ralf Schmitt
>> Wie im DETAIL würde dein kompletter Weg aussehen, in Anbetracht der
>> Tatsache, dass nicht im Grid editiert werden muss?
>
> Genau wie beschrieben. [..] Wie man eine Master/Slave-Beziehung per
> Primärschlüssel hinbekommt mußt Du selbst herausbekommen.
Hi!
Die Umsetzung mit der Master/Slave-Beziehung ist ja vollzogen und scheint
auch so zu funktionieren wie ich mir das gewünscht habe. In alten Projekten
hatte ich dieses "einfache" Prinzip auch schon im Einsatz, allerdings in
einem anderen Zusmamenhang. Insofern hatte ich eine absolute Hinblockade und
kam nicht auf die Idee, ein TTable per Master/Slave an das Query zu binden.
Aber man lernt nie aus.
Da hat mir dein Hinweis ja schon gereicht und macht mich sehr zufrieden! :-)
>[...] Tut mir leid, Sourcecode schreibe ich normalerweise gegen Bezahlung.
Ich wollte keinen kompletten und fertigen Sourcecode, vielmehr eine Art
"Detailbeschreibung", wie du das umsetzen würdest. Also welche Komponenten
du verwenden und wie du sie koppeln würdest. Da du ja "meinen" Weg als
unelegant siehst.
Aber kein Problem, Wissen muss man sich nun mal erarbeiten, und damit habe
ich auch kein Problem. Es macht ja auch Spaß. ;-)
So long und nochmals danke für deine Unterstützung
Ralf