aloha...

der titel mag etwas komisch klingen, aber mir is nix besseres eingefallen...

ich hab folgendes "problem"...

ich greif mit meinem programm auf eine mysql datenbank zu die auf einem server in ungarn installiert ist... je nach netzwerkauslastung geht der zugriff auf die datenbank sehr schnell oder auch nicht...

in meinem programm zeige ich in einem dbgrid nun daten an, die der user in einer seperaten form bearbeiten soll...
ich möchte ihm aber gerne eine "blätter" funktion anbieten in dennen er zwischen den datensätzen wechseln kann...
die änderungen sollen erst an die db übermittelt werden wenn die form geschlossen wird...

ursprünglich hatte ich mir überlegt mit "Begin Transaction / Commit Transaction" zu arbeiten... das hätte aber den nachteil das änderungen die an einem datensatz bereits vorgenommen wurden nicht in der form sichtbar sind...

gibt es noch andere möglichkeiten die daten so zu bearbeiten das
1. die änderungen erst bei schließen an die db übermittelt werden
2. die bereits geänderten datensätze auch mit den geänderten daten angezeigt werden

das blättern wollte ich wie folgt realisieren:

markieren

Delphi-Quellcode:

  DataModule.Query1.Next;
//oder
  DataModule.Query.Prior;
  prUpdateForm; // --> update für TLabel, TEdit, etc.
  prRecordCheck // --> steuert die butteons für vorwärts und rückwärts blättern
  form1.Refresh;

ich hoffe ihr habt ein paar ideen oder denkanstöße wie ich das hinbekommen könnte....

Hallo Andreas,

irgendwie verstehe ich nicht, daß alle Welt mit DB... arbeitet.
Ich mach es immer so, daß dem Benutzer ein Query-Ergebnis zur Verfügung steht, sei es in einem Grid oder in einer anderen Darstellungsform. Hier darf er ändern soviel er will und wenn er fertig ist, "Save"-Button gedrückt, "Edit"-Form geschlossen oder was auch immer, dann werden die Daten gesichert, oder aber nachgefragt ob er sichern will, das ist von der Art der Verarbeitung bzw. der Daten abhängig.

In einigen Fällen erfolgt noch ein "Data-Check-before-Save" bei dem die geänderten Daten ,mit denen in der DB vorhandenen verglichen werden.

Bevor jemand Daten(in)konstistenz ruft, "wer zuletzt schreibt hat Recht!"

Ist natürlich nicht überall anwendbar!

Gruß
K-H

Zitat von p80286:

irgendwie verstehe ich nicht, daß alle Welt mit DB... arbeitet.

öhm wo soll ich denn sonst meine daten speichern auf die zig leute zugreifen müssen???

Zitat von p80286:

Ich mach es immer so, daß dem Benutzer ein Query-Ergebnis zur Verfügung steht, sei es in einem Grid oder in einer anderen Darstellungsform. Hier darf er ändern soviel er will und wenn er fertig ist, "Save"-Button gedrückt, "Edit"-Form geschlossen oder was auch immer, dann werden die Daten gesichert, oder aber nachgefragt ob er sichern will, das ist von der Art der Verarbeitung bzw. der Daten abhängig.

das hab ich ja auch, in meiner form werden die query ergebnise in TLabel und TEdit zum ändern angezeigt...

Zitat von p80286:

In einigen Fällen erfolgt noch ein "Data-Check-before-Save" bei dem die geänderten Daten ,mit denen in der DB vorhandenen verglichen werden.
Bevor jemand Daten(in)konstistenz ruft, "wer zuletzt schreibt hat Recht!"

das wäre mir auch egal da vermutlich nur eine Person editieren darf...

aber machen wir mal folgendes beispiel...
der user ändert in den datensätzen 1 - 3 etwas...
angezeigt wird mittlerweile datensatz nr. 4 dann geht er zu datensatz nr. 3 zurück und will dort nochmal etwas ändern...
wo würdest du in deinem lösungsvorschlag die bereits geänderten daten herbekommen oder anders formuliert... wie hättest du sie dir gespeichert?

Hallo,

hilft Dir da eventuell ein ClientDataset weiter, den Du mit Daten befüllst, den Anwender "wuseln" läßt und die Daten anschließend zurück schreibst?

Oder könnte [google]+kbmemtable +delphi +source[/google] eine Alternative sein? Das ist eine Tabelle im Arbeitsspeicher, die über DataSource auch mit Datenbankkomponenten verbunden werden kann, quasi eine kleine Datenbank im Arbeitsspeicher.

@naphets

danke für den tipp mit dem clientdataset.... den hat mir vorhin ein kollege auch gegeben...

wie folgt hab ich es auch schon umgesetzt...

- auf meiner form habe ich die TDataSetProvider und TClientDataSet Komponente hinzugefügt
- die TDataSetProvieder Komponente habe ich mit der Query Komponente verbunden
- das TClientDataSet habe ich mit der TDataSetProvider Komponente verbunden

das anzeigen der daten klappt auch....
wenn ich allerdings einem feld im clientdataset einen neuen Wert zuweise, dann speichert er sich diesen nicht... und ich hab keinen ahnung warum...
anbei der source zum befüllen des clientdataset feldes:

markieren

Delphi-Quellcode:

  ClientDataSet.Edit;
  ClientDataSet.FieldByName('LAYCOD').AsString := Edit5.Text;
  ClientDataSet.Post;
  ClientDataSet.CheckBrowseMode;

Da hab ich mich wohl ein wenig zu kurz gefasst.

Ich meine daß ich Daten per Query aus der DB abhole, z.B. 1..n Adresssätze und dann die Verbindung zur DB kappe.
Jetzt kann ich vollkommen losgelöst von der Ursprungsdb mit den Daten herumwerkeln.(ggf. unter Verwendung einer lokalen DB-Struktur)

Wenn dann gespeichert werden soll, dann erfolgt der entsprechende SQL-Befehl(insert/Update ggf delete) unter Beigabe der Daten.

Das ist zwar aufwendiger (in der Programmierung) als mit DBGrid und Konsorten zu arbeiten, aber ich traue denen ehrlich gesagt nicht über den Weg. Und sobald Du ein "Update" oä absetzt, dann weißt Du die Daten sind unterwegs. Und vor allem Du bist immer Herr über die Daten.

Das Problem des "Blättern" würde ich so angehen:

a. Lies Daten aus DB in Liste "Ursprung/Moddaten"
(1.Datensatz ist gewählt)
repeat
b. Zeige gewählten Datensatz an
c. Wähle neuen Datensatz [blättern] oder Speichern/abbruch etc.
until not(blättern)
d. Speichern / abbruch etc.

Gruß
K-H

@p80286
ich glaube du hast meine frage nicht richtig verstanden...
daten holen und blättern war noch nie mein problem, sondern das ändern und sofortige anzeigen der änderung ohne das es sofort in der db aktualisiert wird...
vor allem was macht es für einen sinn die daten zu holen und dann die verbindung zur db zu kappen??? beim zurückschreiben muss ich sie dann wieder öffnen was mir nicht wirklcih sinnvoll erscheint...

anyway mein problem ist gelöst...

@nahpets
ich muss ehrlich gestehen das ich das mit deinem komponenten vorschlag nur überflogen habe, aber so ich das sehe muss man für die komponente etwas zahlen...
aber das stichwort "tabelle im arbeitsspeicher" war gut
habs jetzt mit ner sqlite memory table gelöst ist zwar erheblich mehr programmieraufwand als ich haben wollte aber egal, es funktioniert

Hallo,

kbMemTable habe ich hier gefunden.

In der ReadMe.txt steht u.a. dieses:

Zitat:

kbmMemTable / kbmMemTable Pro v. 5.71 (May 12 2008)
================================================== =======================
An inmemory temporary table.

Copyright 1999-2008 Kim Bo Madsen/Components4Developers
All rights reserved.

BEFORE USING THIS COMPONENT, YOU ARE REQUESTED TO READ ALL OF THIS TEXT
DOCUMENT AND SPECIALLY TO NOTICE AND ACCEPT THE DISCLAIMER.

LICENSE AGREEMENT
PLEASE NOTE THAT THE LICENSE AGREEMENT HAS CHANGED!!! 25. Jul. 2003

You are allowed to use this component in any application for free.
You are NOT allowed to claim that you have created this component or to
copy its code into your own component and claim that it was your idea/code.

-----------------------------------------------------------------------------------
IM OFFERING THIS FOR FREE FOR YOUR CONVINIENCE, BUT
YOU ARE REQUIRED TO SEND AN E-MAIL ABOUT WHAT PROJECT THIS COMPONENT (OR DERIVED VERSIONS)
IS USED FOR !
-----------------------------------------------------------------------------------

Das sieht mir jetzt nicht gerade kostenpflichtig aus.

Alternativen wären:
-JvDBMemTable aus der JVCL
-VirtualTable von DevArt

Zitat von nahpets:

Das sieht mir jetzt nicht gerade kostenpflichtig aus.

wie gesagt ich habs mir nicht im detail angeschaut, da ich mit sqlite schon einige projekte jetzt gemacht habe und ich dort auch mit memory tabellen arbeiten kann... aber trotzdem nochmal danke für den typ...