ADO Fehler nach Selct-anweisung

[Luckner]

Hallo,

"
DatamoduleAuftrag.DataModule2.ADOConnection1.Conne cted := false;
DatamoduleAuftrag.DataModule2.ADOConnection1.conne ctionstring := 'Provider=Microsoft.Jet.OLEDB.4.0; Data Source=C:\Projekte\Bertram\Datenbank\EB-XP.mdb; User ID=Admin;Password=;';
DatamoduleAuftrag.DataModule2.ADOConnection1.Conne cted := true;

DatamoduleAuftrag.DataModule2.ADOQueryEtikbase.Act ive := False;
DatamoduleAuftrag.DataModule2.ADOQueryEtikbase.SQL .Clear;
DatamoduleAuftrag.DataModule2.ADOQueryEtikbase.SQL .Add('select * from Artikel where Art-Nr = 13476');
DatamoduleAuftrag.DataModule2.ADOQueryEtikbase.Ope n; "

Bekomme nach dieser Anweisung einen Fehler 'ParameterArt hat keinen Standartwert'. Welcher Wert ist hier gemeint?

Gruß, Luckner

[mkinzler]

Ein "Mussparameter" scheint im Connectionstring zu fehlen

[Perlsau]

Wenn du deinen Quellcode im Foren-Editor markierst und danach auf den Button mit dem Helm klickst, wird der markierte Text in Delphi-Tags eingeschlossen, wodurch er besser lesbar wird.

Zu deinem Code: Ich erkenne mehrere Leerzeichen, wo sie nicht hingehören, weiß aber nicht, ob das nur am Foren-Editor liegt oder ob die bei dir tatsächlich vorhanden sind.

Der fehlende Standardwert dürfte Password sein: Dort steht nach dem = kein Wert. Wenn du kein Passwort vergibst, dann laß doch die beiden Parameter User und Password weg.

DatamoduleAuftrag.DataModule2.ADOConnection1.connectionstring := 'Provider=Microsoft.Jet.OLEDB.4.0; Data Source=C:\Projekte\Bertram\Datenbank\EB-XP.mdb; UserID=Admin;Password=;';
Bei mir steht im ConnectionString, wenn ich kein Passwort verwende, noch 'Persist Security Info=False'

[Furtbichler]

Zitat von Perlsau:

Der fehlende Standardwert dürfte Password sein: Dort steht nach dem = kein Wert.

Der ist ja auch geheim!

[baumina]

Problem ist sicher der Bindestrich im Feldnamen. Versuche es mal so:

DatamoduleAuftrag.DataModule2.ADOQueryEtikbase.SQL .Add('select * from Artikel where Artikel.[Art-Nr] = 13476');

Ist das Feld Art-Nr tatsächlich nummerisch? Ansonsten fehlen da Anführungszeichen.

[Luckner]

Funktioniert. Baumina, Danke Dir für die Lösung.

Gruß, Luckner

[sx2008]

Das ist übrigens der Grund weshalb man ein Feld niemals "Art-Nr" nennen sollte.
Der Bindestrich wird von der SQL Engine als Minuszeicen erkannt sollte innerhalb eines Feld- oder Tabellennamens nicht verwendet werden.
Ganz einfache Regel:
alles was Delphi/Pascal verboten ist sollte man auch nicht in Datenbanken verwenden:

Delphi-Quellcode:

var
  Art-Nr : string; // verboten
  Art_Nr : string; // ok
  R&D : string;    // verboten
  24stunden:Boolean; // verboten, beginnt mit Ziffer
  Möhre: double;   // verboten, Umlaut

Das Quoten der Feld-/Tabellennamen ist keine dauerhafte Lösung, denn irgendwann kommt ein Tool das nicht quoted und schon sind die Probleme wieder da.

[Furtbichler]

Zitat von sx2008:

Das Quoten der Feld-/Tabellennamen ist keine dauerhafte Lösung, denn irgendwann kommt ein Tool das nicht quoted und schon sind die Probleme wieder da.

Mag schon sein, nur ist ein Tool, das nicht quoted 'a waste of hd space'. Das ist ja sogar ANSI SQL, denn ohne 'quoten' wären auch Feldnamen wie 'select', 'user', 'database' usw. (also alle reservierten Wörter) für dieses Tool verboten.

Ich habe kein Problem damit, eine View zu erstellen, die lesbare Tabellenüberschriften als Spaltennamen enthält. Dann muss man sich im Report-Designer wenigstens keine Überschriften ausdenken.

Code:

select [Art-Nr],
       [R&D] 
  from [Komische Tabelle]

Ist nicht nur perfektes SQL, sondern muss auch von jedem 'Tool', das über das Frickelstadium hinaus geht, bedient werden können. Ein Tool, was das nicht kann, bastelt sich irgendwelche SQL-Befehle selbst zusammen und wer so etwas so blöd macht, der hat bestimmt auch noch nie was von SQL-Injection gehört. Also: Finger weg von so einem Tool.

Allerdings schadet es nicht, die Feldnamen der Tabellen so zu gestalten, das sie ein 1:1 Äquivalent in der Programmiersprache der Wahl haben, denn es ist nun einem wesentlich übersichtlicher, wenn das ORM-Pendant einer Tabelle, nämlich der Klassenname und die Properties, exakt die gleiche Schreibweise aufweisen wie Tabelle und Felder.

Tabelle: 'Person' => Klasse 'TPerson'. Feldname: 'Vorname' => Property 'Vorname'. Einfacher und klarer geht's ja wohl kaum.

Wenn man schon OT über Feldnamen philosophiert, dann doch imho so: Bitte bitte keine blöden Abkürzungen. 'VORN,NACHN' ist totaler Cretinismus, wenn man auch 'Vorname, Nachname' verwenden kann. Wie oft ich diesen hirnverbrannten Schwachsinn in Datenbanken schon gesehen habe, erschüttert meinen Glauben an die Menschheit. Getoppt wird das nur noch durch die Verwendung der ungarischen Notation, also dem Voranstellen des Feldtypen und dem stringenten durchziehen der Maxime, das nur exakt 6 Buchstaben lange Feldnamen gute Feldnamen sind.

Einige SAP-Entwickler sind übrigens auch Kandidaten für Teeren-und-Federn aufgrund krankhafter Feldnamenverschlüsselung.

So. Feierabend. Hatte heute übrigens einen schöööönen Tag. Nun ratet mal, womit ich mich rumschlagen durfte

[Furtbichler]

Zitat von DeddyH:

Zitat von Furtbichler:

Nun ratet mal, womit ich mich rumschlagen durfte

Mit dem eigenen Ego?

Nein, daran habe ich mich gewöhnt. Wir kennen uns schon ein Weilchen, musst Du wissen.