Zugriffsverletzung bei ExecSQL

[Voltzi]

Hi Leute!

Habe folgendes Problem. Ich möchte einen Update- Befehl mit ExecSQL ausführen. Dabei bekomme ich folgende Fehlermeldung:

Im Projekt Name.exe ist eine Exception der Klasse EAccessViolation aufgetreten. Meldung: 'Zugriffsverletzung bei Adresse 1F487CAB in Modul 'msado15.dll'. Schreiben von Adresse 01011008'. Prozess wurde angehalten...

Der SQL-Befehl sieht folgendermaßen aus:

DelphiCode:

Delphi-Quellcode:

SQL.Add('UPDATE buch SET titel = '''+EdtTitel.Text+''',isbn = '''+EdtISBN.Text+''',key_verlag = '''+IntToStr(key_verlag)+''',auflage = '''+EdtAuflage.Text+''',kaufpreis = '''+EdtPreis.Text+''',kurze_beschreibung = '''+MemoBeschreibung.Text+''',anzahl = '''+EdtAnzahl.Text+''','key_genre = '''+IntToStr(key_genre)+''',key_unterkategorie = '''+IntToStr(key_unterkat)+''',cover = '''+EdtCover.Text+''',aktiv = '''+IntToStr(oeffentlich)+''' WHERE id = '''+IntToStr(idbuch)+'''');

SQL-Code

SQL-Code:

UPDATE buch SET titel = 'IT-Handbuch',isbn = '34-5462-57247-2',key_verlag = '3',
auflage = '4',kaufpreis = '25,00',kurze_beschreibung = 'Inhalt über die gesamte IT-Bildung',anzahl = '3',key_genre = '2',key_unterkategorie = '3',cover = 'C:/Dokumente und Einstellungen/Administrator/Eigene Dateien/Eigene Bilder/Beispiel.jpg',
aktiv = '1' WHERE id = '1'

Der Fehler tritt auf, seitdem ich den Pfad zu Cover hinzufüge.
Kann mir jemand helfen?

Danke im voraus

MfG
Voltzi

[CasaN]

hi,
wie gross (zeichenlänge) ist das feld cover?

[Voltzi]

das Feld ist 100 Zeichen groß.

[CasaN]

und was passiert wenn du "per hand" diese sql ausführst?

[Bernhard Geyer]

1, Schon die richtigen Häckchen in der ODBC-Konfiguration gemacht?
2, Stell dein Programm auf parametrisierte Anweisungen um. Es könnte sonst sein das sich irgendein Treiberteil z.B. an Slashes verschluckt (z.B. müssen Backslashes bei MySQL escapet werden).

[Voltzi]

Ich nutze als DB-Oberfläche MySQL-Front. Da funktioniert der SQL-String.

[Voltzi]

Ich habe das ganze mal auf einem anderen System getestet. da funktioniert es.

[Bernhard Geyer]

Zitat:

Zitat von Voltzi

Ich habe das ganze mal auf einem anderen System getestet. da funktioniert es.

Haben beide PC's die gleichen Versionen? MyODBC, ADO, ...? Wenn nein - abgleichen!

[Voltzi]

Beide PC's haben die selben Versionen. Ich habe mal ein neues kleines Programm geschrieben, in dem ich die selbe SQL- Anweisung mit "ExecSQL" ausführe. In diesem Fall hat es funktioniert.
Ist es vielleicht möglich, dass Delphi irgendwelchen Quellcode in meinen Programm- Dateien geschrieben hat, so dass ich "ExecSQL"- Anweisungen auf dem System nicht mehr ausführen kann?

MfG
Voltzi

[marabu]

Hallo Voltzi,

versuche es doch mal so:

Delphi-Quellcode:

SQL.Text := 'UPDATE buch SET titel = :titel, isbn = :isbn, key_verlag = :key_verlag, auflage = :auflage, kaufpreis = :kaufpreis, kurze_beschreibung = :kurze_beschreibung, anzahl = :anzahl, key_genre = :key_genre, key_unterkategorie = :key_unterkategorie, cover = :cover, aktiv = :aktiv WHERE id = :id';

Parameters.ParamByName('titel').AsString := edtTitel.Text;
...
Parameters.ParamByName('id').AsInteger := idBuch;

Grüße vom marabu

[Voltzi]

@marabu

Danke für die Idee. Nur leider funktioniert es nicht.

Delphi-Quellcode:

Parameters.ParamByName('titel').AsString := edtTitel.Text;

Statt dem "AsString" musste ich "Value" nehmen, da Delphi es nicht kannte.

Delphi gibt aber dann folgende Fehlermeldung:
"Die Argumente sind vom falschen Typ, liegen außerhalb des Gültigkeitsbereiches oder sind miteinander unvermeidbar."

Diese Meldung erscheint, wenn man beim Ausführen bei der SQL- Anweisung angelangt ist.

MfG
Voltzi

[marabu]

Sorry für AsString - hast dir ja zu helfen gewusst.

Habe bei mir versucht deinen Fehler nachzustellen. MySQL 4.1.10, MyODBC 3.51.11
Was soll ich sagen, ich bekomme deinen Pfadnamen problemlos per ExecSQL und UPDATE in meine Tabelle.
Klappt es denn bei dir, wenn du die Zuweisung an cover wieder entfernst?
Kannst du die Metadaten deiner Tabelle posten, damit ich deine Tabelle bei mir erzeugen kann?
Deine aktuelle Fehlermeldung deutet ja darauf hin, dass irgendein Feld nicht den richtigen Typ hat. Vielleicht, weil es vom ODBC Treiber nicht unterstützt wird?
Welche Version setzt du ein? Wie hast du den Treiber konfiguriert?

marabu

[Voltzi]

Es ist ja nicht so, dass ich nur dieses Anweisung nicht ausführen kann. Ich kann alle SQL-Anweisungen in meinem Programm mit ExecSQL nicht ausführen.

Es ist aber nur auf diesem System so. Auf anderen Systemen funktioniert die Anweisung ja.

Ich hatte zum Test auf diesem System ein kleines Programm erstellt, welches genau diese SQL-Anweisung mit ExecSQL ausführt. Da hat es ja funktioniert. Es muss an irgendwas anderes liegen, als an der Anweisung, der Datenbank oder den ganzen Versionen.

MfG
Voltzi

[alzaimar]

ADO zickt manchmal so richtig rum. Aber nur in der Delphi-IDE, wenn man 'Stop at Delphi exception' einschaltet. Klappt es bei Dir, wenn Du die EXE standalone aufrufst?

Nebenbei:

Delphi-Quellcode:

Query.Parameters.ParamValues['myParam'] := AnyVariantValue;

Verzichtet auf 'Value','AsString' oder sonstewas.

Dann: MSSQL und ADO wollen keine WideStrings, oder nur mittels Androhung von Prügel oder verschärftem "FORMAT C:". bzw. rumtrickserei im OnWillExecute Event der ADOConnection.
Dann: Ist die MDAC-Version wichtig (alles > 2.6 ist akzeptabel). Die 2.6er spinnt 'sporadisch' auf einigen Systemen.

[Voltzi]

Ich habe es auch standalone aufgerufen. Es funktioniert trotzdem nicht. Kann es vielleicht sein, dass es an Windows liegt? Das die msado15.dll eine Windows-Datei ist?

MfG
Voltzi

[Bernhard Geyer]

Zitat:

Zitat von alzaimar

ADO zickt manchmal so richtig rum. Aber nur in der Delphi-IDE, wenn man 'Stop at Delphi exception' einschaltet. Klappt es bei Dir, wenn Du die EXE standalone aufrufst?

Nebenbei:

Delphi-Quellcode:

Query.Parameters.ParamValues['myParam'] := AnyVariantValue;

Verzichtet auf 'Value','AsString' oder sonstewas.

Dann: MSSQL und ADO wollen keine WideStrings, oder nur mittels Androhung von Prügel oder verschärftem "FORMAT C:". bzw. rumtrickserei im OnWillExecute Event der ADOConnection.

Kann ich so nicht stehen lassen :warn:
MSSQL und ADO können sehr wohl sehr gut mit WideStrings umgehen. Was hier Probleme bereitet ist der ADOExpresss-Wrapper bzw. teilweise die Automatische String<->Widestring-Wandlung von Delphi. Ich mußte z.B. an 2 Stellen bei D6 in der ADODB.Pas-Unit anpassungen vornehmen damit es halbwegs funktionierte.

Zitat:

Zitat von alzaimar

Dann: Ist die MDAC-Version wichtig (alles > 2.6 ist akzeptabel). Die 2.6er spinnt 'sporadisch' auf einigen Systemen.

Das typische DLL-Höllen-Problem. Wobei vermute ich hier nicht das die ADO-DLL's direkt fehlerhaft sind sondern eher benötigte DLL's und die Versionen nicht kompatible sind. Einfach mal 'ne neue MDAC-Installation drüberbügeln.

[Voltzi]

Ich habe jetzt eine neue MDAC- Version installiert. Jetzt funktioniert es auch wieder.

@all
Ich bedanke mich für eure große Hilfsbereitschaft.

MfG
Voltzi

[alzaimar]

msado15.dll ist die ADO (MDAC) Komponente....

Saug Dir doch einfach mal die MDAC 2-8 von MS und bügel das drüber. Vielleicht hat die msado15.dll ja eine Macke bekommen.

@Bernhard: Mach mal eine Stored procedure mit einem NVarChar Parameter und versuche dann, einen Wert zu übergeben. Klappt, nur ignoriert er das NVARCHAR. Imho liegt das an ADO. Ich krieg das jedenfalls nicht mit rumpatchen im ADODB.PAS weg (nur mit OnWillExecute). Die bekannten Problemchen mit ADO und Delphi, bzw. die patches meinte ich auch nicht, obwohl die für sich auch schon ausreichen.
Die ADO 2.6 hat eine bestehende Connection aus Versehen wieder freigegeben und es nicht bemerkt, beim nächsten Zugriff kamm dan ein katastrophaler Fehler. MS hats zugegeben und gleich empfohlen, diese Versionen nicht zu nehmen. Leider ist die MDAC 2.6 auf der SQL-2000 CD drauf (Microsoft Dokumente #810008 und #314635).

@voltzi: Hurra!!!!!

[Bernhard Geyer]

Zitat:

Zitat von alzaimar

@Bernhard: Mach mal eine Stored procedure mit einem NVarChar Parameter und versuche dann, einen Wert zu übergeben. Klappt, nur ignoriert er das NVARCHAR. Imho liegt das an ADO. Ich krieg das jedenfalls nicht mit rumpatchen im ADODB.PAS weg (nur mit OnWillExecute). Die bekannten Problemchen mit ADO und Delphi, bzw. die patches meinte ich auch nicht, obwohl die für sich auch schon ausreichen.

OK. Bei SP's hab ich keine Ahnungen bezüglich Bugs. Hab akutell eine System an laufen welches Aufgrund von DB-Unabhängigkeit auf SP's verzichten muss.

Zitat:

Zitat von alzaimar

Die ADO 2.6 hat eine bestehende Connection aus Versehen wieder freigegeben und es nicht bemerkt, beim nächsten Zugriff kamm dan ein katastrophaler Fehler. MS hats zugegeben und gleich empfohlen, diese Versionen nicht zu nehmen. Leider ist die MDAC 2.6 auf der SQL-2000 CD drauf (Microsoft Dokumente #810008 und #314635).

OK. Gut zu wissen das es da Probleme geben kann.