Datenzugriff ohne DBGrid

[braunbär]

Hi!
Entschuldigt, wenn ich mit einer Frage komme, die vielleicht für einen SQL Programmierer blöd wirkt.
Mit Hilfe einer TZquery und einer TDatasource kann ich ein dbGrid mit Daten aus der Datenbank befüllen.
Welche einfache Möglichkeit gibt es, das Ergebnis der Abfrage ohne graphische Komponente und ohne Tricksen
von der Tzquery zu holen, gegebenenfalls einen Datensatz nach dem anderen (Ohne im Sourcecode von Tdbgrid zu wühlen, um herauszufinden, wie und wo genau die Daten herkommen )?

Alles, was ich an Tutorials gefunden habe, zeigt mir, wie ich ein dbgrid befülle

[Soner]

Man befüllt gar nichts, alles bleibt in TSQLQuery/TZQuery/TZReadOnlyQuery. Sowohl TDBGrid als auch alle anderen Datensteuerungen zeigen es direkt aus TxxQuery.
Wen du direkt auf ein Wert zugreifen möchtest, dann kannst du das mit TField.AsXYZ-Funktionen machen, siehe nach AsInteger, AsString usw. Eigenschaften.

Nehmen wir an du hast so diese Kundentabelle mit den Feldern, Kundennr und Kundenname, dann kannst du alle Datensätze so ausgeben:

Code: Alles auswählen

Q1.SQL.TEXT:='select * from kunden'; //alles auswählen, alle Spalten holen
Q1.Open; //query ausführen
Q1.FIrst; //Datenzeiger auf 1.Zeile bewegen, eigentlich zeigt es am Anfang schon  auf 1.Zeile
while not Q1.EOF do begin //solange es nicht letzt datenzeile ist
  Writeln(Q1.FieldByName('Kundennr').AsString+' '+Q1.FieldByName('Kundenname').AsString); //nr und name ausgeben
  Q1.Next; //nächste Zeile
end;

//Wenn du neue ZEile hinzufügen willst:
Q1.Append;  //oder  Q1.Insert
Q1.FieldByName('Kundennr').AsInteger:=12;
Q1.FieldByName('Kundenname').AsString:='Banane';
Q1.Post;  //speichern
//man muss natürlich transaction-handling machen aber zeos macht es automatisch.

Du kannst gleiche Query gleichzeitig mit viele DBEdit- oder sonstige DB-Steuerungen und DBGrid verbinden. Wen du dann, Query mit Q1.Next/Q1.Prior bewegst, dann kannst du beobachten, dass die Daten in DB-Steuerungen sich ändern, weil sie auf die gleiche Daten anzeigen. Und die zeigen immer auf aktuellen Datensatz.
Das ist nur dafür damit du verstehst wie es im Hintergrund abläuft. Es gibt genug ausführliche Tutorials im Internet, z.B. bei lazarus.intern.es oder bei Lazarus-Wiki.

Eint Tipp, man sucht in der Ergebnismenge nichts, man lässt DB-System mittels WHERE-Klausel machen und die Ergebnismenge enthält schon was man gesucht hat.

Wenn du neu mit DB-Programmierung bist, dann solltest du erwägen SQLDB zu benutzen, das liegt schon bei Lazarus und es hat genug Dokumentation und es gibt gefühlt mehr Benutzer.

[braunbär]

Danke für die Antwort. Ich habe bis jetzt kaum aktiv SQL programmiert, war aber als Firmenchef in die Entwicklung von einigen SQL basierten Programmen stark involviert. Oberflächlich kann ich SQL, bloss hab ich damals fast nichts selbst umgesetzt, und kämpfe momentan mit derartigen trivialen Fragen.

Die Aufgabenstellung von diesem Projekt ist etwas eigen. Wir haben vor Jahren ein umfangreiches Programm entwickelt, das auf einem Netzwerkdatenbankmodell beruht. Der Kunde wünscht sich unter anderem wegen der flexibleren Reportmöglichkeiten ein SQL Datenbanksystem für genau das Programm - eine Umstellung dieses (riesigen) Programms auf SQL Code wäre aber mit einem unrealistischen Arbeitsaufwand verbunden, und ein für ihn passendes "modernes" Programm hat er nicht gefunden (das war meine erste Empfehlung). Ich arbeite jetzt an einem Interfaceprogramm, das die Netzwerkdatenbankbefehle unseres Programms nach SQL übersetzt und für unser Programm so eine Netzwerkdatenbank simuliert, wobei die Daten dann aber tatsächlich in einer MariaDB gespeichert werden. Dafür brauche ich natürlich keine tabellarische Darstellung der Daten, vielmehr soll das Interface mit so wenig Overhead wie möglich belastet werden.

[Zvoni]

Hab hiervon kein Wort verstanden.....
Was sind "Netzwerkdatenbankbefehle"?????
Da du MariaDB (MySQL) erwähnst: Der Zugriff auf Daten eines modernen RDBMS erfolgt in 99,9999% aller Fälle IMMER per SQL.

Heisst: Mit hoher Wahrscheinlichkeit wird jetzt schon unter der Haube SQL verwendet.

Es sei denn euer aktuelles Programm ist in sowas wie RPG auf ner IBM DB2 geschrieben worden.
[SARKASMUS ON]Dann werdet ihr damit sehr viel Spass haben.[SARKASMUS OFF]

Sonst das was Soner geschrieben hat.

Wenn du Hilfe bei SQL benötigst, gib laut....
Mache das täglich....

[af0815]

Hab hiervon kein Wort verstanden.....
Was sind "Netzwerkdatenbankbefehle"?????

Ich kenn das ganze

Gehe mal davon aus, du hast zB. einen Novell 3.12 File-Server und PC's die mit MS-DOS laufen und den entsprechenden Novell-Requestern. Das ganze vielleicht mit RG58-Cu verkabelt oder mit Yellow-Cable mit Vampirklemmen

Dort brauchst du aber Daten von den Maschinen oder Messwerkzeugen gespeichert, bzw. Auftragsverwaltung. Was nun, man nimmt Records und speichert die Dateibasierend auf dem Server ab. Das Locking muss man sich selbst machen und man wird durch das Locking des File-Servers dabei unterstützt - sprich es kann immer nur einer schreiben, aber der Rest lesen. Damit konnte man damals mit Borland Pascal auf den PCs ganz schöne Datenbanken machen.

Später kam dann auch noch DBase dazu die intern ja ähnliches gemacht haben und somit in einem gewissen Rahmen doch verdammt komplexe Datenbanken ermöglicht haben. Weil eine IBM konnten sich besonders kleinere Firmen nicht leisten und wenn wurde die meisten nicht für die Produktion benutzt, weil sich das nicht gerechnet hätte.

[charlytango]

das die Netzwerkdatenbankbefehle unseres Programms nach SQL übersetzt

Da setzt leider auch mein Verständnis für diese Terminologie aus.
Und auch wenn ich mich @soner und @zvoni anschließe bin ich erstens doch neugierig was genau damit gemeint ist.
Vielleicht kannst du genauer skizzieren welche Software da beteiligt ist, dann können wir qualifizierter helfen.
Vielleicht nur ein Hinweis... wenn du dich mit ZEOS mit dieser "Netzwerkdatenbank" verbinden kannst, dann läuft da bereits SQL im Hintergrund.

Der von Soner genannte Teil des Lazarus-Wiki gibt einen guten Überblick wie das so mit SQL-Daten funktioniert.

Falls du nur Reporting betreiben willst sollten ja nur Abfragen im Spiel sein. "SELECT *" ist übrigens kein guter Stil und geht letzten Endes auch auf die Performance, besonders wenn die Datenbank groß ist.

Wenn du etwas in die DB schreiben willst, vergiss nicht auf

Q1.ApplyUpdates;

Lies dir zu diesem Thema den Abschnitt "Daten in einer Tabelle ändern" durch.

[charlytango]

einen Novell 3.12 File-Server und PC's die mit MS-DOS laufen

Ouutch --so alt?

[Zvoni]

einen Novell 3.12 File-Server und PC's die mit MS-DOS laufen

Ouutch --so alt?

Yep. Auch mein Gedanke. Fehlen nur noch Lochkarten.....

Q1.ApplyUpdates;

Betrifft mWn nur wenn man Q1.Edit, Q1.Append und co. anwendet, oder?
Wenn ich ein CUD-SQL abfeuer (nicht R), reicht ein Transaction.Commit (...Retaining) und Ruhe ist

Später kam dann auch noch DBase dazu die intern ja ähnliches gemacht haben

Ach ja, stimmt. Da gabs doch mal was......
Was habe ich DBase in der Berufsschule gehasst......

..... und SELECT * FROM ist ne tickende Zeitbombe....

[af0815]

Yep. Auch mein Gedanke. Fehlen nur noch Lochkarten.....

Die habe ich mir verkniffen, ja ich habe damit gearbeitet, auch mit Puncher und Reader am Teletype, allerdings noch früher. Und ich konnte mir bei den alten Rechnern die Bit auch mit dem Mikroskop ansehen (Ringkernspeicher), geile Technologie. Bootloader per Schalter einprogrammieren und so, ja schöne gute alte Zeit.

[Zvoni]

*schnipp*... und so, ja schöne gute alte Zeit.

Ähhh....nö.... verzichte darauf.

Keine Ahnung wie oft mir ein Modem ins Ohr gekreischt hat, nur weil der Kunde sich in der Telefonnummer verwählt hat....

[braunbär]

Yep. Auch mein Gedanke. Fehlen nur noch Lochkarten.....

An Lochkartenstanzern habe ich noch viel Zeit während meine Informatikstudiums verbracht.

Die Anwendung haben wir von den frühen 80er Jahren beginnend entwickelt, damals gab es praktisch noch keine brauchbaren Tools. Für SQL waren die Computer nicht leistungsfähig genug, und wir haben ein Datenbanksystem nach dem Netzwerkmodell selbst entwickelt (damals in Turbo Pascal und wegen der Speicherknappheit auch viel Assembler, es mussten ja Dos, Datenbankprogramm + Anwendung mit 640K Arbeitsspeicher auskommen) ebenso eine eigene Bildschirmbeschreibungssprache und für Turbo Pascal 3 einen Overlay Manager. EIne völlig andere Herangehensweise als relationale Datenbanken, die Daten werden nicht in Tabellen gespeichert, sondern jeder Datensatz ist ein "record", und die Beziehungen zwischen den Datensätzen werden durch sogenannte "Sets" statt über Fremdschlüssel abgebildet.

Nachdem der Ansatz ein grundlegend anderer ist, kommt eine Umstellung eines Programms vom Netzwerkmodell nach SQL einer kompletten Neuprogrammierung gleich. Statt dessen schreibe ich jetzt ein Interface programm, das die Anfragen unserer Anwendung an die Netzwerkdatenbank quasi nach SQL übersetzt und an eine MariaDB schickt, die Antwort von MariaDB wird dann in die Form konvertiert, die unser Programm vom Netzwerkdatenbanksystem erwartet.

[Zvoni]

Heiliger Strohsack.......

Da denke ich aber, dass eine Neubewertung des Aufwandes bzgl. Neuprogrammierung aber definitiv Sinn macht.

Euer momentaner Ansatz ist für mich eher wie:
Ihr habt ein Gerät, was als Energiequelle eine Dampfmaschine braucht, und ihr konstruiert gerade ein "neues" Gerät was nach vorne wie eine Dampfmaschine aussieht und sich so verhält, aber hinten raus die Anfragen an einen Atomreaktor weitergibt, und dessen Antworten wieder in Dampfmaschine umwandelt.

Ob das wirklich Sinn macht?

Manchmal muss man sich eingestehen: OK, das Ding ist tot..... lasst uns neu machen

[braunbär]

Eine Neuprogrammierung könnte der Kunde sich nicht leisten. Punkt.
Und die Software passt zu 100% zu seinen Anforderungen. Er hat sich nach fertigen Alternativen umgeschaut und nichts gefunden...

[Zvoni]

Eine Neuprogrammierung könnte der Kunde sich nicht leisten. Punkt.
Und die Software passt zu 100% zu seinen Anforderungen. Er hat sich nach fertigen Alternativen umgeschaut und nichts gefunden...

Na dann.....
Warten wir mal darauf, wie deine "Netzwerkdatenbankbefehle" aussehen, und was sie machen.
Ich denke, dass wir diese dann nach SQL übersetzt bekommen

[charlytango]

Statt dessen schreibe ich jetzt ein Interface programm, das die Anfragen unserer Anwendung an die Netzwerkdatenbank quasi nach SQL übersetzt und an eine MariaDB schickt, die Antwort von MariaDB wird dann in die Form konvertiert, die unser Programm vom Netzwerkdatenbanksystem erwartet.

Ich kann das Argument gut verstehen dass sich ein Kunde etwas nicht leisten kann.
Was du beschreibst ist im wesentlichen das nachprogrammieren von SQLDB oder ZEOS, ein TwoWay Konverter zwischen zwei inkompatiblen SW-Teilen. Lesend und schreibend.

Denkst du, dass da ein allgemeiner Echtzeit-Proxy möglich ist, oder musst du jede lesende und schreibende Aktion nachbauen? Ich bezweifle immer noch die finanzielle wirtschaftlichkeit verglichen mit einer Neuprogrammierung.
Außer du machst es pro bono. Aber das kannst du sicher besser abschätzen.

Zvonis Vergleich des Atomreaktors mit einer Dampfmaschine (ich mag deren Technik) werden wohl zutreffen.
Bin gespannt womit du uns noch überraschst

PS: was du möglicherweise nicht berücksichtigst. Eine Neuprogrammierung würde mit einem Ferrari erfolgen und nicht mit dem alten 2CV