[C++Builder] ADOQuery mit Parameter setzen

Bitte schön:

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

Linnea

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

Linnea schrieb:

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

*seufz*
Was manche so unübersichtlich nennen.

Ja es gibt schon einige, die sich halt davor drücken wollen SQL zu lernen.

caspar_louis

Ich kann nicht beurteilen ob das bei BCB auch so ist. Bei Centura-SAL ist die Verarbeitung deutlich schneller, wenn erst ein (unübersichtlicher) SQL-String zusammengebaut und dann ausgeführt wird als wenn mit Parameterübergaben gearbeitet wird.

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?

rama schrieb:

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.

caspar_louis

Joe_M. schrieb:

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.

Man sollte eigentlich auch grundsätzlich auf der einen Seite seine Eingabemaske und auf der anderen seine Klasse die fürs Handling mit der Datenbank zuständig ist.
Bei mir kommt nie das was ein Benutzer eingibt ungeprüft in die Datenbank.
Was ich da von Joe M. höre verwundert mich eher...