Datenbank wird nicht aktualisiert

[Moony]

Hallo zusammen,

habe das folgende Problem:

In meiner Applikation habe ich auf die Filemaker Datenbank erweitert. Es funktioniert soweit ganz gut. Ich wähle nun einen Datensatz aus, und führe an diesem eine Funktionsüberprüfung durch. Als Bsp.:

1. Mein Feld Cnt enthält eine 0 sowohl in der DB als auch in meiner Tabellenanzeige.
2. Ich führe meine Abfrage aus und baue absichtlich einen Break ein, damit ich den Wert direkt in der Datenbank auf 1 ändern kann.
3. Gehe dann weiter und stelle fest, dass der Datensatz mit dem Wert 0 nicht mehr exisitiert, also breche ich meine weiteren Prüfungen ab.
4. Abschließend wird die Datenbank aktualisiert mit ADODataSet.Requery()
5. Hier müsste dann der manuell geänderte Wert aus der Datenbank in der Tabelle angezeigt werden.

Und hier kommt das Problem: Die Werte in der Datenbank werden mit meinen aus dem Grid überschrieben und nicht umgekehrt!

Hoffe es kennt jemand eine Lösung. Zur Info noch, ich habe das mit einer Access Datenbank probiert und dort werden die Werte richtig aus der Datenbank geholt.

Bitte dringend um Hilfe!!!!
Danke im Voraus!

Gruß, Moony

[mkinzler]

Unterstützt FileMaker Transaktionen?

[Moony]

Soweit ich das schnell einlesen konnte ja. Warum?

[mkinzler]

Dann musst diese comitten, das die Änderungen ausserhalb der Transaktion sichtbar werden

[Moony]

Wann muss ich das genau durchführen?

[Jens Hartmann]

Hallo,

das Commit, musst Du ganz zum Schluss durchführen. Ich arbeite zwar mit Firebird, aber so in etwa müsste es ausssehen..

Delphi-Quellcode:

  Query.Close; 
  Query.SQL := Memo2.Lines;  
  Query.ExecSQL; 
  Connection.Commit;

Gruß Jens

[Moony]

Also, ich mache das folgendermaßen:

Delphi-Quellcode:

MyDataset.Close;
MyDataset.Open;
MyConnection.CommitTrans;

Und bei dem CommitTrans bekomme ich folgende Meldung: EOleException...Meldung:'Keine der Transaktionen ist aktiv'

[Jens Hartmann]

Lass mal das OPEN weg...

Delphi-Quellcode:

MyDataset.Close; 
//MyDataset.Open; 
MyConnection.CommitTrans;

Gruß Jens

[Moony]

Nee, weiterhin die gleiche Meldung. Irgendwelche anderen Ideen?

[Jens Hartmann]

Muss du denn nicht auch irgendwie folgenden Befehl senden, ich weiß natürlich nicht wie der bei deiner Datenbank heißt, aber irgendwie so..

Delphi-Quellcode:

  Query.ExecSQL;

Die Datenbank, muss ja schließlich wissen, was sie und wie sie speichern soll. Also den SQL String bekommen. Mit dem Commit, schließest Du ja nur die Transaktion ab.

Gruß Jens

PS: zumindest denke ich, das es so ist.

[Moony]

Der SQL Befehl ist ja noch vorhanden:

Delphi-Quellcode:

MyDataset.CommandText

Mit Open und Close aktualisiere ich lediglich das Query. Ich könnte auch Requery aufrufen, das macht nichts anderes als Close und dann Open aufzurufen. Wenn das CommitTrans lediglich nur de Transaktion abschließt, muss ich doch das Query schließen, Öffnen und anschließend die Transaktion abschließen mit CommitTrans. Aber genau das bringt mir die besagte Fehlermeldung.

[Jens Hartmann]

Weiß nicht genau,

aber ich meine, du musst die Query schließen, die Transaktion abschließen und anschließend die oder eine andere Query wieder öffnen, um die Daten wieder einzusehen.

Wenn du mit der selben Query, Daten speichern und öffen willst, musst Du den SQL Befehl ja immer wieder anpassen. Das habe ich immer falsch gemacht, und somit Problem bei Abfragen etc. gehabt. Ich benutze mittlerweile für jede Art eine eigen Query, und somit meine ich zu wissen,

Erst Query schließen, Transaktion abschließen, und anschließend die Query zum Anzeigen der Daten öffnen.

Also ich meine das wäre so. Wenn nicht, lasse ich mich auch gerne belehren.

Gruß Jens

[Moony]

Aber das mache ich doch wenn ich sage Close, dann CommitTrans und dann wieder Open. Aber wenn ich das CommitTrans aufrufe gibts die Fehlermeldung, dass keine Transaktion aktiv ist.

Ich weiß nicht ob das vielleicht am Query liegt, ich aber ein TADODataSet verwende. Leider kann ich das nicht in ein Query umändern, wenn das der Fall ist, da die Anwendung viel zu komplex bereits aufgebaut ist.

Gibts denn vielleicht eine alternative dazu?

[Jens Hartmann]

Zitat:

Zitat von Moony

wenn ich sage Close, dann CommitTrans und dann wieder Open.

Hast Du aber anders gelößt

Delphi-Quellcode:

MyDataset.Close; 
MyDataset.Open; 
MyConnection.CommitTrans;

[hoika]

Hallo,

ich würde hier auch 2 Queries benutzen.

Query_Vis
=========
Anzeige-Query
Nur Open/Close

Query_DB
========
DB-Code


Ein Update läuft dann so ab.

Transaction läuft noch ... (MyConnection.StartTrans)

Delphi-Quellcode:

with Query_DB do
begin
  SQL.Clear;
  SQL.Add('Update Table 1 ... ');
  ExecSQL;
end;

Query_Vis.Close;
MyConnection.CommitTrans;
Query_Vis.Open;

Ich persönlich habe aber nicht gern Transaktionen offen.
Deshalb benutze ich kein DBGrid, somit muss die Query_Vis auch nicht ständig offen sein.
Ich lade meistens alles in ein normales TStringGrid

MyConnection.StartTrans;
Query_Vis.Open; use.
MyConnection.CommitTrans;

Damit ist die Transaktion nicht offen
und muss vor dem Update (Query_DB) geöffnet werden.



Heiko

[Moony]

Mein Problem ist, dass ich das Programm und vor allem die Struktur und den Aufbau wie auf die Datenbank zugegriffen wird nicht umschrieben kann. Es ist zu komplex und würde viel zu viel Aufwand bedeuten. Deshalb benötige ich eine andere Lösung.

[Jens Hartmann]

Wo liegt den dan genau dein Problem,

Ich weiß nicht so recht, was Du für eine andere Lösung brauchst. Der Vergang muss eigendlich so funktionieren. Was heißt komplex? Warum, soll das so nicht funktionieren.

Gruß Jens

[Tyrael Y.]

Delphi-Quellcode:

Query.Open;

darf man NUR bei einer SELECT-Anweisung anwenden

Delphi-Quellcode:

Query.ExecSQL;

wendet man bei allen anderen SQL-Anwweisungen ausser SELECT an

Delphi-Quellcode:

Connection.CommitTrans;

darf man nur nach einem

Delphi-Quellcode:

Query.ExecSQL;

anwenden


Keine Ahnung, ob euch das bewusst ist, mir schien es ist euch nicht bewusst.

[hoika]

Hallo,

Zitat:

Connection.CommitTrans darf man nur nach einem
Query.ExecSQL; machen

Unsinn, zumindestens bei der 2. Bemerkung ... ;)

Delphi-Quellcode:

XXX.BeginTransaction;
try
  with Query do
  begin
    '' select 
    Open;
    try
      while not EOF do
      begin

        Next;
      end;
    finally
      Close;
    end;
  end;
finally
  XXX.EndTransaction
end;

Es kann aber wirklich sein, dass MySQL meckert,
wenn eine Transaktion bei geöffneter Query commited wird.
So etwas komt bei mir nicht vor (try finally)

An den Thread-Ersteller:
Du musst prüfen, ob eine Query noch offen ist.

Mein Link weiter vorn betraf auch DBX.
Wenn der DBX-Treiber "Mist baut", kannst du nur zu einem anderen Treiber wechseln.
Aber meistens sitzt das Problem vor dem Rechner ;)


Heiko

[Moony]

Ich kann meine vorhandene Struktur des Programms und den Zugriff auf die Datenbank nicht ändern. Irgendwann aktualisiere ich die Datenbank, sprich ich rufe entweder ein MyDataset.Requery() oder MyDataset.Close & .Open auf. An dieser Stelle wird innerhalb meines Prozesses nicht die aktualisierte Datenmenge abgerufen, sondern mit meinen jetzigen Werten aus dem Grid überschrieben. Das ist mein Problem.
Mit dem CommitTrans habe ich probiert, aber da gibts Fehlermeldungen. Ich kann aber auch keine Transaktion beginnen ohne die DB wahrscheinlich vorher zu schließen. Auf jeden Fall gibts Fehlermeldungen wenn ich die Transaktionen versuche durchzuführen.

@Tyreal: Ich befürchte, dass hier das zusätzliche Problem liegt. Ich besitze kein Query sondern ein Dataset.

[Tyrael Y.]

Zitat:

Zitat von hoika

Zitat:

Connection.CommitTrans darf man nur nach einem
Query.ExecSQL; machen

Unsinn, zumindestens bei der 2. Bemerkung ... ;)

Und was willst du in der Datenbank aktualisieren mit einem SELECT?
SELECT macht in zusammen mit CommitTrans keinen Sinn.

Zitat:

Zitat von Moony

@Tyreal: Ich befürchte, dass hier das zusätzliche Problem liegt. Ich besitze kein Query sondern ein Dataset.

Wenn ich mich nicht irre gibt es bei Dataset paar Methoden, die
auch SELECT, INSERT usw. behandeln

ich glaube
Open()
Edit()
Insert()
Append()

musst mal gucken, ob es alle waren und wann welcher benutzt werden soll.

[Moony]

Ich will die aktuelle Datenmenge aus der Datenbank in mein Dataset holen. Wenn nämlich in der zwischenzeit von Außen jemand Änderungen in der Datenbank gemacht hat, will ich die aktuellen Daten bekommen. Das passiert aber nicht wenn ich eine Aktualisierung auf meine Datenmenge durchführe. Mit Append, Edit, etc. beginne ich selbst Änderungen an der Datenbank, in diesem Fall will ich das aber nicht. Lediglich die aktuellen Daten aus der Datenbank in mein Dataset laden und per DBGrid anzeigen.

[hoika]

Hallo,

Tyreal

Zitat:

Und was willst du in der Datenbank aktualisieren mit einem SELECT?
SELECT macht in zusammen mit CommitTrans keinen Sinn.

Doch, macht es, wenn z.B. mehrere Selects ausgeführt werden.
Jede Aktion läuft ja in einer Transaktion, ob man es will oder nicht
(egal ob select/insert/update).
Ja nach benutztem DB-Framework gibt es noch automatische Transaktionen.
Um zu verhindern, dass pro Select eine Transaktion gestartet wird,
schreibt man das StartTransaction selber.

Firebird ist ein schönes Bsp.
Benutze ich autocommit (Bde,FIBPlus, Zeos ?),
werden ein Haufen Transaktionen erzeugt,
auch wenn ich nur Selects mache, das Programm wird langsamer.


Zum Thread-Ersteller:
Der MySQL-Engine-Typ fehlt noch.

Zitat:

Wenn nämlich in der zwischenzeit von Außen jemand Änderungen in der Datenbank gemacht hat

Wer macht denn die Änderungen, dein eigenes Programm (auf einem anderen Recher?).

Zu der Fehlermeldung gibt es per Google doch eindeutige Aussagen.
Dein Programm erzeugt DB-Anweisungen, die nicht mit MySQL kompatibel sind.
Du musst erst mal rausbekommen, welche Query das direkt ist,
z.B. indem du mal alle Schreibzugriffe rasukommentierst
und dann schrittweise wieder reinnimmst.

Zitat:

"Ich kann das Programm nicht ändern"

Dann kannst du MySQL als DB nicht verwenden ...

Zum Engine-Typ:
Ist das InnoDB, werden Transaktionen unterstützt.
Um Änderungen zu sehen, die ein anderes Programm (oder dein eigenes mit anderer Connection)
gemacht hat, musst du mit Transaktionen arbeiten.


Heiko

[Moony]

1. Ich verwende keine MySQL Datenbank sondern eine Filemaker Datenbank, die über die ODBC Schnittstelle angebunden wird.
2. Während mit der Datenbank in meiner Applikation gearbeitet wird, kann es sein dass von übergeordneter Stelle aus Flags in der Datenbank gesetzt werden, so dass ein Benutzer gewisse Datensätze nicht angezeigt bekommt.

Bsp.: Der Benutzer bekommt in der Maske nur Datensätze angezeigt, die er drucken darf (PrintFlag in der DB). Wenn jetzt der Admin währenddessen entscheidet, dass ein Datensatz doch nicht gedruckt werden darf, dann wird das PrintFlag weggesetzt. Somit gibt es eine Änderung an der Datenbank von aussen. Und genau diese Änderung will ich durch die Aktualisierung meiner Datenmenge aufrufen. Was normalerweise lediglich durch ein Requery getan sein sollte, ist aber hier nicht der fall. Warum auch immer.

[hoika]

Hallo,

kein mysql, dann war das der andere Thread ...

Nun, warum der Code so gemacht werden soll, hättest du ja mal früher sagen können :)

Zitat:

Zur Info noch, ich habe das mit einer Access Datenbank probiert und dort werden die Werte richtig aus der Datenbank geholt.

Genau der gleiche Code ?, oder doch noch was "rumgebastelt" ...

Warum dann die Sache mit dem break (1. Post)
Du hast doch da schon das Admin-Tool, also benutze das direkt zum Setzen.

Hast du in deinem Programm überhauopt schon mal Tranktionen benutzt ?
Teste doch mal mit 2 laufenden Instanzen deines Programmes,
ob Prog1 die Änderungen von Prog 2 sieht (bei offen halten).


Heiko

[Moony]

Genau der gleiche Codeschnipsel funktioniert bei einer Access und bei der Filemaker nicht. D.h. die geänderte Datenmenge wir bei Access richtig in mein Grid geladen und bei Filemaker nicht.

Welches Admin Tool? ich habe keins. Ich besitze nur meine Applikation und muss zwischenzeitig bei gewissen Aktionen des Benutzers die Datenmenge aktualisieren, was ich mit dem Requery druchführe.

Zitat:

Hast du in deinem Programm überhauopt schon mal Tranktionen benutzt ?

Nein, mit Transaktionen habe ich noch nie gearbeitet, war bis jetzt auch nicht notwendig.

[hoika]

Hallo,

Zitat:

Wenn jetzt der Admin währenddessen entscheidet, dass ein Datensatz doch nicht gedruckt werden darf, dann wird das PrintFlag weggesetzt.

Also ist dein Programm gleichzeitig das Admin-Tool.

Zu Access/FileMaker.
Es wird wohl so sein, dass Access die Transaktionen anders verwendet wir FileMaker.
Jede Aktion unter Access wird sofort in die DB geschrieben,
wenn man keine Transaktionen benutzt (AutoCommit).

Starte doch mal dein Programm 2mal,
gehe in ein Form, wo Daten geändert werden können,
Prog1 ändert, Prog2 ist offen und schaut danach nach,
ob die Änderungen wirklich drinsind.
Sind sie es nicht, beende Prog2, wieder starten, schauen.

Sind sie immer noch nicht drin, Prog1 und Prog2 schliessen,
Prog2 aufmachen, nachschauen.
Wenn sie jetzt drinstehen, startet Ado beim Filemaker zu Beginn
des Programms eine Transaktion und commited die entweder erst beim Programmende
oder nach einem bestimmten Timeout.


Dann musst du dich wohl oder übel mal mit
Transaktionen / Isolation Levels beschäftigen.

Eine Notlösung wäre, als Isolation Level read uncommited zu benutzen.


Heiko