ich habe folgendes Problem:

Wenn ich eine BDE-Komponente benutze (und zwar die Query-Komponente), dann kann ich ganz leicht folgenden Code ausführen

Query2->SQL->Clear();

Query2->SQL->Add("INSERT INTO COUNTRY (NAME, CAPITAL, POPULATION) ");
Query2->SQL->Add("VALUES (:Name, :Capital, :Population) ");

Query2->Params->Items[0]->AsString = "Liechtenstein";
Query2->Params->Items[1]->AsString = "Vaduz";
Query2->Params->Items[2]->AsInteger = 420000;
Query2->ExecSQL();

Jetzt benutze ich aber eine ADOQuery Komponente. Diese unterstützt auch die gleichen Methoden außer dem Params!

Bei dieser ist es nur möglich

ADOQuery->Parameters->Items

zu definieren, doch das ist nicht das gleiche wie bei der BDE-Komponente! Wie kann ich das mit dieser ADO_Komponente denn lösen???

Danke für die Antworten!

Gruß

INSERT INTO COUNTRY VALUES('Liechtenstein','Vaduz',420000);

ADOQuery->Parameters->Items[0]->Value = "Liechtenstein";

ausserdem ist es günstiger die Parameters per Name anzusprechen, z.B.

ADOQuery->Parameters->ParamByName("Name")->Value = "Liechtenstein";

ausserdem ist es günstiger die Parameters per Name anzusprechen

Es ist immer günstiger sowas über SQL zu erledigen.

SQL verwendet er ja schon im Query, aber die Abfrage soll ja durch die Parameter ermöglichen verschiedene Daten einzutragen und nicht durch unübersichtliche Stringoperationen oder Programmcodeersetzung die Eingabe weiterer Datensätze für den User zu ermöglichen, denn eventuell hat der End-User keine Ahnung von SQL. So kann der Endbenutzer die Daten in Editfelder eingeben und diese werden dann per Knopfdruck in die Datenbank geschrieben...

aber ich schätze mal der Sinn der Komponentenbenutzung ist für manche einfach zu nicht zu verstehen...

na klar, für jedes insert schreibt er im Quelltext ein eigenes SQL-Statment...

No, braucht er nicht, das geht viel eleganter und kürzer.
Man kann sich die Sache natürlich auch unnötig kompliziert machen ...

aber ich schätze mal der Sinn der Komponentenbenutzung ist für manche einfach zu nicht zu verstehen...

Das weisst du ja aus eigener Erfahrung ...

No, braucht er nicht, das geht viel eleganter und kürzer.
Man kann sich die Sache natürlich auch unnötig kompliziert machen ...

na dann bitte ich doch mal um ein Beispiel, schließlich bin ich ja lernfähig/lernwillig

while(pos<country->Count)
{
   query->SQL->Clear();
   query->SQL->Add("INSERT INTO country VALUES("+IntToStr(pos)+",'"+country->Strings[pos++]+"')");
   query->ExecSQL();
}

*seufz* also doch unübersichtliche Stringoperationen im Quellcode...

*seufz*
Was manche so unübersichtlich nennen.

Weiß jemand, ob das im BCB einen (Geschwindigkeits-) Unterschied macht?

Mich würde auch interessieren ob Parameter bei BCB, das SQL-Kommando "zerlegen" können.
Und zwar in der Form:
Werden bspw. Hochkommas im Parameterinhalt so gekapselt, daß diese sqlseitig als Teil des Wertes und nicht als Stringabschluß betrachtet werden?

Linnea schrieb:

*seufz* also doch unübersichtliche Stringoperationen im Quellcode...

*seufz*
Was manche so unübersichtlich nennen.

Das ist nicht nur unübersichtlich, sondern auch gefährlich. Was, wenn das Programm mal auf einem Rechner läuft, der nicht das Gebietsschema Deutsch eingestellt hat und ein Datum ein Suchkriterium ist? Reicht sogar schon, wenn nur bei der DB das falsche Gebietsschema eingestellt ist. Das gilt dann natürlich auch für Punkte und Kommas in Zahlen. Frickel Du ruhig ohne Parameter weiter und such Dir nen Wolf, wenn es dann mal Probleme gibt...

In SQL sind Parameter gang und gäbe. Was wären Stored Procedures ohne Parameter?

Außerdem sollte es keinen Unterschied machen, ob ein Statement mit oder ohne Parametern verwendet wird. Performanceunterschiede ergeben sich im Regelfall erst dann, wenn der Cursor falsch gesetzt ist, respektive das Statement nicht vorbereitet wird.

Das ist nicht nur unübersichtlich, sondern auch gefährlich. Was, wenn das Programm mal auf einem Rechner läuft, der nicht das Gebietsschema Deutsch eingestellt hat und ein Datum ein Suchkriterium ist? Reicht sogar schon, wenn nur bei der DB das falsche Gebietsschema eingestellt ist. Das gilt dann natürlich auch für Punkte und Kommas in Zahlen. Frickel Du ruhig ohne Parameter weiter und such Dir nen Wolf, wenn es dann mal Probleme gibt...

Ich find Parameter auch übersichtlicher.

Mir ist neu daß bei SQL-Datenbanken das Gebietsschema eine Rolle spielt.
Datetimes, Decimals etc. werden bei den Systemen mit denen ich arbeite (MS-SQL-Server,Centura)immer gleich gespeichert. Lediglich die Anzeige kann länderspezifisch erfolgen, wass zum Speichern und für Vergleiche keine Rolle spielt.

2006-02-15 = 15.02.2006

Bei welchen Datenbanken ist das anders ?

Das ist nicht nur unübersichtlich, sondern auch gefährlich. Was, wenn das Programm mal auf einem Rechner läuft, der nicht das Gebietsschema Deutsch eingestellt hat und ein Datum ein Suchkriterium ist? Reicht sogar schon, wenn nur bei der DB das falsche Gebietsschema eingestellt ist. Das gilt dann natürlich auch für Punkte und Kommas in Zahlen. Frickel Du ruhig ohne Parameter weiter und such Dir nen Wolf, wenn es dann mal Probleme gibt...

Das ist absolut nicht gefährlich.
Sowas fängt man gekonnt ab.Bisher ohne Probleme.

Mir ist neu daß bei SQL-Datenbanken das Gebietsschema eine Rolle spielt.
Datetimes, Decimals etc. werden bei den Systemen mit denen ich arbeite (MS-SQL-Server,Centura)immer gleich gespeichert. Lediglich die Anzeige kann länderspezifisch erfolgen, wass zum Speichern und für Vergleiche keine Rolle spielt.

2006-02-15 = 15.02.2006

Es spielt auch keine Rolle, da man fürs Datum eigentlich nur timestamp verwendet.