MySQL Einträge ändern

[ralli]

@af0815 und @pjensen, danke für eure Hilfe.

@pjensen, vielen Dank für Dein kleines Probeprojekt, das hatte ich bereits genau so gemacht, allerdings ist mir da ein peinlicher Fehler unterlaufen, weshalb keine Daten im Grid angezeigt wurden. Habe ich dummy doch tatsächlich in der TSQLQuery im Objektinspektor die Datasource Eigenschaft mit datasource1 besetzt, die natürlich frei bleiben muss.

Jetzt läuft alles, und ich werde ein Frontend für Mysql beginnen zur Administration und Verwaltung. Mein fbmaker für firebird ist schon weit fortgeschritten. Das möchte ich nun auf mysqlmaker portieren. Mysql ist die Datenbank des Web, und obwohl ich firebird erfogreich am Laufen habe, möchte ich dann doch lieber nicht auf mehreren Hochzeiten tanzen. Wenn mit mysql alles läuft, schmeisse ich firebird runter. Auch lampp habe ich gelöscht, weil es ja mit Bordmitteln von susi einwandfrei klappt. Habe bereits moodle,joomla und phpBB2 unter apache2 installiert und konfiguriert, läuft alles einwandfrei und zwei Webserver Systeme brauche ich nicht. @pjensen, wenn ich mich ein wenig eingearbeitet habe, schaue ich mir das update Problem an, das muss natürlich auch funktionieren...

ralli

[af0815]

Bei Dir läuft es jetzt???

Ja, ich hatte so wie Du und ralli erhebliche Probleme, die Datenbank mit den Daten habe ich von Dir übernommen, das Projekt konnte ich nicht übernehmen, da es beim Laden immer einen Fehler gegeben hat.

1) "Index" in der DB in "ClientIDX" umbenannt.
2) Das ganze nochmal schnell komplett neu erstellt, um eventuellen Fehleinträgen im Obejtinspektror etc. aus dem Weg zu gehen.

Bei mir tut sich folgendes:

Bei upWhereKeyOnly => Fehlermeldung
Bei upWhereAll => Fehlermeldung
Bei upWhereChanged => läuft, aber immer noch das gleiche Probelm

Ich werde mir am Abend deine Dateien und Logs nochmal ansehen.

Zum Logfile:
- Die ########## kommen natürlich von mir.
- Bei UpWhereKeyOnly steht hinter dem "Where" gar nichts, ....Das ist doch falsch oder?
- Bei UpWhereAll steht ganz am Ende eine 0 im Eintrag bei City,...Das ist doch wohl auch falsch oder?

Ja, der bastelt da scheinbar falsch herum. Nachdem er bei dir ja SQL Statements erzeugt (aber falsche), kann Du dir mal den Inhalt von UPDATESQL in einem Memo ausgeben lassen, und zwar unmittelbar nach den ApplyUpdates? Es wäre interessant was dort drinnensteht. Ich habe mir den Quellcode aus der Query in mein Testprojekt kopiern, die Variablen angepasst und so herausgefunden warum das SQL Statement nicht richtig läuft.

Im Übrigen steht da öfters "show index from clients". Deswegen niemals eine Spalte "Index" nennen, richtig?

Ja, aber nicht nur. Man darf generell KEINE reservierten Wörter als Spaltenbezeichner, Variablennamen etc. verwenden. Das gilt auch hier. Bei Lazarus würdest du ja auch nicht eine Variable 'procedure' nennen und wenn würde da der compiler sein Veto einlegen. Am DB-Server wird aber erst zur Laufzeit (und zwar meistens beim ersten Aufruf nach Änderung) kompiliert. Deshalb der Fehler so spät.

Mit upWhereAll, upWhereChanges, upWhereKeyonly hatte ich kürzlich schon mal rumgespielt, allerdings mit dem gleichen Ergebnis.

Genau da liegt ein Problem, es sollte soviel Doku dazu da sein, das man nicht blind 'herumspielen muß. Man sollte es wissen, was was auslöst.

In der Hoffnung auf Hilfe...
Peter

Das werden wir auch noch hinbekommen und dabei viel Erfahrung sammeln

Andi

[ralli]

Ich habe gerade eine bestehende mysql Datenbank mit phpMyAdmin importiert. Sie hat ein Feld mit Namen Inhalt, welches mit dem Datentyp mediumtext definiert wurde.

Die Tabelle besteht nur aus 4 Feldern und archiviert e-mails.

1. Feld Datum

2. Feld Absender varchar(5)

3. Feld Betreff varchar(80)

4. Feld Inhalt mediumtext

In einem dbgrid werden nun nur die ersten 3 Felder richtig angezeigt, das 4. Feld Inhalt überhaupt nicht. Was ist das schon wieder für ein Bug.

ralli

[ralli]

Jetzt habe ich mal ein 5. Feld hinzugefügt mit dem Namen Probe - varchar(10). Seltsam, das wird wieder angezeigt, aber das 4. Feld verschluckt er...

ralli

[ralli]

Und nun das 5. Feld probe wieder gelöscht und das 4. Feld Inhalt umstrukturiert von mediumtext in varchar(8192), weil ich grosse Texte dabei habe.

Jetzt kann ich den Feldinhalt auch in einem dbmemo anzeigen. aber praktikabel ist das alles nicht.

ralli

[ralli]

Hat denn noch niemand Lazarus mit mysql im Einsatz ? Kann ich das eigentlich schon einsetzen oder ist das noch problematisch ? Es ist doch seltsam, das bei der populärsten Datenbank des WEB niemand daran interessiert ist, seine eigenen Erfahrungen hier zu posten, womit ich euch nun auffordere. Lohnt es sich schon, sich mit Lazarus und mysql zu beschäftigen oder ist mysql auch noch ein Zeitdieb. Datenbanken sind doch ein wichtiges Thema, denn ohne Datenbanken läuft doch nichts. Delphi wurde nicht zuletzt so erfolgreich, weil es eine ziemlich offene Architektur für Datenbanken präsentierte, und die Anbindung fast sämtlicher populären Datenbanken erlaubte. Jetzt werde ich mal dasselbe bei firebird probieren, wenn das auch mit grösseren Texten Probleme gibt, dann ist das alles nicht so richtig zu gebrauchen. Bei mysql habe ich mir nun damit geholfen den Datentyp mediumtext in varchar(8192) umzuwandeln. Das geht aber erst seit mysql 5.1x. Ab dieser Version ist varchar aufgebohrt auf max 65535. Vorher war varchar ja auf 255 begrenzt.

ralli

[af0815]

4. Feld Inhalt mediumtext

In einem dbgrid werden nun nur die ersten 3 Felder richtig angezeigt, das 4. Feld Inhalt überhaupt nicht. Was ist das schon wieder für ein Bug.

Die Frage ist erstmal umgekehrt zu stellen. Ist der Typ 'mediumtext' überhaupt implementiert ?! Und wenn ja in welcher Form.

Das Problem ist, das die BDE und ADO nicht so einfach zu ersetzten sind. Da muss man einiges opfern für die Plattform unabhängige Implementierung. Momentan scheint es, als wäre ZEOS so aktiv um den Trends bei den Datenbanken zu folgen und einen ähnlichen Komfort zu gewähren wie die BDE & ADO.

MySQL & PHP wurden deshalb auch so populär, weil sie einfach und schnell waren. Nur jetzt entwickelt sich MySQL in Richtung volles DBMS mit allen Vor- und Nachteilen (Große Typen, Programmierung, Sprachumfang,...). Nur kannst Du von den Komponenten in Lazarus nicht immer erwarten, das alles voll mitgetragen bzw. sofort implementiert wird.

Andi

[af0815]

@pjensen
Ich habe mein Testprojekt angehängt, schau mal ob es damit geht.
Meine Version: Linux Lazarus 0.9.21 Beta

MySQL datenbank ist die Deinige mit der Änderung des Index.

[pjensen]

@af0815

------ HEUREKA ------ ------ ES LÄUFT ------

Dies war ein kleiner Schritt für die Menschheit, aber ein großer Schritt für mich
Vielen Dank erstmal.

Aber jetzt kommen natürlich, wie Du schon voraus gesehen hast, die Fragen:

1)
Du gehst, wenn ich es richtig verstanden habe, das ganze Grid von Oben nach unten und von links nach rechts durch. Bei jeder Veränderung wird die ganze Zeile in der Datenbank ungedatet. (Jedenfalls wird im Log jede Zeile einzelnd upgedatet.). Soweit richtig verstanden ?

2)
Du hast, glaube ich, die Prozeduren aus "sqldb" mehr oder weniger 1:1 in Deinem Code nachgebildet. Ich hab noch nicht genau kapiert, was Du da gemacht hast.

Hast Du im Original von "sqldb" irgendwelche Fehler entdeckt?

3) Jetzt geht sogar "UpWhereKeyOnly", warum das bei Deinem Prog geht und bei meinem nicht, muß ich auch nochmal rausfinden.......... Hast Du da einen Anstz für?

4)
Gibt's eigentlich eine Möglichkeit, die angezeigte Spaltenbreite im Grid fest zu definieren? So daß die Spalten z.B. wesentlich schmaler sind als entsprechend der Feldlänge der Datenbank im MySQL?

5) Gibts eigentlich auch ein Grid, das beim Anklicken der Spaltenüberschrift sortiert ? (z.B. oben PLZ anklicken, dann wir automatisch nach PLZ aufsteigend sortiert, nochmal anklickecn, dann wird automatisch absteigend sortiert / Anzeige durch einen Up/Down-Pfeil)

MfG, Peter

[af0815]

ad 1)
Herauszufinden was updatet wurde ist für die einfache und universelle Komponente zuviel. Deshalb sicherheitshalber die ganze Zeile. Das ist aber der Grund warum es die 'UpdateSQL' gibt. Dort kannst du ja ein anders Verhalten festlegen.

ad 2)
Um den Fehler einzugrenzen habe ich den Code 1:1 genommen und konnte somit mit dem Debugger festellen was die Komponente eigentlich macht. Das einzige was ich machen musste, ist die richtigen Objekte hineinplazieren und zwar hart. Ist für das Verständnis manchmal gut, zumindest muß man Nachdenken, welches Objekt gerade wo gebraucht wird. Ich gebe zu da hat mir die Erfahrung von ca. 10 Jahren Delphi & Datenbankprogrammierung geholfen.

ad 3)
Your Job

ad 4) Vermutung ja, aber müsste mal im Quelltext nachsehen.

ad 5)
Kannst Du über Änderung des SQL Text steuern. Herausfinden was angeklickt wurde, dann die 'Order by' Klausel im Statement entsprechend ändern (Und ein Requery durchführen).

Ich weiß es klingt alles einfach, aber ich habe die letzten 7 Jahre Betriebsdatenefassung für mehrer Standorte programmiert (Delphi & SQL). Leider wurde das ganze an die zentrale IT abgegeben, da das Projekt zu groß wurde.

[monta]

Hat denn noch niemand Lazarus mit mysql im Einsatz ? Kann ich das eigentlich schon einsetzen oder ist das noch problematisch ?

Ich kann nur für Firebird sprechen, dort laufen die mitgelieferten Komponeten in den Standardfunktionen erträglich, bis auf mangelnde Unterstützugn der Datentypen.

Aber Zeos läuft bestens und sollte auch eben so gut mit MySQL laufen.

P.S.: Im übrigen bitte die Dateien als Anhänge hier hochladen, so nützen sie auch später noch anderen und es ist alles zusammen.

[pjensen]

@monta,

OK, hatte ich gar nicht gewußt, das das geht. Übrigens war der Download vorhin sehr langsam, brach ein paar mal ab.

ZEOS werde ich mir mal angucken.



@af0815
Die Zeilenbreite merken ist recht einfach mit "Misc - TXMLProbstorage"

[af0815]

Eine für mich sehr interessante Anwendung:
Ich arbeite jetzt als Freiberufler (Elektro-Ing) und muß laufend Briefe (z.B. Angebote, Infos etc.) an Kunden schreiben. 90% der Briefe sind Standart-Texte, 8 verschiedene Versionen.Das mache ich derzeit mit OpenOffice.

Eine Tabelle mit
Name, Adresse, Wohnort, Bemerkung, etc. Dann trage ich während des Telefonats ein paar Daten ein. Anschließend nehme ich einen vorgefertigten Brief, ändere nur Name, Adresse etc. Jetzt muß ich immer ein neues Verzeichnis erstellen, den Brief darin abspeichern & drucken. Ich finde das sehr nervig und unbefriedigend.... und fehlerträchtig obendrein (z.B. mal wieder nen alten überschrieben und abgespeichert....)

.........

=> Ich brauche eine einfache Adress-Datenbank, in der ich die Einträge schnell verändern kann, wahlweise in einer Liste oder in einer Maske.
Dann einfach mit einem Mausklick einen Brief ausdrucken, z.B. während des Telefonats. Diese Tabelle sollte auch nach verschiedenen Dingen gefiltert werden können.

Da Du ja wie ich SUSE10.2 hast: Schau Dir mal das Adressbuch von KDE an. Genau so in der Art brauche ich das. Hier fehlen vereinfacht gesagt nur noch 10 Buttons: Brief1..Brief10 drucken. Oder ein Button: KundeXY-Termin an... um...

Noch aktuell ?

Die Frage ist nur bei dem Umfang ob DB oder DB-ähnlich mit XML ?
Bei DB hat man den Vorteil, das man ev. OO mit Base und als Serienbriefmodul verwenden kann. Vielleicht lässt sich auch OO als Automationserver unter Linux verwenden.

[pjensen]

@af0815

- Ja, sehr aktuell.
- Habe es gestern nicht mehr hinbekommen, alles ausser dem Index im Grid anzeigen zu lassen.
- Habe vorhin mal ZEOSLIB installiert, bin hiernach gegangen.
Das hat 10 Minuten gedauert und es macht genau das was es soll......Bis jetzt
Sieht jedenfalls sehr erfolgversprechend aus.

- Ausdrucken:
Weiß noch nicht genau, wie ich Briefe schreiben will.
Die Idee ist, das OOP2.0 Briefe (.odt) zipfiles sind. Darin enthalten die Datei context.xml mit dem eigentlichen Text.

=>> Einen festen Brief (z.B. Angebot_1.odt) in eine festes Verzeichnis schreiben und hier entpacken. Hierbei Name, Strasse,Preis etc. als Platzhalter definieren, z.B.
LAZA-NAME, LAZA-STRASSE, LAZA-PREIS.
Dann mit dem Lazarus-Prog die Platzhalter im content.xml tauschen gegen die Werte aus der Datenbank. Dann das zusammenzippen als und umbennenen in Angebot_1.osd, dann einfach ausdrucken...

Oder mit dem LazReportgenerator (oder wie der auch immer heißt). Hab ich mir noch nicht näher angeschaut.


MfG, Peter

[Christian]

TDbf würde für den Fall auch reichen kann man auch als Serienbriefquelle benutzen und ist als Datenbank einfacher zu handeln.