Zeitproblem Post/Refresh erster Datensatz

[Jedi]

Hallo,
ich habe ein Problem mit einer sqlite-3 - DB-Anwendung, das bei mir bisher so nie aufgetreten ist und finde keinen Ansatz zur Suche:

Bearbeitet wird eine Datenbank mit 5 Tabellen (1 Mitgliedertabelle und 1 Jahres-Auswertungstabelle sowie 3 Zusatztabellen). Die Mitglieder- bzw. Jahres-Auswertungstabelle werden jährlich mit den Stammdaten neu erstellt, die Zusatztabellen bleiben bestehen und werden jährlich bei Bedarf mit neuen Werten versehen (z.B. Beiträge, Berechtigungen, Standorte usw.). In die Mitglieder- bzw. Auswertungstabelle werden die Daten aus den Zusatztabellen übernommen (nicht verknüpft!) um alte Jahresdaten bei Änderung der Daten der Zusatztabellen zu erhalten. Das Programm läuft ohne inhaltliche Probleme und macht alles wie es soll.
Mich stört allerdings, das jedes erste! Post oder Refresh in der Datenbank ca. 3-5 sec. dauert. Danach laufen alle Aktionen unabhängig von der Dauer der Erfassung / Änderung ohne Verzögerung ab. Werden jedoch ca. 3 Minuten keine weiteren Eingaben getätigt, geht das Spiel von vorn los.

Mir fällt nichts ein, wo ich im Programm suchen könnte. Vielleicht habt ihr einen Hinweis zur Suche.

Programm:

Lazarus 1.4.4
ZEOS-Komponenten 7.1.4-stable
Datenanbindung mit 1 x TZConnection, 5 x TZQuery, 5 X TDataSource
Datenanzeige/Änderung mit TDBGrid als Übersicht und zusätzlicher Form mit DataControls (Ansicht aller Daten eines Datensatzes ohne zu scrollen) für Änderungen des ausgewählten Datensatzes.

BS ist Win 7-64

Gern weitere Auskünfte!

MfG
Jedi

[EgonHugeist]

Hallo Jedi,

SQLite im nicht exklusivem Modus ist sehr langsam bei jeder Art update. Ich würde ers mal raten auf Zeos 7.2/7.3 umzusteigen. 7.2-Stable wird bald kommen!

7.2 unterstützt den FireDac default high performance modus, wenn du

Code: Alles auswählen

 
synchronous=0
locking_mode=EXCLUSIVE
 

zu den TZConnection.Properties hinzufügs.

Performance Beispiel:
http://synopse.info/forum/viewtopic.php?id=2801
die FireDac insert Raten kann Zeos-7.2 bei weitem toppen.

Generelles Kommentare über die Zeos Performance vegleiche kannst du dir hier erlesen:

http://synopse.info/files/html/Synopse% ... ml#TITL_94

Ich bin über den letzten Refactorings von 7.2 .. dann kommt stable. Ich habe leider keine Zeit mehr 7.1 zu pflegen.

Probiers aus.. hab Spaß und Teile mit, ob's geholfen hat.

[af0815]

Mich stört allerdings, das jedes erste! Post oder Refresh in der Datenbank ca. 3-5 sec. dauert. Danach laufen alle Aktionen unabhängig von der Dauer der Erfassung / Änderung ohne Verzögerung ab. Werden jedoch ca. 3 Minuten keine weiteren Eingaben getätigt, geht das Spiel von vorn los.

Klingt ganz dannach als ob da erst die internen Buffer gefüllt/gewartet werden müssen. Viel hängt davon ab wie die Queries geschrieben bzw. konfiguriert sind.

Warum es nach der ersten Verzögerung rasch geht, da sind die ganzen Buffer aktuell und es werden nur die Änderungen mit der DB abgeglichen, (Vermutung aufgrund des Verhaltens wie beschrieben) Irgendwann werden die Buffer als veraltet angesehen und der Refresh dauert halt genau so lange wie der Anfang. Macht die Connection ein (180s) timeout ?

[Jedi]

Besten Dank für die Antworten.

@EgonHugeist
Ich habe jetzt auf einem anderen Rechner die ZEOS-Komponenten mit Version 7.3 ersetzt und bin dabei auf ein anderes Problem gestossen:
In einer ZQuery wird mit :

Code: Alles auswählen

ZQ_Name.SQL.Text  := ('Select Name || '', '' || Vorname As Fullname From ' + datname + Where CMS_b is Null Order By Name, Vorname');

ein Variables Feld "FullName" erzeugt und in einer TDBLookupComboBox als Listfield / Keyfield verwendet.
Funktioniert mit ZEOS 7.1.4-stable,

mit Version 7.3 erhalte ich nur eine Anzeige "(MEMO)"


Wo kann da das Problem liegen?

@af0815

Macht die Connection ein (180s) timeout ?

Wie kann ich das prüfen?

MfG
Jedi

[EgonHugeist]

Hallo Jedi,

hmpf das ist kein BUG oder sowas, viel mehr war 7.1 buggy.

Die str-concats geben Zeos einen untypisierten TEXT zurück. By default kann SQLite nur INTEGEG, DOUBLE, BLOB, TEXT, NULL Typen auseinander halten. Es gab diverse Tickets wegen String-Truncations. Somit hab ich das mal abgestell.

Workaround:
Füge "Undefined_Varchar_AsString_Length=x" zu den TZConnection.Properties hinzu (altes verhalten: Undefined_Varchar_AsString_Length=255) oder benutze den Parameter bei den TZDataSet-Componenten.Properties, welches die Eigenschaft nur für die auszuführende Query einstellt.

Somit solltest du dein String-Feld wieder erhalten. Soweit mir bekannt will SQLite4 etwas näher an den SQL92-Standart rücken.. Was das im Einzelnen heißt, frag die Sterne. Jetzige SQLite4 refactorings betreffen nur die INDEX Eigenschaften, wie BTREE vs. LSM und ROWID sollte mit dem eigentlichen PrimaryKey ersetzt werden.. Abwarten und Tee trinken.

[hde]

Ich bin über den letzten Refactorings von 7.2 .. dann kommt stable.

@EgonHugeist
gut zu lesen, und Dank für deinen Einsatz
Gruß hde

[Jedi]

@EgonHugeist
Danke erstmal für die schnelle Hilfe.

Der Eintrag "Undefined_Varchar_AsString_Length=x" in den TZConnection.Properties bzw. in den TZDataSet-Componenten.Properties hat leider nichts gebracht. Es wird immer noch (MEMO) angezeigt.
Wo kann ich noch dran drehen?

Mir ist nun aber noch etwas aufgefallen:
Obwohl ich die Komponenten 7.3 installiert habe, wird im Objektinspektor für die TZConnection die Version 7.2-beta angezeigt.
Ich hatte früher mal die Version 7.2-beta getestet aber wegen des o.g. Problems wieder entfernt. Kann es damit zusammenhängen?

MfG
Jedi

[EgonHugeist]

hast du es wirklich mit 'x' versucht?
dann:

Undefined_Varchar_AsString_Length=255
x = count of chars

Meine tests sagen, dat funzt.
wegen des 7.3 tags... Werd's nachher ändern, danke für den Hinweis.

@Hans-Dieter,

ja wird Zeit. 7.2 is von ZCore bis ZDbc überarbeitet. Superschnell wäre der ZComponent-Layer, wenn die von mir begonnenen TZFields eingeschalten würden. Aber das werd ich erst mit 7.3 oder 4 machen.
übrigens ist das ADO protocol auch für FPC dabei.

7.3 bringt 3 neue Protokolle mit sich:
OleDB, odbc_w, odbc_a, weil mir das ADO Dingensbummens zu lahm war. OleDB rockt, ist aber nur unter Windows dabei... ODBC ist aber immer noch besser als das DBLIB Protokoll.

[Jedi]

Hallo,
ich habe mein "x" entsprechend der maximalen Länge der Einträge angepasst, aber es hat leider nicht funktioniert. Ich habe da bestimmt noch irgendwo eine Einstellung nicht richtig vorgenommen?
Hier mal der Auszug TZConnection aus der lfm-Datei:

object ZC_Mitgl: TZConnection
ControlsCodePage = cCP_UTF8
AutoEncodeStrings = False
ClientCodepage = 'UTF-8'
Properties.Strings = (
'codepage=UTF-8'
'controls_cp=CP_UTF8'
'Undefined_Varchar_AsString_Length=75'
)
Port = 0
Protocol = 'sqlite-3'
left = 512
top = 4
end

Auch andere Werte für "x" bringen keine Änderung. Immer noch der Eintrag (MEMO).
Hast Du noch andere Vorschläge, wo mein Fehler liegen kann?

MfG
Jedi

[af0815]

Macht die Connection ein (180s) timeout ?

Wie kann ich das prüfen?

Ich weis es leider nicht ich kenne nur den umgekehrten Weg

Code: Alles auswählen

ZConnection1.Properties.Add('timeout=120')

[EgonHugeist]

@Jedi

hab mich wohl zu weit aus dem Fenster gelehnt... Der Test war nie im SVN gelandet und nach System-Neuinstallation auch bei mir nicht mehr da.

OK hab den Test wieder hinzugefügt und auch gleich einen Fix für das Wiedererscheinen des Problems hochgeladen.

Patch done R3758 \testing-7.2 (SVN).

In ca. einer Woche merge Testing-7.2->Trunk->testing-7.3.

Bei weiteren Erscheinungen bitte melden. --->>> Stable sollte auch Stable sein! Und ich kann nur pflegen/fixen, was mit einem konkreten Beispiel behaftet ist.

Grüße, Michael

[Jedi]

@EgonHugeist
Danke für die Info. Da muss ich nun nicht mehr suchen.
Kann ich den Patch irgendwo downloaden (ich kann in nicht finden) oder ist es besser auf die neue Version zu warten?

MfG
Jedi

[EgonHugeist]

@Jedi

nope ich würde warten. Ich warte mal bis einer meiner Tester alles durch seine Compiler Sammlung gespult hat (macht er heute) wenn ich grünes Licht bekomme mach ich den Merge noch heute.

Problem ist, das ich die letzten Tage noch a bizzl and core performance gefummelt habe. Die Zeos-Tokenizer Performanze hat sich ver100facht. Hinzu kommt, das ich Sowohl für Delphi, als auch für FPC weitere RTL replacements eingeführt habe, da so diverse RTL (speziel FPC) Functionen tot langsam sind oder der FPC code hinzubaut, den keiner brauchen kann.

Bestes Beispiel an den Haaren herbeigezogen:

Code: Alles auswählen

 
procedure TestUnicodePerformance(P: PWideChar);
begin
  while P^ <> #0 do begin
    Assert((P^ = 'a') or (p^ = 'b'))
    Inc(P);
  end;
end;
 

Performante Portierung:

Code: Alles auswählen

 
procedure TestUnicodePerformance(P: PWord);
begin
  while P^ <> Ord(#0) do begin
    Assert((P^ = Ord('a')) or (p^ = Ord('b')))
    Inc(PWideChar(P));
  end;
end;
 

Füttere beide Funktionen mit nem laangen UnicodeString voll mit 'a'oder'b' und lass das mal 1000 mal durchlafen ... die Unterschiede sind sowas von übel! Beim Delphi gibt es hier keine Unterschiede. Der FPC spoolt all Chars duch den WideStringManger, macht vorher 'nen String draus und vergleicht den String. Hust, Prust. Keep LIBICONV and MemoryManager in busy state!

Ich meld mich, wenn der merge gemacht ist.

[Jedi]

Danke!

[EgonHugeist]

Erledigt. Bitte testen!

Und dann zurück zum Thema?