Wie verwende ich in MySQL eine C++ Funkion?

[mysql+c++]

Guten Tag.
Ich möchte mit MySQL auf eine C++ Funktion zugreifen. Das auslagern von 'Intelligenz' ist Prinzipiell möglich. Nur finde ich auf die schnelle nichts im Internet.

Was ich zu lösen versuche ist das auflösen von Variablen in SQL-Anweisungen.
Genauer:
SELECT * FROM variable_fuer_eine_tabelle;

Da MySQL nicht die Variable auflöst und nachschaut was sich hinter "variable_fuer_eine_tabelle" verbirgt, bin ich gezwungen das ganze auszulagern. Die SQL-Anweisung einem C++ Programm übergeben und die komplette aufgelöste Zeichenkette zurückzubekommen, ist das Ziel.
Für Andere Vorschläge bin ich offen.
Gedankt sei dem der Hilft.

[Unix-Tom]

Mit MySQL kann man nicht auf eine C++-Funktion zugreifen.
MySQL ist ein RDBMS und versteht nur SQL.
Du kannst aber von c++ auf MySQL zugreifen.
Rest bitte hier suchen. Gibt sicher 100derte Threads dazu.

[mysql+c++]

Von c++ auf mysql zuzugreifen ist eine ganz andere Sache und um mein Problem zu lösen nicht brauchbar.

[mysql+c++]

Bringt das meine Lösung ein wenig näher?
http://dev.mysql.com/doc/refman/5.1/de/plugin-api.html

[Gate]

Sorry, aber das ist absolut sinn frei was du vorhast. Wenn du eine Variable aus einem bestimmten Programm benutzen willst, musst auch den Query von dort absetzen. Nichts mit irgendwie Programm aufrufen, mal ganz davon abgesehen, dass das wohl das denkbar schlechteste Design ist.
Wie gesagt Unix-Tom hat recht und damit wäre alles gesagt, also überdenke nochmal, was du eigentlich machen willst.

[Unix-Tom]

MySQL kann sowas nicht wie MSSQL welche die CLR verwenden kann.

[mysql+c++]

@Gate: Es gibt immer für alles ein Anwendungszweck .. was Sinnvoll ist oder nicht das kannst du Leider nicht beurteilen. Schon gar nicht wenn du es nicht richtig verstanden hast. Ich habe nie behauptet das die Variable von einem anderen Programm kommt. Hierzu ein Zitat von mir:

Da MySQL nicht die Variable auflöst und nachschaut was sich hinter "variable_fuer_eine_tabelle" verbirgt, bin ich gezwungen das ganze auszulagern. Die SQL-Anweisung einem C++ Programm übergeben und die komplette aufgelöste Zeichenkette zurückzubekommen, ist das Ziel.

Hast du noch nie eine Prozedur mit Variablen geschrieben? Hattest du noch nie eine Tabelle mit Tabellen oder Spaltenamen als Datensatzinhalt?

@Unix-Tom: Naja ich war auch für andere Vorschläge offen

Ich habe eine Lösung gefunden und da ich es hasse .. das die Leute in Foren kein Feedback geben, sende ich nun mein Feedback. Es sollen ja auch andere etwas davon haben .. so ist zu mindestens das alte Prinzip.

SET @sql := CONCAT('SELECT * FROM ', variable_fuer_eine_tabelle); 
PREPARE myStmt FROM @sql; 
EXECUTE myStmt;

Das Prinzip mit CONCAT ist klar .. das was mir gefehlt hat war PREPARE und EXECUTE.

Danke für die Hilfe.

[hustbaer]

@mysql+c++:

das die Leute in Foren kein Feedback geben, sende ich nun mein Feedback

Ja das nervt mich auch immer. Und weil's halbwegs dazupasst noch ein paar Kommentare von mir

Das ganze nennt man "dynamic SQL" (und zwar egal ob man es aus C++ heraus macht, oder direkt in einem SQL script).

In T-SQL (MSSQL) kann man übrigens direkt "EXEC @sql" schreiben, und das "CONCAT" kann man einfach mit "+" machen, der Rest bleibt sich ziemlich gleich.

Falls "variable_fuer_eine_tabelle" von irgendwo ausserhalb des Systems kommt (also z.B. irgendwann als User-Input eingelesen wird/wurde etc.) solltest du den String auch noch "escapen", also z.B. jedes " verdoppeln, und noch ein " vorne und hinten dran machen (sepp -> "sepp", "hans" -> """hans""", test"234 "test""234" etc.). Und zwar einfach um SQL-Injection zu verhindern. Bzw. wie genau man Entity-Namen (Tabellennamen, Spaltennamen etc.) escapen muss hängt vom verwendeten SQL-Dialekt ab, aber mit " geht es meistens.

[mysql+c++]

hustbaer schrieb:

Ja das nervt mich auch immer. Und weil's halbwegs dazupasst noch ein paar Kommentare von mir

Da sind wir ja einer Meinung!
Ja, das Passt gut dazu ..

hustbaer schrieb:

Das ganze nennt man "dynamic SQL" (und zwar egal ob man es aus C++ heraus macht, oder direkt in einem SQL script).

Das ist doch ein Stichwort .. hiermit kann man doch Suchen. Hierfür ein Lob

hustbaer schrieb:

Falls "variable_fuer_eine_tabelle" von irgendwo ausserhalb des Systems kommt (also z.B. irgendwann als User-Input eingelesen wird/wurde etc.) solltest du den String auch noch "escapen", also z.B. jedes " verdoppeln, und noch ein " vorne und hinten dran machen (sepp -> "sepp", "hans" -> """hans""", test"234 "test""234" etc.). Und zwar einfach um SQL-Injection zu verhindern. Bzw. wie genau man Entity-Namen (Tabellennamen, Spaltennamen etc.) escapen muss hängt vom verwendeten SQL-Dialekt ab, aber mit " geht es meistens.

Das ist ein guter Hinweis. Beim ersten mal ist mir das um die Ohren geflogen. Meine Log-Tabelle liefert nicht nur Tabellenname sondern auch Spaltenname, Werte usw.
Sehr guter Hinweis. Nun sollten wir alles Komplett haben.

[nixnutz]

Moin!

Ich verstehe die ursprüngliche Frage nicht. Den Antworten nach zu urteilen geht es anderen nicht viel besser. Im Thread gibt es eine bunte Sammlung von Themenfeldern:

Connector/API:
- Embedded SQL (Pre-Compiler)
- Dynamisches SQL: Connector/C++, MySQL++, C-API
- Prepared Statements
- "normale" Statements, die nicht prepared werden

MySQL Erweiterung:
- Benutzerdefinierte Funktion (UDF)

Wenn Du einfach nur eine SQL-Anweisung in deinem C++-Programm ausführen willst, schau Dir einen der Connectoren an, beispielsweise den MySQL Connector/C++:

http://dev.mysql.com/doc/refman/6.0/en/connectors-apis.html
http://dev.mysql.com/doc/refman/6.0/en/connector-cpp-examples-prepared-statements.html

Unix-Tom sagte es bereits, "Ich möchte mit MySQL auf eine C++ Funktion zugreifen." macht wenig Sinn. Oder willst Du wirklich von einem in der MySQL ausgeführten SQL-Kommando auf ein C++-Programm zugreifen, um in diesem C++-Programm eine Aktion auszulösen?

Ulf

[mysql+c++]

nixnutz schrieb:

Ich verstehe die ursprüngliche Frage nicht. Den Antworten nach zu urteilen geht es anderen nicht viel besser.

Tut mir Leid aber das stimmt so nicht. Ich glaube das geht nur dir so. Unix-Tom hat meinen Lösungsansatz eindeutig verstanden und mich dazu Korrigiert. Nur hat er keinen weiteren Vorschlag bzw. Lösungsansatz für mein bereits im ersten Beitrag beschriebenes Problem angebracht. Was eventuell verständlich ist, weil nicht jeder kann alles Wissen.

nixnutz schrieb:

Im Thread gibt es eine bunte Sammlung von Themenfeldern:

Das kommt daher weil man ein Lösungsansatz sucht.

nixnutz schrieb:

Connector/API:
- Embedded SQL (Pre-Compiler)
- Dynamisches SQL: Connector/C++, MySQL++, C-API
- Prepared Statements
- "normale" Statements, die nicht prepared werden

MySQL Erweiterung:
- Benutzerdefinierte Funktion (UDF)

Keine Ahnung wo das alles stehen soll... Embedded SQL (Pre-Compiler)???
Ist ja eigentlich auch egal. Lies das alles bitte im Kontext.

nixnutz schrieb:

Wenn Du einfach nur eine SQL-Anweisung in deinem C++-Programm ausführen willst, schau Dir einen der Connectoren an, beispielsweise den MySQL Connector/C++:

Hab ich schon im zweiten Beitrag von mir gesagt. Das das mir überhaupt nichts bringt. Wie oft den noch? Lies das mal alles durch.

nixnutz schrieb:

Unix-Tom sagte es bereits, "Ich möchte mit MySQL auf eine C++ Funktion zugreifen." macht wenig Sinn.

Wo sagt er das es wenig Sinn macht? Das sagt er meiner Meinung nach überhaupt nicht. Es sagte sogar in seinem zweiten Beitrag:

Unix-Tom schrieb:

MySQL kann sowas nicht wie MSSQL welche die CLR verwenden kann.

Was Sinn macht oder nicht liegt nicht in deiner Urteilskraft. Schon gar nicht wenn du es nicht verstanden hast? Kann es sein der du der selbe Autor bist wie "Gate"? Genau die selbe Denkweise.

nixnutz schrieb:

Oder willst Du wirklich von einem in der MySQL ausgeführten SQL-Kommando auf ein C++-Programm zugreifen, um in diesem C++-Programm eine Aktion auszulösen?

Mein Problem ist bereits gelöst.
Mein erster Lösungsansatz war, aus einer Procedur (in MySQL) eine C++ Funktion aufzurufen. Das geht mit MySQL nicht (laut Unix-Tom) aber mit beispw. MSSQL geht das und macht auch Sinn. Für vieles! .. beispw. für ein eigenen Passwort-Verschlüsselungsalgorithmus usw.

Verliere nicht das Ziel aus den Augen... das auflösen von einer Variable in MySQL! In dieser Variable steht beispw. ein Tabellenname (siehe erster Beitrag). Aber das Problem habe ich nun gelöst. Aber dennoch war es mir wichtig auf dein Beitrag zu Antworten. Das gehört sich nun einfach mal so.
Grüße.

PS: Viele Leute spielen sich als die großen Macker, wenn die auf ein Beitrag antworten. Es stimmt schon das viele Thread-Autoren unerfahren und ungenau sind. Aber das gibt ihn nicht das Recht darüber zur urteilen, ob es Sinn macht oder nicht. Und das sowieso.. wenn man die Frage nicht Verstanden hat oder der Autor selber die Frage ungenau geschrieben hat. Stattdessen sollte man Fragen 'was derjenige genau machen möchte, eventuell gibt es ja auch einen anderen Lösungsweg'.
Es kann und darf nicht darüber gerichtet werden ob es Sinn macht. Denn der Thread-Autor hat sich ja etwas dabei gedacht um sein Problem zu lösen. Das sein Lösungsansatz falsch ist, ist natürlich möglich. Aber das kann man nur herausbekommen wenn man die oben genannte Frage stehlt und sich weiter darüber unterhält.
Das wollte ich nur mal gesagt haben!

[nixnutz]

mysql+c++ schrieb:

PS: Viele Leute spielen sich als die großen Macker, wenn die auf ein Beitrag antworten. Es stimmt schon das viele Thread-Autoren unerfahren und ungenau sind. Aber das gibt ihn nicht das Recht darüber zur urteilen, ob es Sinn macht oder nicht. Und das sowieso.. wenn man die Frage nicht Verstanden hat oder der Autor selber die Frage ungenau geschrieben hat. Stattdessen sollte man Fragen 'was derjenige genau machen möchte, eventuell gibt es ja auch einen anderen Lösungsweg'.
Es kann und darf nicht darüber gerichtet werden ob es Sinn macht. Denn der Thread-Autor hat sich ja etwas dabei gedacht um sein Problem zu lösen. Das sein Lösungsansatz falsch ist, ist natürlich möglich. Aber das kann man nur herausbekommen wenn man die oben genannte Frage stehlt und sich weiter darüber unterhält.
Das wollte ich nur mal gesagt haben!

Amen.

[nixnutz]

mysql+c++ schrieb:

nixnutz schrieb:

Oder willst Du wirklich von einem in der MySQL ausgeführten SQL-Kommando auf ein C++-Programm zugreifen, um in diesem C++-Programm eine Aktion auszulösen?

Mein Problem ist bereits gelöst.
Mein erster Lösungsansatz war, aus einer Procedur (in MySQL) eine C++ Funktion aufzurufen. Das geht mit MySQL nicht (laut Unix-Tom) aber mit beispw. MSSQL geht das und macht auch Sinn.

Du kannst den MySQL-Server beliebig erweitern. Beispielsweise über eine UDF, http://dev.mysql.com/doc/refman/5.1/en/adding-functions.html und http://dev.mysql.com/doc/refman/5.1/en/adding-udf.html . Die UDF ist eine C/C++ Funktion deiner Wahl.

mysql+c++ schrieb:

Verliere nicht das Ziel aus den Augen... das auflösen von einer Variable in MySQL!

Und wie passt da C++ ins Bild? Wo kommt denn der Wert für Variable her?

Wenn Du ausschließlich mit SQL arbeiten willst, dann hast Du ja gefunden wie Du in der MySQL auf der SQL-Ebene mit SET eine Variable definierst und über den Umweg von Prepared Statements auch auf der SQL-Ebene in einem SQL-Kommando verwendest.

Ulf

[mysql+c++]

Das man den MySQL-Server beliebig erweitern kann, habe ich damals auch gefunden. Aber für meinen Anwendungszweck total umständlich und den Aufwand nicht wert.

Woher die Werte kommen habe ich eigentlich auch schon gesagt:

mysql+c++ schrieb:

Meine Log-Tabelle liefert nicht nur Tabellenname sondern auch Spaltenname, Werte usw.

C++ passte damals so ins Bild das es die Select Anweisung als Zeichenkette + Variable übergeben bekommt und dann die komplette SQL-Anweisung als Zeichenkette zurückgibt.
Also so hier:

cpp_function( "Select * from ", variable_fuer_tabelle );

In c++ würde die Funktion so aussehen:

std::string cpp_function ( std::string sql1, std::string sql2 )
{
  return sql1 + sql2;
}

Wie ich dann die Zeichenkette ausführen wollte, war dann der nächste zu überlegende Schritt. Beziehungsweise habe ich mir damals überhaupt keine Gedanken gemacht. Aber nun habe ich das ohne Umwege geschafft. Warum ohne Umwege? Siehe dazu:
http://de.wikipedia.org/wiki/Prepared_Statement

Selbst wenn das mit C++ funktioniert hätte, hätte ich dennoch die Zeichenkette mit PREPARE und EXECUTE verwenden müssen. Die Schwächen meines Lösungsansatzes sind mir im Nachhinein klar geworden. (Das Bedeutet aber nicht das es Sinnlos ist von MySQL auf C++-Funktion zuzugreifen!)
Das Stichwort von 'hustbaer': "dynamic SQL" ist hier entscheidend!
Aber das habe ich schon alles selber herausbekommen

Problematik verstanden?

[hustbaer]

@mysql+c++:
Ich hab aber auch erst nach deinem "CONCAT/PREPARE/EXECUTE" Posting verstanden was du eigentlich willst.
Die Aussage

Ich verstehe die ursprüngliche Frage nicht. Den Antworten nach zu urteilen geht es anderen nicht viel besser.

kann ich also unterschreiben.

Lern dich besser auszudrücken. Und vor allem: beschreibe was du machen möchtest, nicht wie du es angehen willst.

Das ist auch einer der Gründe, warum immer wieder und wieder die Antwort "das macht keinen Sinn" kommt: weil Leute ihren halbgaren Lösungsansatz beschreiben, für ein Problem dass sie oft nicht ausreichend verstehen, ohne dabei aber das Problem zu beschreiben.

Ich gebe dir zwar Recht wenn du schreibst dass es öd ist wenn Leute kein Feedback geben.

Was die restlichen Dinge angeht eher nicht.

[nixnutz]

mysql+c++ schrieb:

Das man den MySQL-Server beliebig erweitern kann, habe ich damals auch gefunden. Aber für meinen Anwendungszweck total umständlich und den Aufwand nicht wert.

Naja, und das hat mich auch aus der Bahn geworfen: was macht er da...

mysql+c++ schrieb:

Woher die Werte kommen habe ich eigentlich auch schon gesagt:

mysql+c++ schrieb:

Meine Log-Tabelle liefert nicht nur Tabellenname sondern auch Spaltenname, Werte usw.

Hmm, was mir dabei nicht klar war ist, ob Du auf der SQL-Ebene im Datenbankserver etwas erreichen möchtest oder...

mysql+c++ schrieb:

C++ passte damals so ins Bild das es die Select Anweisung als Zeichenkette + Variable übergeben bekommt und dann die komplette SQL-Anweisung als Zeichenkette zurückgibt.
Also so hier:

cpp_function( "Select * from ", variable_fuer_tabelle );

innerhalb einer Anwendung, innerhalb eines Clients.

mysql+c++ schrieb:

In c++ würde die Funktion so aussehen:

std::string cpp_function ( std::string sql1, std::string sql2 )
{
  return sql1 + sql2;
}

Wie ich dann die Zeichenkette ausführen wollte, war dann der nächste zu überlegende Schritt.

Da passt die Antwort rein, daß Du den MySQL Connector/C++ verwenden könntest. Oder MySQL++ oder die C-API mit "etwas" Casting.

mysql+c++ schrieb:

Beziehungsweise habe ich mir damals überhaupt keine Gedanken gemacht. Aber nun habe ich das ohne Umwege geschafft. Warum ohne Umwege? Siehe dazu:
http://de.wikipedia.org/wiki/Prepared_Statement

Selbst wenn das mit C++ funktioniert hätte, hätte ich dennoch die Zeichenkette mit PREPARE und EXECUTE verwenden müssen.

Stop - ich komme nicht mit. Springst Du hier zwischen Client und Server hin und her? Laß mich versuchen, dein Problem mit meinen Worten zu wiederholen.

Du hast irgendwo in der Datenbank eine Tabelle, nenne sie "Log". Diese Tabelle "Log" enthält Spalten in denen der Name anderer Tabellen enthalten ist. Beispielsweise steht in der Tabelle "Log":

id wert1 name_anderer_tabelle
1 100 "tabelle2"
2 24 "tabelle3"

Du möchtest die Tabelle "Log" auslesen und die gefundenen Werte verwenden, um Anfragen an die in der Tabelle "Log" in der Spalte "name_anderer_tabelle" gespeicherten Tabellen zu stellen.

Es sind also folgende Schritte auszuführen:

1. Lese "Log" aus
2. Erstelle neue Anfrage aus Werten von "Log"
3. Sende neue Anfrage

Wenn ich diese Aufgabe lösen sollte, dann würde ich entweder ein Clientprogramm schreiben, welches die gewünschte Operation ausführt oder ich belasse die Logik auf dem Server, auf der SQL-Ebene, beispielsweise in einer Stored Procedure.

Mit anderen Worten: ich mache 1-3 entweder komplett auf dem Client oder komplett auf dem Server. Jetzt dämmert mir langsam, daß Du alles auf dem Server machen wolltest, aber weil Dir ein kleines Stückchen fehlte (CONCAT, dynamic SQL), Du nach 1) für 2) auf den Client wechseln wolltest.

Mir würde es nie in den Sinn kommen hier zu mixen und einen Wechsel der Ausführungsebene vorzunehmen. Mit wäre es viel zu "teuer", einen Kontextwechsel zu vollziehen. Ich möchte nicht wissen wie rechenintensiv es ist externes Programm aufzurufen und dies einen Teil der Arbeit übernehmen zu lassen. Selbst wenn der Programmstart "billig" ist, beispielsweise, weil die MySQL UDF in den MySQL Server einkompiliert ist, erfolgt immer noch ein Kontextwechsel in einen Benutzer-Bereich (UDF = *user* defined function), also in einen Bereich dem ich als Datenbank nicht vertrauen darf.

Zudem würde ich mich zwei Mal fragen ob ich Logik an zwei Stellen ablegen will, weil dies bedeutet, daß ich zwei Stellen warten muss. Die Vorstellung, daß das jemand machen will hat bei mir ausgelöst.

mysql+c++ schrieb:

Beziehungsweise habe ich mir damals überhaupt keine Gedanken gemacht. Aber nun habe ich das ohne Umwege geschafft. Warum ohne Umwege? Siehe dazu:
http://de.wikipedia.org/wiki/Prepared_Statement

Selbst wenn das mit C++ funktioniert hätte, hätte ich dennoch die Zeichenkette mit PREPARE und EXECUTE verwenden müssen.

Das bezieht sich wieder auf die Situation in der Du einen Teil von 1-3 auf dem Client machst und einen Teil davon auf dem Server. Was Du schreibst ist richtig, wenn Du die Konkatenation (das Verbinden) der Zeichenketten - 2) - auf dem Client machst und den Rest auf dem Server.

Wenn Du alle Schritte auf dem Client machst, dann ist es nicht zwingend notwendig Prepared Statements zu benutzen. Bei Ausführung aller Schritte auf dem Client, kannst Du auch ein "normales" Statement verwenden.

<code>
[...]
stmt = con->createStatement();
stmt->execute("USE " EXAMPLE_DB);
[...]
</code>
http://dev.mysql.com/doc/refman/6.0/en/connector-cpp-examples-query.html

Das SQL-Kommando, welches Du derartig an den Server sendest, sollte selbstverständlich gültig sein, damit es tut was Du willst. Gegebenenfalls sind die Zeichenketten, die im SQL-Kommando verwendet werden zu escapen. "Schadhafte" Zeichenketten, die im Extremfall SQL-Injection ermöglichen, sind von Dir zu entfernen. Die Datenbank wird genau das ausführen, was Du ihr sagst. Wenn Du ihr ein defektes SQL-Kommando sendet, wird die Antwort von MySQL entsprechend ausfallen.

Bei der Verwendung von Prepared Statements in einer rein client-basierten Lösung ist weiter zu differenzieren: arbeitet der Client mit einer Prepared-Statement Emulation oder verwendet er die Prepared Statements des MySQL-Server, verwendest Du die Client-API für Prepared Statements oder die SQL-Syntax mit PREPARE und EXECUTE.

1. Client-basierte Lösung, Prepared Statements (PS) des MySQL-Servers, PS mittels API

<code>
prep_stmt = con->prepareStatement("INSERT INTO test(id, label) VALUES (?, ?)");

prep_stmt->setInt(1, 1);
prep_stmt->setString(2, "a");
prep_stmt->execute();
</code>
http://dev.mysql.com/doc/refman/6.0/en/connector-cpp-examples-prepared-statements.html

Harken für deine Aufgabenstellung: Du kannst keinen Tabellennamen binden. Prepared Statements trennen variable Werte von gleichbleibenden SQL-Kommandos. Sie parametrisieren SQL-Kommandos.

2. Client-basierte Lösung, Prepared Statement Emulation, PS mittels API

Andere Programmiersprache, aber egal für die Grundsatzdiskussion:
http:://php.net/pdo

PDO kann Prepared Statements emulieren, um diese über eine formalisierte API bereitzustellen. Die Emulation erstellt SQL auf dem Client, für Dich unsichtbar, und führt ein ordnungsgemäßes escapen der Werte durch. Es wird ein normales Statement ausgeführt. Das ist im Prinzip wie http://dev.mysql.com/doc/refman/6.0/en/connector-cpp-examples-query.html (siehe oben), nur daß in der Emulation ordentlich escaped wird, um SQL-Injection zu unterbinden.

3. Client-basierte Lösung, PREPARE und EXECUTE

Es löst deine Aufgabe - mehr nicht. Wenn es keinen triftigen Grund gibt, diese Variante zu wählen verzichtest Du auf das, wonach 99% der PS-Anwender lechtzen: Trennung von (potentiell vergifteten) Daten und SQL-Kommando auf der Leitung, um die Aufgabe des Bereinigens der Daten zu verlagern und ggf. Verringerung des Netzwerktraffics, der entsteht wenn bei wiederholter Ausführung nur die Daten und nicht das Kommando ausgeführt wird.

Kurz: bei einer ausschließlich client-basierten Lösung des Problems ist es nicht zwingend notwendig Prepared Statements zu verwenden. Schon gar nicht bist Du gezwungen PREPARE/EXECUTE einzusetzen. Es ist eine Möglichkeit von vielen.

mysql+c++ schrieb:

Beziehungsweise habe ich mir damals überhaupt keine Gedanken gemacht. Aber nun habe ich das ohne Umwege geschafft. Warum ohne Umwege? Siehe dazu:
http://de.wikipedia.org/wiki/Prepared_Statement

Selbst wenn das mit C++ funktioniert hätte, hätte ich dennoch die Zeichenkette mit PREPARE und EXECUTE verwenden müssen.

Die Verwendung eines Prepared Statements siehst Du nicht als Umweg an, weil Du damit deine rein server-basierte Lösung bekommst. Über die Krücke der Prepared Statements baust Du Dir Dynamic SQL im MySQL Server. Das ist Dreck ! Wer Prepared Statements nur verwendet, um damit Dynamic SQL zu relalisieren sollte sich darüber im Klaren sein, daß er sie vergewaltigt. Bevor Du wieder einen Anfall bekommst: bis heute gibt es keine andere Möglichkeit eine rein server-basierte (ohne UDF) Lösung für dein Problem zu erstellen.

Was Du eigentlich willst ist EXECUTE IMMEDIATE:
http://forge.mysql.com/worklog/task.php?id=2793

Prepared Statements sind dazu da, um SQL-Kommandos zu parametrisieren. Sie trennen das eigentliche Kommando von seinen Daten. Das kann genutzt werden, um die Netzwerklast zu reduzieren, als Tipp an die Datenbank mehr Zeit für die Ausarbeitung eines Ausführungsplans zu investieren, weil mit mehrfacher Ausführung zu rechnen ist, als Ausrede seine Eingabedaten nicht bereinigen zu müssen, weil ja der Parser der Datenbank die Arbeit viel besser erledigen könne und, und, und.

Bis hin zum MySQL spezifischen Effekt, daß ein anderes Kommunikationsprotokoll zwischen Client und Server zum Einsatz kommt, welches mal weniger mal mehr Traffic beim Senden von Resultsets zum Client bewirkt (binary vs. text protocol) und mal mehr mal weniger CPU-Zeit auf dem Server verbrät (Stichwort: string casts).

mysql+c++ schrieb:

Problematik verstanden?

Und, hast Du auch verstanden was Du da vorhattest und was Du jetzt machst, um Dir Dynamic SQL innerhalb einer rein server-basierten Lösung zu basteln.

Ulf

[mysql+c++]

hustbaer schrieb:

Ich hab aber auch erst nach deinem "CONCAT/PREPARE/EXECUTE" Posting verstanden was du eigentlich willst.

Kann ja sein .. das du es später verstanden hast. Aber das geht absolut nicht von den Antworten heraus (nicht nur deine). Also das es den anderen auch so geht ist dementsprechend falsch und kann nicht unterschrieben werden. Er hätte sagen sollen das es es nicht versteht und Punkt.

hustbaer schrieb:

Lern dich besser auszudrücken. Und vor allem: beschreibe was du machen möchtest, nicht wie du es angehen willst.

Jeder muss dazu lernen .. da bin ich keine Ausnahme. Ich weiß ja selber das ich in dem Bezug schwächen habe. Aber dennoch habe ich im ersten Beitrag beschrieben was ich eigentlich machen möchte und mein Lösungsansatz war nur die hälfte vom Beitrag:

mysql+c++ schrieb:

Was ich zu lösen versuche ist das auflösen von Variablen in SQL-Anweisungen.
Genauer:
SELECT * FROM variable_fuer_eine_tabelle;

Da MySQL nicht die Variable auflöst und nachschaut was sich hinter "variable_fuer_eine_tabelle" verbirgt, bin ich gezwungen das ganze auszulagern. Die SQL-Anweisung einem C++ Programm übergeben und die komplette aufgelöste Zeichenkette zurückzubekommen, ist das Ziel.

hustbaer schrieb:

Das ist auch einer der Gründe, warum immer wieder und wieder die Antwort "das macht keinen Sinn" kommt: weil Leute ihren halbgaren Lösungsansatz beschreiben, für ein Problem dass sie oft nicht ausreichend verstehen, ohne dabei aber das Problem zu beschreiben.

Zu Thema Sinn oder Unsinn habe ich schon dazu was gesagt. Die Leute stehen einfach nicht in der Position das zu entscheiden. Schon gar nicht wenn sie es nicht verstehen. Wieso soll man in der Position sein, zu sagen 'es macht kein Sinn' ohne das eigentliche Problem zu kennen .. weil der Autor selber das ungenügend beschreibt. Dazu habe ich auch schon das PS geschrieben:

mysql+c++ schrieb:

PS: Viele Leute spielen sich als die großen Macker, wenn die auf ein Beitrag antworten. Es stimmt schon das viele Thread-Autoren unerfahren und ungenau sind. Aber das gibt ihn nicht das Recht darüber zur urteilen, ob es Sinn macht oder nicht. Und das sowieso.. wenn man die Frage nicht Verstanden hat oder der Autor selber die Frage ungenau geschrieben hat. Stattdessen sollte man Fragen 'was derjenige genau machen möchte, eventuell gibt es ja auch einen anderen Lösungsweg'.
Es kann und darf nicht darüber gerichtet werden ob es Sinn macht. Denn der Thread-Autor hat sich ja etwas dabei gedacht um sein Problem zu lösen. Das sein Lösungsansatz falsch ist, ist natürlich möglich. Aber das kann man nur herausbekommen wenn man die oben genannte Frage stehlt und sich weiter darüber unterhält.
Das wollte ich nur mal gesagt haben!

Und keiner hat über das eigentliche Problem unterhalten.

Da du jetzt mittlerweile alles verstanden hast und immer noch der Meinung bist das ich den ersten Beitrag ungenügend beschrieben habe. Dann kannst du mal die Frage selber Formulieren .. ich muss ja auch dazu lernen. Schreibe einfach wie du es gemacht hättest. Natürlich musst du meinen Lösungsansatz mit einbauen bzw. vorschlagen.

[zwutz]

dein Fehler war, dass du dein Problem falsch beschrieben hast... so hat man es auch falsch verstanden und den Sinn nicht entdeckt... ich dachte bei deinem ersten Posting, du willst aus SQL heraus C++-Funktionen aufrufen... und das macht wirklich keinen Sinn... und ja, einige hier sind durchaus in der Lage, den Sinn einer Sache anzuzweifeln auch wenn der Fragesteller von der Sinnhaftigkeit überzeugt ist... nennt man gemeinhin "Erfahrung"

Hättest du einfach geschrieben, du willst wissen, wie man Variablen in SQL-Anweisungen verwendet wär die Sache deutlich klarer gewesen...

[mysql+c++]

zwutz schrieb:

ich dachte bei deinem ersten Posting, du willst aus SQL heraus C++-Funktionen aufrufen... und das macht wirklich keinen Sinn...

Das ist auch das was ich ursprünglich wollte. Also habe ich mich richtig ausgedrückt. Und das macht SINN! Noch nie einen eigenen Passwort-Algorithmus geschrieben? Das ist ein sehr bekanntes Beispiel .. das die Passwörter mit einen eigenen Algorithmus verschlüsselt und in die Datenbank gespeichert werden (und nicht unbedingt vorher verschlüsselt werden, den dieser Anwendungsfall ist nicht immer möglich).

zwutz schrieb:

und ja, einige hier sind durchaus in der Lage, den Sinn einer Sache anzuzweifeln auch wenn der Fragesteller von der Sinnhaftigkeit überzeugt ist... nennt man gemeinhin "Erfahrung"

Erfahrung hin oder her ... es geht einfach nicht. Denn man zweifelt über das was man verstanden hat ... und man hat einfach nicht das verstanden was der Fragesteller gemeint hat. Aus diesem Grund sollte man Fragen bevor man voreilige Schlüsse zieht. Das ist genau wie mit Vorurteile .. als würde ich meinen Kindern erklären das man das nicht machen sollte. Nicht erst losschießen und dann sich darüber Unterhalten. Sondern davor! Das ist ein Grundsatz den jeder einhalten sollte.
Den Fragesteller nützt es über nichts wenn einer sagt es macht kein Sinn. Es sollte lieber entgegenkommen und fragen. Die Frage habe ich schon so oft zitiert:
'was derjenige genau machen möchte, eventuell gibt es ja auch einen anderen Lösungsweg'.

zwutz schrieb:

Hättest du einfach geschrieben, du willst wissen, wie man Variablen in SQL-Anweisungen verwendet wär die Sache deutlich klarer gewesen...

Ich habe geschrieben, das ich wissen will wie ich eine Variable auflöse und das ist ja 'verwenden'. Damit ist alles klar.

[mysql+c++]

@nixnutz: upps, hab dein Beitrag übersehen. Da ich zu der zeit meinen eigenen Beitrag geschrieben habe :). Werde demnächst darauf antworten, erstmal muss das Essen vorbereitet werden. Dann gegessen usw.