Diesing, Burkhard schrieb:
Hello Michael,
fine that you have found a workaround. But splitting the nested sql
should be not the normal behavior to solve problems.
Which database and ODBC version did you use?
I use MaxDB 7.5.26 (odbc driver 7.5.18), database in ascii.
Best wishes
Michael
Regards,
Burkhard
------------------------------------------------------------------------
From: Michael P. [mailto:[EMAIL PROTECTED]
Sent: Freitag, 15. Juli 2005 17:56
To: Diesing, Burkhard
Cc: List
Subject: Re: update long + nested Sql Cmd => -8: Execution failed,
parse again
Hi Burkhard,
thanks for your answer. I tried to call 'Prepare' several times
but the error didn't vanish. I implemented it in a way that I called
Me.oCommandM.Prepare()
Me.oCommandM.ExecuteNonQuery()
again and again (surrounded by Try-Catch-EndTry and a loop) with
the hope that the error message may disappear after a few
iterations, however it remained the same (The max. number of
trials was set to 10).
I solved the problem by splitting the nested sql cmd into two
separate sql cmds.
Best wishes
Michael
Diesing, Burkhard schrieb:
Hi Michael,
The documentation reads: for applications which are based on ODBC and
apply the PREPARE-command the developer is responsible for the
number of
parse/EXECUTE orders.
What does this mean? How can I fix the problem?
It means that the application has to prepare/parse the command again.
You can try it with a call to
e.oCommandM.Prepare()
If this doesn't help please post a zipped ODBC trace. To produce the
trace have a look to
http://sapdb.2scale.net/moin.cgi/ODBCTrace
Regards,
Burkhard
-----Original Message-----
From: Michael P. [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 13. Juli 2005 04:24
To: List
Subject: update long + nested Sql Cmd => -8: Execution failed,
parse again
Hi group,
The command
UPDATE table1 SET field0 = '332211', longfield1 = ?, longfield2 = ?
WHERE id = (SELECT id_inTable1 FROM table2 WHERE id = 7117)
created the error '-8: Execution failed, parse again'. The fields
'longfield1' and 'longfield2' of type long and have been specified in
the parameters of the command beforehand and have also been
'prepared'
(Deteils see below in the vb.net code). The fields 'longfield1' and
'longfield2' do only contain short strings such as 'hello maxdb' and
'this and that'. :-)
The error does neither occur in sql-commands where I use
"WHERE id = 17"
instead of "WHERE id = (SELECT ...)" nor when I don't have to handle
fields of type long.
The documentation reads: for applications which are based on ODBC and
apply the PREPARE-command the developer is responsible for the
number of
parse/EXECUTE orders.
What does this mean? How can I fix the problem?
Best wishes and thanx for help
Michael
The vb.net code:
Dim nameOfFieldLongL As String
Dim valueOfFieldLongL As String
Dim iFieldL As Integer
Dim nFieldsL As Integer
nFieldsL = arrlistFieldsOfTypeLong_fieldNamesA.Count
If Me.oCommandM.Parameters Is Nothing Then
Me.oCommandM.CreateParameter()
End If
For iFieldL = 0 To nFieldsL - 1
nameOfFieldLongL =
arrlistFieldsOfTypeLong_fieldNamesA(iFieldL)
valueOfFieldLongL =
arrlistFieldsOfTypeLong_fieldValuesA(iFieldL)
valueOfFieldLongL = valueOfFieldLongL.Trim
Me.oCommandM.Parameters.Add( _
"@" & nameOfFieldLongL, _
Odbc.OdbcType.NText).Value = valueOfFieldLongL
Next
Me.oCommandM.CommandText = sqlCommandA
Me.oCommandM.Prepare()
Me.oCommandM.ExecuteNonQuery() ' this line lead to '-8:
Execution failed, parse again'
