Zugriffsverletzung bei ExecSQL

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