4. Widerspenstiges Datenbankfeld

Widerspenstiges Datenbankfeld

  • T

    Hallo,

    nach längerer Abstinenz mit Datenbanken holt es mich nun doch wieder ein: Ich habe eine ACCESS Db. Dort füge ich mit INSERT INTO Daten ein:

    INSERT INTO [Images] 
(Name, Vorname, Geburtsdatum, LfdNr, Diagnose, Geschlecht, Datensatzname, Bildpfad, Dateiname, Bildname, Attribute, Datenträger-Nr, Datenträgerkennung) 

VALUES ( 'Testiger0', 'Test0', '12.12.2001', '', 'Whatever', '', 'Testiger0, Test0','\\Rsc015\D\Archive\InsImgs\Angio5 _ 56', 'Angio5 _ 56', 'Testiger0, Test0', 0, 3, 'Demo Volume #3' )

    Funktioniert super, bis auf das Feld Datenträger-Nr. Gut hab, hab ich mir gedacht, las ich es halt weg und mach danach ein UPDATE:

    UPDATE Images SET Datenträgerkennung=1

    schade nur, das er mir da auch einen Fehler um die Ohren wirft: "Syntaxfehler in UPDATE Anweisung". Nein, es ist wirklich ein int Wert.

    Mache ich das ganze im Nachgang mit DAO funktioniert es wie es soll:

    m_pImageTable->Edit();//m_pImageTable is a CDaoRecordset
    m_pImageTable->SetFieldValue( "Datenträger-Nr", m_CurrVolume.first.c_str() );
m_pImageTable->Update();

    wie werde ich dieses häßlich DAO - Workaround wieder los, bzw. was kann an diesem komischen Feld sein, das es sich mit SQL nicht setzen läßt?

    eventuell ist dieser Beitrag auch im MFC - Forum besser aufgehoben -> dann bitte verschieben.

    Danke

    0
  • K

    Hallo

    versuchs dochmal mit

    DatenträgerNr

    statt mit

    Datenträger-Nr

    (oder bei Access glaube ich so: [Datenträger-Nr])

    MfG
    Klaus

    0
  • T

    Stimmt, da war mal was... Das hat mir bisher dort bei so unglückseligen Spaltennamen mit Leerzeichen dazwischen geholfen.
    In diesem Fall hilft das leider nicht. Ich werde wohl mal versuchen herauszufinden, was da SetField vom DAO anders macht als meine bescheidenen SQL-Versuche.

    trotzdem schonmal Danke für Deine Hilfe

    0
  • U

    Ich sehe im ersten SQl-Query 13 Felder aber 15 Values. Das kann nicht gehen.

    0
  • T

    Auch auf die Gefahr hin, das ich falsch liege, aber:

    'Testiger0, Test0' ist doch in dem Fall das Gleiche wie "Testiger0, Test0" und somit nur ein Wert und somit 15 von Dir gezählte minus zwei sind wieder 13 🙂 .Aber die Anmerkung ist schon richtig: Wenn mir DAO da nicht so schicke exceptions um die Ohren pfeffern würde hätte ich das einige male falsch gemacht.

    Wie auch immer: daran scheint es nicht zu liegen, da ER es "frißt". Es klemmt wirklich an diesem einen Feld. Du darfst mir auch glauben, das das INSERT INTO ansonsten auch funktioniert.

    Aber daraus gleich die nächste Frage: ist beides ( ' und " ) erlaubt, um Strings zu kennzeichnen?

    0
  • F

    Ich weiss nicht, wie's bei Access ist, aber generell ist das doppelte Anführungszeichen nicht dasselbe wie ein einfaches.

    Das einfache wird für Zeichenketten verwendet, das doppelte für Datenbank-Objekte.

    Wenn du z.B. eine Spalte mit Leerzeichen anlegen willst, geht das mit doppelten Anführungszeichen:

    create table test (
    "Spalte Mit Leerzeichen" integer
    )

    Ich kann mir zwar vorstellen, das einige Datenbanken dem User hier Freiheiten erlauben, indem sie auch doppelte Anführungszeichen für normale Strings zulassen, verlassen würde ich mich aber nicht darauf.

    Ich hab's gerade mal ausprobiert. DB2 hält sich hier an den Standard und erlaubt es nicht.

    0
  • U

    MySQL erlaubt es auch nicht. Dort ist lediglich erlaub INT in einfachen Hochkommas einzufassen oder ohne Hochkommas.
    String muss immer in einfachen Hochkommas sein.

    0
  • T

    Also ACCESS erlaubt beides. MSDE und SQL-Server (ist ja fast das Gleiche) sowie Borland Intertbase 6.0 auch. Gut zu wissen, das das durchaus einen Unterschied macht.

    Leider bringt mich das meinem Problem nicht wirklich näher. Mittlerweile bin ich sogar bereit diese "Häßlichkeit" im Code zu ertragen, wenn ich mir wenigstens erklären könnte, warum das so ist.

    Als Anmerkung noch: Die Table ist wirklich total simpel, nix verlinkt und dieses Feld ist IMO auch nirgendwo sonst nochmal referenziert.

    0
  • K

    Hallo

    hast du es denn schon mal ohne dem "-" versucht
    (siehe mein Post weiter oben ?)

    MfG
    Klaus

    0
  • U

    Versuche es aml ohne Umlaut.

    0
  • T

    Danke für euer reges interesse:

    1.) ohne Umlaute. Wenn ich Dich richtig verstehe: Ich war mal faul und hab dazu CString benutzt:

    CString strFieldName = "Datenträger-Nr";
strFieldName.OemToAnsi();

    Das Ergebnis war merkwürdigerweise das Gleiche wie vorher.

    2.) ohne Bindestrich findet er das Feld gar nicht "Unbekanntes Feld...."

    @KlausB:

    gebracht hat es das Einschließen in eckige Klammern []. Merkwürdig: ich hatte es in meinem DBTool gestern wirklich auch so versucht, da schien es nicht zu gehen. Wenn du jetzt nicht nochmal nachgehakt hättest hätte ich das jetzt als gesichertes Wissen abgespeichert 🙄
    Ich sollte diesen Fall wohl wirklich als DB-besonderheit bei ACCESS irgendwie gesondert behandeln....

    Vielen Dank @all

    0
Anmelden zum Antworten