Problem mit Umschalten der Verbindung

[Delbor]

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

[Delbor]

Hi zusammen
Das Problem scheint ganz woanders zu liegen. ich hab das Params.Clear wie von Baumina vorgeschlagen, mal eingefügt. Das Resultaat war daselbe wie auf dem Eingangs gezeigten Anhang. Also hab ich in der entsprechenden Routine eine Zeile hinzugefügt, um eine zusätzliche Ausgabe auf dem Memo zu errreichen:

Delphi-Quellcode:

  CM_First.ProcedureReport.Add('  ');
  CM_First.ProcedureReport.Add('FUNCTION TFDMySQLDml.DefineContentmasterConnection');
  CM_First.ProcedureReport.Add('--------------------------------------------------');
  CM_First.ProcedureReport.Add('TFDMySQLDml.FDConnectionMySQL.Params.DriverID := '+ FDConnectionMySQL.Params.DriverID);
  CM_First.ProcedureReport.Add('TFDMySQLDml.FDConnectionMySQL.Params.Database := '+ FDConnectionMySQL.Params.Database);
  CM_First.ProcedureReport.Add('-------------------------------------------------------------------------------------'); //<= Neu

Das Ergebnis ist im Anhang ersichtlich.
Ursprünglich vermutete ich, das das Memo standardmässig über eine gewisse Beschränkung auzugebender Zeichen verfügt und habe deshalb Stringzuweisungen an die Liste, die zwischen den beiden Define-Funktionen erfolgen, deaktiviert. Allerdings hat das Memo die letzte Zeile trotzdem weiterhin verschluckt.
Zeilenweises durchsteppen der Routine ergab, das sämtliche Zeilen korrekt abgearbeite werden und auch diee Variablenbelegungen stimmen.
Da FDConnectionMySQL.Params und das Memo im Grunde beides Listen sind, sind deren beider Indexe nullbasiert - daran kanns also nicht liegen.

Gruss
Delbor