Hi Sir Rufo
Auch dir danke ich für deine Antwort.
Zitat:
Jede Verbindung zum Server ist eine eigene Session auf dem Server. Zu jeder Session gibt es Session-Variablen, die ich abfragen und auch setzen kann.
Trenne ich die Verbindung, dann wird auch die Session beendet und die gesetzen Werte der Session-Variablen gehen den gleichen Weg wie die Session -> ab ins Nirwana.
Genau deshalb verwende ich nur eine einzige Connection-Komponente. Die bewusste
DB-Anwendung lief unter DelphiXE4 Pro und DBExpress problemlos.
Dann hab ich mir DelphiXE8 zugelegt - offensichtlich genau einen Tag, bevor Delphi Seattle erschien. Das heisst: die Version des
MySQL-Servers, der unter DelphiXE8/DBExpress funktioniert hätte, war offenbar auch schon wieder Geschichte. Eine neue Version des
MySql-Servers benötigtete ich, weil ich mir einen neuen Rechner (Win10 Pro/64) zugelegt hatte. Und da ich nun mit den DBExpress-Komponenten keine Verbindung zu
MySQL mehr erhielt, entschloss ich mich, auf FireDac umzusteigen.
Erstmal habe ich sämtliche Express-Komponenten durch solche aus dem Firedac-Framework ersetzt. Dabei zeigten sich Probleme bei Prozeduren, die auf Serverfunktionen zugreifen.
Zitat:
select * from DBName1.TabName, DBName2.TabName
Bauminas Codeschnipsel ist mir nicht ganz unbekannt - es wäre auszutesten. Nachträglich fallen mir Beispiele von der
MySQL-Seite ein, die vor Abfragen anderer Datenbanken erst mit use zu dieser wechseln. Solche Beispiele scheinen zumindest Bauminas Codeschnipsel zu widersprechen - es sei denn, der Server akzeptiert ein zweifaches use:
Delphi-Quellcode:
use DBName1;
use DBNAme2;
Das wäre in dieser Form aber die direkte Kommunikation mit dem Server über die Kommandozeile.
Zitat:
EDIT: Achso, bevor du FDConnectionMySQL.Params.Add machst, vielleicht sicherheitshalber vorher ein FDConnectionMySQL.Params.Clear machen.
Ja, wär' ja klug, wenn sich die Komponente ihre Parameter nicht so einfach überschreiben lässt.
Gruss
Delbor