ADOConnection

[Moombas]

Moin zusammen,

ich "muss" mich aktuell nun anfangen mit Datenbanken auseinander zu setzen.
Generell bekomme ich die Verbindung hin (Daten auslesen, hinzufügen, ändern und löschen geht auch), jedoch habe ich da ein Verständnis- Umsetzungsproblem.

Jedoch habe ich im Vorfeld dafür eine ODBC-Datenquelle eingerichtet, welche ich per TADOConnection nutze.
Wenn jemand diese Verbindung jedoch nicht eingerichtet hat, kann er das Programm nachher nicht nutzen, richtig!?

Wie bekomme ich dies also ohne diese "voreingerichtete" Verbindung hin? Stehe da aktuell etwas auf dem Schlauch.

Was ich habe ist:
Servername : Port
Benutzer
Passwort
Schema
Tabelle

[jobo]

Du kannst direkt mit ADO arbeiten und brauchst kein ODBC zu bauen.
Den Connectionstring kannst Du dann vorgeben (wenn Du sicher bist, wo die DB liegt)
oder Du lässt den Anwender einen bauen.

P.S.:
https://www.connectionstrings.com/

[timog]

Ich stimme jobo voll zu; falls es aber ODBC sein soll/muss, dann sind es letztendlich nur Einträge in der Registry.

HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI
HKEY_CURRENT_USER\Software\ODBC\ODBC.INI
bzw.
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\ ODBC\ODBC.INI

Dort solltest Du die ODBC Datasources finden. Diese kannst Du über ein Setup Programm auf den Clients erstellen lassen oder Du verteilst eine REG-Datei mit diesen ODBC-Einstellungen.

Außerdem wirst Du wohl den mySQL Connector/ODBC Datenbanktreiber (ODBC) oder den OLEDB Provider MySQLProv (ADO) auf dem Client benötigen. Der kann ebenfalls über ein Setup verteilt werden oder muss halt manuell vor dem Einrichten der ODBC Datasource vorhanden sein.

[jobo]

Als Ergänzung:

Im Grunde ist die ODBC Geschichte erstmal nur eine weitere Fehlerquelle. Du kannst auf 3 Level (Datei,User,System) Datenquellen definieren. Spätestens bei Systemdatenquellen ist das (auch) ein Rechteproblem. Dann hast Du das noch als 32 bit und 64bit, führt auch immer wieder zu Verwirrung.
Wenn überhaupt würde ich erstmal zu Fuß eine Datei ODBC anlegen (außerhalb des Programms, ohne Code) und die einfach benutzen. Die gesparte Zeit kannst Du dann in die Datenbankprogrammierung stecken.

Einen ADO Connectionstring kannst Du selbst festlegen wie Du magst und kommst auch an die DB.
Auch das kannst Du dem User überlassen, indem du ein UDL File verwendest, das der User anlegen muss.

Dazu gibt es hier sicher auch schon mehrere Beiträge.
UDL Files anlegen: Explorer, Neu, Textdatei, umbenennen nach *.udl, Doppelklick auf die Datei startet einen Windows System Assistenen zur Abfrage der notwendigen Parameter (inkl. Verbindungstest). Die fertige Datei enthält den Connectionstring.

[p80286]

Aber.....
Ein Aber gibt es immer....

ADO ist nicht nicht mehr State of the Art aber das galt vor 10 Jahren auch für ODBC! Heute ist es umgekehrt.
Du solltest, falls möglich, beide Schnittstellen beachten und alle Datentypen durchtesten. Und da es für Datenbanken auch unterschiedliche Treiber (vom DB-Hersteller und von MS) gibt/geben kann solltest du das im Hinterkopf behalten. Im Zweifel mußt Du Deine Kunden mit den richtigen Treibern versorgen.

Gruß
K-H

[haentschman]

Moin...8-)

Zitat:

ich "muss" mich aktuell nun anfangen mit Datenbanken auseinander zu setzen.

Für mich stellen sich folgende Fragen:
1. Warum MySQL? Einfach so? Lizenzfalle...schon mal gehört?
2. Warum ADO? Einfach so?
3. Privates Projekt? Commerzielles Projekt?
4. Datensensitive Componenten? = Bääääh. :zwinker: Zum Üben i.O., aber für das eigentliche Projekt besser andere Methode.
5. Normalisierung...schon mal gehört?
6. Admin Tool für deine Datenbankauswahl?

[Moombas]

Zitat:

Zitat von haentschman (Beitrag 1441265)

Moin...8-)

Zitat:

ich "muss" mich aktuell nun anfangen mit Datenbanken auseinander zu setzen.

Für mich stellen sich folgende Fragen:
1. Warum MySQL? Einfach so? Lizenzfalle...schon mal gehört?
2. Warum ADO? Einfach so?
3. Privates Projekt? Commerzielles Projekt?
4. Datensensitive Componenten? = Bääääh. :zwinker: Zum Üben i.O., aber für das eigentliche Projekt besser andere Methode.
5. Normalisierung...schon mal gehört?
6. Admin Tool für deine Datenbankauswahl?

Zu:
1. Weil sie bereits existiert und nur (ab jetzt auch) von mir zugegriffen wird/bearbeitet wird.
2. Weil ich das bisher als einzige Verbindung via Delphi gefunden habe, nehme andere (bessere) Vorschläge gerne an. In diesem Bereich muss ich ja erstmal lernen!
3. nur Firmenintern
4. Auch hier nehme ich bessere Vorschläge gerne an :)
5. Generell ja, jedoch werde ich wohl nur "Werte in vorhandene Tabellen/Spalten ergänzen"
6. Workbench 8.0.16.0

Zitat:

Zitat von p80286 (Beitrag 1441211)

Aber.....
Ein Aber gibt es immer....

ADO ist nicht nicht mehr State of the Art aber das galt vor 10 Jahren auch für ODBC! Heute ist es umgekehrt.
Du solltest, falls möglich, beide Schnittstellen beachten und alle Datentypen durchtesten. Und da es für Datenbanken auch unterschiedliche Treiber (vom DB-Hersteller und von MS) gibt/geben kann solltest du das im Hinterkopf behalten. Im Zweifel mußt Du Deine Kunden mit den richtigen Treibern versorgen.

Gruß
K-H

...meine "Kunden" wären hierbei meine Kollegen, wo ich ungern weitere Treiber installieren würde, wenn es sich vermeiden lässt. Im Grunde geht es um Arbeitsvereinfachung.


Mal kurz zusammengefasst:
Wir arbeiten bei einem Teil der Hardware mit einer Cloud. - check
Um die Hardware in die Cloud zu melden, werden Daten der Geräte aufgenommen und daraus eine .csv erstellt. - check
Nun soll als weiterer Schritt, diese Geräte in eine Datenbank eingepflegt werden, worüber sie an die Standorte etc. gebucht werden. - todo

[Bernhard Geyer]

Du hast Delphi 10.3.
Es wird nur intern verwendet

Nimmt die FireDac-Komponenten von Delphi.
Da wärst du zwar in der GPL-Falle, ist aber für firmeninterne SW egal.

[haentschman]

Moin...8-)

Zitat:

Nimmt die FireDac-Komponenten von Delphi.

Aber: mit der Professional nur Embedded mit der Enterprise auch Server. Als Firma sollten die MyDAC oder UniDAC drin sein...aktuell gepflegt und gut, auch wenn es aktuell nicht notwendig ist, keine GPL Falle!

[Moombas]

Die Verbindung funktioniert mit FireDAC schon mal.

Große Danke dafür schon mal.

Wenn ich jedoch den "gleichen" Code für das hinzufügen/entfernen/updaten des Datenbankeintrags verwende erhalte ich eine Fehlermeldung:

Code:

procedure DeleteClick(Sender: TObject);
var
  sQuery   : string;
begin
  sQuery := 'DELETE FROM ' + DBNAME + ' WHERE seriennummer = 0000000000000000';

  FDQuery.SQL.Clear;
  FDQuery.SQL.Add(sQuery);
  FDQuery.SQL.Add('SELECT * FROM ' + DBNAME);
  FDQuery.Active := True;
  SetGridColumnWidths(DBGrid);
end;

"[FireDAC][Phys][MySQL]-308. Anweisung, die keine Ergebnismengen zurückgibt, kann nicht geöffnet/definiert werden. Hinweis: Verwenden Sie die Methode "Execute/ExecSQL" für Nicht-SELECT-Anweisungen."

Ich suche dafür aber vielleicht kann mir jemand schneller als ich finden kann einen Tipp/Link geben :)

Edit: Habs hin bekommen, war einfacher als gedacht XD

[haentschman]

Delphi-Quellcode:

procedure DeleteClick(Sender: TObject);
var
  sQuery  : string;
begin
  sQuery := 'DELETE FROM ' + DBNAME + ' WHERE seriennummer = 0000000000000000';

  FDQuery.SQL.Clear; 
  FDQuery.SQL.Add(sQuery);
  FDQuery.SQL.Add('SELECT * FROM ' + DBNAME);
  FDQuery.Active := True;
  SetGridColumnWidths(DBGrid);
end;

1. Keine globalen Variablen! (DBNAME) :warn:
2. Entweder Select oder Delete in der Query
3. Select mit Open
4. Delete mit ExecSQL
5. Parameter verwenden

Delphi-Quellcode:

procedure DeleteClick(Sender: TObject);
var
  sQuery  : string;
begin
  sQuery := 'DELETE FROM ' + DBNAME + ' WHERE seriennummer = :SER';

  FDQuery.SQL.Text(sQuery);
  FDQuery.ParamByName('SER').AsString := '000000000';
  FDQuery.ExecSQL;
  SetGridColumnWidths(DBGrid);
end;

[p80286]

Zitat:

Zitat von haentschman (Beitrag 1441276)

Als Firma sollten die MyDAC oder UniDAC drin sein..

Hmmmm, nach meiner Erfahrung ist das natürlich nicht drin "schließlich haben wir ja schon das Delphi bezahlt"
(ich weiß das das Kurzsichtig ist, aber der Chef ist der Chef und der kennt sich aus weil er xxxx liest)

Gruß
K-H

[haentschman]

Zitat:

"schließlich haben wir ja schon das Delphi bezahlt"

...kommt auf die Version an. :wink:

[HolgerX]

Hmm..

Wenn Du eine einfache interne Datenbank benötigst und auf den Clients nichts installieren willst...
Es nur um die überschaubaren Datenmenge geht...

Schau mal zum MS-SQL-Server Express..
Einfach zu installieren, auf diesem Windows PC/Server nur 2 Ports zu öffnen und einen Dienst (Browser) zu aktivieren..
Keine Lizenzkosten..

Hier werden keine Treiber oder ODBCs unter Windows benötig, diese sind per se schon installiert.
Wenn Du keine besonderen Funktionen des Datenbankservers benötigst, dann genügt der 'alte' SQLOLEDB Provider..

Einfach per ADO ansprechbar...

(Nur so eine Idee.. ;) )

[Moombas]

Zitat:

Zitat von haentschman (Beitrag 1441281)

Delphi-Quellcode:

procedure DeleteClick(Sender: TObject);
var
  sQuery  : string;
begin
  sQuery := 'DELETE FROM ' + DBNAME + ' WHERE seriennummer = 0000000000000000';

  FDQuery.SQL.Clear; 
  FDQuery.SQL.Add(sQuery);
  FDQuery.SQL.Add('SELECT * FROM ' + DBNAME);
  FDQuery.Active := True;
  SetGridColumnWidths(DBGrid);
end;

1. Keine globalen Variablen! (DBNAME) :warn:
2. Entweder Select oder Delete in der Query
3. Select mit Open
4. Delete mit ExecSQL
5. Parameter verwenden

Delphi-Quellcode:

procedure DeleteClick(Sender: TObject);
var
  sQuery  : string;
begin
  sQuery := 'DELETE FROM ' + DBNAME + ' WHERE seriennummer = :SER';

  FDQuery.SQL.Text(sQuery);
  FDQuery.ParamByName('SER').AsString := '000000000';
  FDQuery.ExecSQL;
  SetGridColumnWidths(DBGrid);
end;

Edit: Fehlermeldung erhalte ich nur, wenn ich folgenden Code verwende:

Zitat:

FDQuery.SQL.Text := 'SELECT * FROM ' + DBNAME;
FDQuery.ExecSQL; //->Fehlermeldung
// FDQuery.Active := True; //funktioniert

Global (const) ist es aktuell nur, weil ich am testen bin und nicht immer die den test-DBNamen eingeben wollte ^^
Nachher muss so oder so individuell die Datenbank/die Tabelle gewählt werden.

[haentschman]

Zitat:

3. Select mit Open
4. Delete mit ExecSQL
5. Insert mit ExecSQL
6. Update mit ExecSQL

...:zwinker:
Anders ausgedrückt: Soll die Abfrage eine Ergebnismenge enthalten...Open. Alles andere ExecSQL. :zwinker:

Delphi-Quellcode:

FDQuery.SQL.Text := 'SELECT * FROM ' + DBNAME;
FDQuery.Open;

[Moombas]

Danke @ haentschman (und natürlich auch an HolgerX und die anderen). Hab es nun für alles soweit hinbekommen (auch mit den Parametern etc.).

Sowas "einfaches wie das mit dem "open" hätte ich gerne selber gefunden :?

Das mit dem Open geht auch in einer Zeile:

Code:

FDQuery.Open('SELECT * FROM ' + DBNAME);

Macht das was wenn vorher im SQL.Text was drin stand oder wird dieser dabei dann ignoriert/gelöscht?

[haentschman]

Rückfrage: Warum Parameter?

deshalb:
https://de.wikipedia.org/wiki/SQL-Injection

[Moombas]

Parameter deshalb, da ich Gerätedaten übergeben werde, wo die Spalte und die Datenbank gleich bleibt, der Parameter (z.B. Seriennummer) sich aber ändert.
Daher ist es schöner einfach den Parameter zu ändern mit grundsätzlich dem gleichen Query. Zudem lässt sich daraus, denke ich, zusätzlich auch besser eine eigene Funktion dafür bauen.

[jobo]

Ich glaube ihr redet aneinander vorbei.
Wenn Moombas Parameter freiwillig einsetzt, braucht man ihn nicht mehr zu überzeugen und er muss sich natürlich auch nicht dafür "rechtfertigen", sie einzusetzen.
Parameter sind der richtige Ansatz! Leider haben sie auch manchmal ihre Grenzen.

[haentschman]

Soweit richtig...Aber der wahre Grund ist zuerst SQL Injection. (siehe Link) :zwinker:

Zitat:

Wenn Moombas Parameter freiwillig einsetzt, braucht man ihn nicht mehr zu überzeugen und er muss sich natürlich auch nicht dafür "rechtfertigen", sie einzusetzen.

...wer muß sich denn rechtfertigen? :roll: Er muß wissen warum Parameter...das hat nichts mit freiwillig zu tun. Wer es nicht macht gehört, geschlagen...:?

[Moombas]

Soweit ich das richtig verstehe muss dafür dem Benutzer jedoch mindestens der Server bekannt sein.
Da der Benutzer (Kollegen) in meinem Falle jedoch davon nichts mit bekommen, sollte das doch generell kein Problem darstellen oder übersehe ich da etwas?

[jobo]

Zitat:

Zitat von Moombas (Beitrag 1441311)

Soweit ich das richtig verstehe muss dafür ..

Wofür?

[Moombas]

Sorry, für das von haentschman angesprochene SQL Injection

[jobo]

SQLInjection ist ein Missbrauch einer Software.
Es reicht dazu, eine Software, die nicht dagegen gewappnet ist, missbräuchlich einzusetzen.

Dazu muss nur das Programm gestartet, genutzt werden. Ein server muss nicht bekannt sein, wenn das Programm nicht dessen Eingabe erwartet.

[Schokohase]

Zitat:

Zitat von Moombas (Beitrag 1441311)

Soweit ich das richtig verstehe muss dafür dem Benutzer jedoch mindestens der Server bekannt sein.
Da der Benutzer (Kollegen) in meinem Falle jedoch davon nichts mit bekommen, sollte das doch generell kein Problem darstellen oder übersehe ich da etwas?

Ja, du kennst anscheinend Litte Bobby Tables nicht.

[Moombas]

Stimmt aber laut dem Link von heantschman sollte es mit dem Gebrauch der "ParamsByName" ja behoben sein.

[haentschman]

Richtsch...:stupid: