geloescht_JesterDay

... try //Code, der den Fehler verursacht except Application.Terminate; // Die "saubere" Methode // oder // Halt; // Die Holzhammer Methode end Aber ich stimme Klotzkopp da schon zu, solltest du nicht lieber versuchen deine Anwendung so zu ändern, dass der Fehler gar nicht erst auftritt?

Ja, wenn du Mod_Rewrite auf deinem Server nutzen kannst: #.htaccess RewriteEngine On RewriteCond %{HTTP_USER_AGENT} Firefox RewriteRule ^/(.*) /ff/$1 RewriteCond %{HTTP_USER_AGENT} MSIE RewriteRule ^/(.*) /ie/$1 Alle Anfragen auf /index.html (z.B.) werden für den Firefox mit der Datei /ff/index.html und für den IE mit der Datei /ie/index.html beantwortet.

Einen Spamfilter, den ich ohne deine Spamschleuder nicht bräuchte... wie war das? Der Computer bietet uns Lösungen für Probleme, die wir ohne Computer gar nicht hätten. Über die Philosophier "Hauptsache mir geht es gut, der Rest is ja egal" könnte man auch diskutieren.. .aber das ganze war ja eh mehr oder weniger OT, wollte nur ein paar von Chief gewünschte Begründungen liefern. Deswegen sag ich auch schon gar nix mehr...

Nachtrag: Hat etwas gedauert, aber ich hab es grad mal auf unserer produktiv DB getestet (DB2\400). Das Eintragen der 15000 Sätze dauert natürlich was, ob aber wirklich länger weiß ich nich so genau. Das Lesen und Schreiben dauerte knapp 4 Sekunden (Button gedrückt und langsam gezählt).

1. Nein. 2. Ja. Aber der Oracle DB-Server wird wohl auch um einiges besser ausgestatet sein als unser Testserver (mehrere VMs auf einem Rechner, VM läuft unter Debian mit Apache und MySQL und mit 128 MB Speicher) Auch wenn ich das auf unserem "echten" DB-Server testen würde, denk ich nicht, dass der Unterschied so groß wäre Was du an DOA ändern könntest... das solltest du ja deinen DB-Admin fragen. Ich geh einfach mal davon aus, der kennt sich mit Oracle und den Treibern aus und kennt vielleicht den ein oder anderen Kniff. Scheinbar ist das ja nur bei großen Ergebnismengen so. Also entweder durch die Anzahl sätze oder die Satzlängen. Was du mal machen könntest wäre, eine Testtabelle mit z.B. 1 oder 2 Feldern und es mal damit probieren. Ansonsten gibt es bei der DOA-Komponente vielleicht ne eigenschaft, ob sofort alle Daten geholt werden sollen, oder immer nur stückweise. Beim ClientDataSet z.B. über PacketRecords. Danach hört sich das Verhalten zwar nicht direkt an, aber vielleicht mal als anstoß, etwas in der Art zu suchen. Hast du mal probiert, alle Sätze nur anzeigen zu lassen? In einem Grid oder so. BRaucht er da genauso lang? Wie sieht es denn mit anderen Anwendungen aus, die auf die DB zugreifen und auch viele Sätze zurückliefern? Und wenn die Anzeige genausolang braucht, hast du ein anderes Tool, mit dem du das mal gegentesten könntest (z.B. der Delphi SQL-Explorer oder auch eins direkt von Oracle oder so)?

Mir hat ein Kollege von nem Verwandten erzählt, der seit neuestem nen Plasma hat. Fazit: Fussball schauen ist damit ... naja... unmöglich nicht, aber auf jeden Fall lustig

Ich hab mal ein kleines Programm gemacht zum Testen. Hab aber kein Oracle hier und hab MySQL genutzt. Zugriff über dbExpress und mit Delphi7. dbExpress wurde ja aber mit D6 eingeführt. Als Treiber haben wir den dbExpress Treiber von Core Lab (http://crlab.com/dbx/ - geht auch für Oracle). Meine Tabelle sieht so aus: DROP TABLE IF EXISTS `test`.`IOTest`; CREATE TABLE `test`.`IOTest` ( `id` int(10) unsigned NOT NULL auto_increment, `Data1` char(255) collate latin1_german1_ci NOT NULL default '', `Data2` char(255) collate latin1_german1_ci NOT NULL default '', `Data3` char(255) collate latin1_german1_ci NOT NULL default '', PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_german1_ci; Also ungefähr die Satzlänge, die du auch hast. Die hab ich gefüllt mit Daten, zuerst mal mit 1500 Sätzen. Danach hab ich alle gelesen (SELECT * ...) und in eine Textdatei geschreiben. Das ganze dauerte vielleicht ne Sekunde. Dann auf 15000 Sätze erhöht, da hat das Schreiben der Sätze schon was länger gedauert, also schreiben in die DB. Dann wie eben alles gelesen und als Text gespeichert... 2-3 Sekunden (geschätzt). Hier mal mein Programm: unit MainUNT; interface uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, DB, SqlExpr, StdCtrls, ExtCtrls, ActnList, XPStyleActnCtrls, ActnMan, ComCtrls; type TForm1 = class(TForm) SQLConnection: TSQLConnection; qryMain: TSQLDataSet; amMain: TActionManager; aiFill: TAction; aiProcess: TAction; pnlTop: TPanel; btnFill: TButton; pnlMain: TPanel; btnProcess: TButton; sbMain: TStatusBar; procedure aiFillExecute(Sender: TObject); procedure aiProcessExecute(Sender: TObject); private { Private-Deklarationen } public { Public-Deklarationen } end; const cSQL_FILL = 'INSERT INTO IOTest (id, Data1, Data2, Data3) VALUES (NULL, %s, %s, %s)'; cSQL_PROCESS = 'SELECT * FROM IOTest'; cSQL_Empty = 'DELETE FROM IOTest'; var Form1: TForm1; implementation {$R *.dfm} //****************************************************************************** //*** TForm1.aiFillExecute //*** //*** Tabelle Füllen //****************************************************************************** procedure TForm1.aiFillExecute(Sender: TObject); type TData = array[0..254] of Char; var Str1, Str2, Str3: TData; saveCursor: TCursor; I, n: Integer; begin saveCursor := Screen.Cursor; Screen.Cursor := crHourGlass; try //*** zuerst leeren qryMain.CommandText:= cSQL_Empty; qryMain.ExecSQL; //*** wieder füllen n:= 65; for I := 1 to 15000 do // Iterate begin //*** Daten vorbereiten FillChar(Str1, 255, chr(n)); FillChar(Str2, 255, chr(n)); FillChar(Str3, 255, chr(n)); Inc(n); if n> 90 then n:= 65; qryMain.CommandText:= Format(cSQL_FILL, [QuotedStr(Str1), QuotedStr(Str2), QuotedStr(Str3)]); qryMain.ExecSQL; end; // for finally Screen.Cursor := saveCursor; end; // try/finally end; //****************************************************************************** //*** TForm1.aiProcessExecute //*** //*** Daten lesen und schreiben //****************************************************************************** procedure TForm1.aiProcessExecute(Sender: TObject); const cFilename = 'Data.txt'; var aList: TStringList; saveCursor: TCursor; I: Integer; aFileName, temp: String; begin saveCursor := Screen.Cursor; Screen.Cursor := crHourGlass; try //*** Datei vorbereiten aFileName := ExtractFilePath(Application.ExeName)+cFileName ; aList:= TStringList.create; try //*** Daten lesen qryMain.CommandText:= cSQL_PROCESS; qryMain.Open; while not qryMain.EOF do begin for I := 0 to qryMain.Fields.Count - 1 do // Iterate begin aList.Add(qryMain.Fields[i].asString); end; // for qryMain.next; end; // while aList.SaveToFile(aFileName); finally FreeAndNil(aList); end; // try/finally finally Screen.Cursor := saveCursor; end; // try/finally end; end. Das Formular selber enthält nur eine TSQLConnection und ein TSQLDataSet zum Zugriff auf die DB. Dann 2 Panels (einfach so...) und 2 Buttons und einen ActionManager. Im Action Manager sind 2 Aktionen definiert und die je einem Button zugeordnet. An Delphi kann es also nicht liegen, an Windows (schreiben der Daten) auch nicht. (Ach ja, ich benutze eine TStringList zum Speichern...also erstmal alles in den Speicher, dann am Ende auf die Platte, bei 15000 Sätzen ung. 11MB Datei). Ich schätze mal, es liegt entweder an den Oracle einstellungen bei euch, oder am DB Zugriff (also an DOA). Vielleicht frägst du mal den DB-Admin, kann ja sein, dass die DB für solche Zugriffe bissel angepasst werden muss o.ä. (bzw. dein Treiber).

Hast du mal probiert, das Schreiben in die Datei auszukommentieren? Wenn eine Datei eine gewisse Größe erreicht (weiss ja nicht, wie deine Satzlänge ist), kann so ein Schreibzugriff ziemlich bremsen. Kommentier den mal aus und lass es durchlaufen. Außerdem, was benutzt du für die Dateibehandlung? Write deutet für mich nicht auf einen TFileStream hin, oder? Ein TFileStream ist der alten TFile-Methode auf jeden Fall vorzuziehen.

Ich kapiere nicht ganz, was du genau mit deinem Beitrag sagen willst. Pro oder Contra Router? Und zu deiner "Paranoia" Rechnung... dass es keine Paranoia ist, bestätigen DDos-Attacken und damit verbundene Erpressungen, die vielen Spammails etc. ja wohl zur Genüge. Würdest du so eine Rechnung auch für die "Paranoia" im Auto (ESP, dutzende Airbags, ABS...) machen? Kostet auch Anschaffung und Sprit...

Also ich hab mir die Seiten mal angesehen, selbst mit ausgeschaltetem CSS ändert sich am Textcursor nichts... Ansonsten fällt mir nix auf... und ein Mediawiki hier bei uns zeigt dieses Verhalten z.B. nicht... komisch.

Damit definierst du ja 2 Frames, gibst aber nur 1 an... <frameset rows="100%" ohne den * sollte es IMHO sein.

Nein, am Thread ändert sich nichts, aber am (VCL-)Hauptthread. Denke mal (hab auch danach gesucht aber nichts detailiertes gefunden), dass hat mit der Nachrichtenabarbeitung zu tun. wie in der Hilfe zu TThread beschrieben. Wenn du direkt einen API-Aufruf verwendest zum Anzeigen, könnte es vielleicht gehen, weiß ich aber jetzt aber nicht auswendig. Threads sollten aber mit der GUI nix zu tun haben (Ausnahmen wie z.B. ein Thread für eine 3D-Anim o.ä. auf der GUI sind was anderes). Die Oberfläche sollte nur aus dem Hauptprogramm gemanagt werden. Macht das ganze IMHO auch wartungsfreundlicher. Ach ja, wenn du synchonize verwendest (zumindest wenn es häufig aufgerufen wird), kannst du auch gleich auf den Thread verzichten, denn der wartet dann ja immer auf den Hauptthread

Kommt auf deine Sichtweise an HTML ist nicht dafür gemacht, etwas im Browser anzuzeigen, sondern der Browser dafür, HTML anzuzeigen

Ich denke, die GUI-ausgabe in deinem Thread ist das Problem. Ein Thread ist eben kein eigenständiges Programm. Wenn du es so machst, musst du wohl die Methode synchronize verwenden: Beispiel aus der Delphi Hilfe: Dieses Beispiel zeigt, wie die Methode Click einer Schaltfläche Thread-sicher aufgerufen werden kann: procedure TMyThread.PushTheButton; begin Button1.Click(); end; procedure TMyThread.Execute; begin ... Synchronize(PushTheButton); ... end; Oder aber, du lässt den Thread nur die Berechnung ausführen, alles mit der GUI aber den Hauptthread machen. Dazu gibt es das Event OnTerminate, welches beim Beenden des threads aufgerufen wird, so ungefähr: // ... // ... im hauptthread - unit1 // try NewThread := MyThread.Create(true); NewThread.FreeOnTerminate := [b][COLOR="Red"]True[/COLOR][/b]; [COLOR="Red"]NewThread.Zahl:= StrToInt(Edit1.Text);[/COLOR] [B][COLOR="Red"]NewThread.OnTerminate:= ThreadTerminate;[/COLOR][/B] NewThread.Resume; except on E:Exception do begin ShowMessage(E.Message); NewThread.Free; end; end; [b] [COLOR="Red"]procedure TForm1.ThreadTerminate(Sender: TObject); begin ShowMessage(IntToStr(NewThread.Zahl)); end;[/COLOR] [/b] // ... im Unterthread - unit2 // [b] [COLOR="Red"]//TMyThread ... private FZahl: Integer; procedure setZahl(aZahl: Integer); Function getZahl: Integer; ... public property Zahl: Integer read getZahl write setZahl; ... end; procedure TMyThread.setZahl(aZahl: Integer); begin FZahl:= aZahl; end; function TMyThread.getZahl: Integer; begin result:= FZahl; end; [/COLOR] [/b] procedure MyThread.Execute(); begin // ... Berechnung // [B][COLOR="Red"]FZahl:= FZahl * 5 + 3; // als Beispiel[/COLOR][/B] end; EDIT: Wobei ich mir nicht sicher bin, ob FreeOnTerminate True sein muss, bei nochmaligem anschauen...

also bei Plasmas stimmt das (siehe unten)

Ja, mehr musst du eigentlich nicht tun. Ein Link auf die Datei, veranlasst den Client die Datei vom Server anzufordern, der schickt einen entspr. Headercode mit und der Client entscheidet dann, was er damit macht (bzw. läßt u.U. dich entscheiden (Speichern, Öffnen mit...). Wenn er die Datei lädt, stimmt der Link schonmal. Funktioniert das Video, wenn du es direkt vom Rechner spielst? Wo funktioniert das Video nicht? Bei dir, bei einem anderen? Was für eine WMV Version benutzt du? Hast du u.U. DRM in WMV aktiv (keine Ahnung, ob und wie das bei MovieMaker überhaupt geht oder ginge). Auf welchem System soll das ganze abgerspielt werden? Welcher Player ist da für Videos eingestellt? Kannst du oder der/die andere das Video mit rechtsklick speichern und dann abspielen? 1000 Fragen, aber das kann nunmal alles mögliche sein, was du hier schreibst EDIT: Falsches Format kann sein, weil da, wo es abgespielt werden soll natürlich der entspr. WMV Codec vorhanden sein muss... hättest du lieber MPEG 1 oder 2 genommen (oder vielleicht XVid, DivX, MPEG4), das geht eigentlich überall (bzw. Codecs sind vorhanden).

Natürlich ist das möglich, kommt nur auf dein Programm an Wenn du z.B. alles im FormCreate machst: nimm es da raus! Bzw. lager alles in eine Prozedur aus. ... procedure TForm1.Init; begin Query1.close; FreeAndNil(Form2); // Form2 später selber erzeugen, wenn gebraucht! // Weiteres, was du brauchst Query1.SQL.Text:= 'Irgend ein SQL'; Query1.Open; end; ... procedure TForm1.Create(sender: TObject); begin Init; end; so z.B. Und später brauchst du zum "zurücksetzen" nur die Prozedur Init aufrufen.

Weiß ich nicht... ne moderne Röhre hat schon noch Vorteile (aber halt auch den Nachteil von der Tiefe). Plasma z.B. hält von vorneherein nur ein paar Jahre, dabei wird das Bild schon immer blasser. Bis es irgendwann eben nicht mehr ansehbar ist. Das liegt an der Plasmatechnik. LCD hat dasselbe Problem wie ein LCD Monitor: nur wenn du davor sitzt, sieht das Bild optimal aus. Wenn du links oder rechts von der Mitte sitzt, oder von zu weit oben oder unten kuckst, ändert sich das Bild. Kann jeder an einem LCD Monitor probieren. Wie groß die Winkelabhängigkeit, hängt vom Gerät ab, aber es gibt sie immer. Eine Röhre funktioniert auch in 10 Jahren noch, und es ist egal, wo du sitzt.

klar... Denkfehler bei mir Muss ich mir nochmal durch den Kopf gehen lassen. EDIT: Hast du noch ein eindeutiges Feld in jedem Satz? Also z.B. eine ID? SELECT T1.MNr FROM Kunden T1 JOIN Kunden T2 ON (T1.MNr = T2.MNr AND T1.KNR = T2.KNr AND T1.id <> T2.id) sollte nämlich gehen

Das ist kein Problem, sondern der Standard Soundex-Algorithmus Und das LIKE ist eigentlich nicht nötig, weil er ja Soundex verwendet. (siehe hier). MySQL Soundex verwendet aber nicht nur 4 Zeichen Soundex-Code, sondern beliebig lange Codes (Also wirklich jeden Buchstaben im Wort ersetzen, aber min. 4 Zeichen lang. Friseur und Friseurin ergeben also bei MySQL M626 und M6265). ... SUBSTRING(SOUNDEX(name), 1, 4) = SUBSTRING(SOUNDEX(search), 1, 4) ... sollte das Problem beheben.

SELECT T1.MNr FROM Kunden T1 JOIN Kunden T2 ON (T1.MNr = T2.MNr AND T1.KNR = T2.KNr) Liefert dir alle Mitgliedsnummern, die auf dein obiges Beispiel passen.

Generell gibt es kein height: 100%! Einzig der IE unterstützt dies, und auch ab der 6er Version nur im Quirksmodus. Grund: HTML beschreibt das Dokument. Eine Anzeige, die die volle Fensterhöhe annehmen soll, müsste sich aber am Viewport (dem Ausgabebereich des Clients) orientieren. Da der Client nix mit dem Dokument zu tun hat (aus HTML sicht), gibt es kein standardkonformes HTML mit height: 100%. Ausnahme: height: 100% als Bezug auf die Parentbox im CSS Boxmodell. Bringt aber nichts für die Fensterhöhe. Workarounds wie # CSS html { height: 100%; } body { height: 100%; } ... sehen auf den ersten Blick wie eine Lösung aus. Sobald die Fenstergröße aber geändert oder gescrollt wird, ändert sich das sehr schnell

Gar nicht. Das TEdit unterstützt keine Ausrichtung, das hast du schon richtig gesehen. Entweder du benutzt andere Komponenten dafür (gibt es genug Komponentensammlungen o.ä., kann ich dir keine spezielle nennen jetzt), oder du überschreibst die Paint-Methode (? müsstest du vorher auch nochmal nachsehen) der TEdit Klasse.

Wenn du das immer in der Reihenfolge 1, 2, 3, 1, 2, 3... haben willst, musst du dir irgendwo merken, welche Nummer die letzte war. In einer DB oder einer Datei. Also anstelle von rand eine Funktion, die den Wert aus der Datei liest, den gelesenen Wert um 1 erhöht, in die Datei zurückschreibt und den Wert zurückgibt.