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.

Delphi-Quellcode:

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'

[baumina]

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

Delphi-Quellcode:

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

[Furtbichler]

Zitat:

Zitat von Perlsau (Beitrag 1234891)

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

Der ist ja auch geheim!

[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:

Zitat von sx2008 (Beitrag 1234951)

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 :stupid:

[DeddyH]

Zitat:

Zitat von Furtbichler (Beitrag 1234984)

Nun ratet mal, womit ich mich rumschlagen durfte :stupid:

Mit dem eigenen Ego? :stupid: :tongue:

[Furtbichler]

Zitat:

Zitat von DeddyH (Beitrag 1234989)

Zitat:

Zitat von Furtbichler (Beitrag 1234984)

Nun ratet mal, womit ich mich rumschlagen durfte :stupid:

Mit dem eigenen Ego? :stupid: :tongue:

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

[sx2008]

Zitat:

Zitat von Furtbichler (Beitrag 1234984)

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.

Das sind kleine tickende Zeitbomben die dann hochgehen wenn man's nicht erwartet.
Datenbanken versch. Hersteller verwenden ja nicht mal einheitliche Quotezeichen ("" oder [] oder ´´).

Kleines Beispiel: man hat eine komplexe Abfrage mit 5+ Tabellen und irgendwo hat man versehentlich das quoten eines Feldnamens vergessen. Jede Wette dass man eine völlig unverständliche SQL Fehlermeldung bekommt und zunächst nicht versteht was eigentlich das Problem ist. Oder man verwendet ein reserviertes Wort; es kann Tage dauern bis man den Fehler gefunden hat.

Hier ist eine Vermeidungsstrategie angesagt.
Defensives Programmieren zahlt sich langfristig aus.

[p80286]

Ihr dürft nicht vergessen, daß es hier um Access geht. Da ist einiges anders als bei anderen Datenbanken. Meistens ist [Tabelle].[Feld] richtig.
Manchmal muß es aber auch [Eigentümer].[Tabelle].[Feld] sein, und machmal reicht ein Tabelle.Feld der nackte Feldbezeichner hat bei mir allerdings noch nie geklappt.

Gruß
K-H

[Bernhard Geyer]

Zitat:

Zitat von p80286 (Beitrag 1235078)

Ihr dürft nicht vergessen, daß es hier um Access geht.

Der ist gut, weil er auch stimmt. Von mir ein +1

Bei Access ist auch der zugriffsweg (BDE/ADO direkt/ODBC/direkt in Access...) relevant. Je nach Weg versteht Access manche Befehle nicht mehr.

[mkinzler]

Zitat:

Zitat von Smut (Beitrag 1234986)

Wenn ich Firebird und IBDAC benutze muss ich aber nicht unbedingt 'Name' für den in der DB zusammengesetzten 'gesamten Namen' benutzen, oder?
Klar bekomme ich das auch zum Laufen, macht aber viel mehr Arbeit, als wenn ich gleich was gescheites nehme.

Und was wäre "was Gescheites?"

[p80286]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1235080)

Bei Access ist auch der zugriffsweg (BDE/ADO direkt/ODBC/direkt in Access...) relevant. Je nach Weg versteht Access manche Befehle nicht mehr.

Und ich hab mich immer gewundert....

Schade, daß Kreuzigungen nicht mehr so richtig in sind! :mrgreen:

Gruß
K-H

[Furtbichler]

Zitat:

Zitat von p80286 (Beitrag 1235086)

Schade, daß Kreuzigungen nicht mehr so richtig in sind! :mrgreen:

Sagt wer?

[mkinzler]

In dem Tempo, in dem wir uns ins Mittelalter zurückbewegen sind die bestimmt bald wieder "in"

[Furtbichler]

Man sollte in den Online-Handel mit Kreuzen, Steinen, Lärchenzungen, Wolfszitzenchips und Ozelotleber investieren. Das könnte sich bald lohnen.