Re: Access violation C5 error on Visual FoxPro SQLEXEC() call after error

> > I think bind parameters can't be destroyed in SQLCancel.
> >
> > I attach patch which may solve Andrus's problem and change a little
> > Dave's patch. I see application may call FreeStmt(SQL_CLOSE) and
> > FreeStmt(SQL_RESET_PARAMS). But VFP doesn't call it.
>
> Ludek, thank you.

Does it work ok? I'm sorry but I was unable to reproduce it here.

> It's very sad that Visual FoxPro cannot be used with Postgres ODBC driver
> release versions.

Don't worry. I'm planning release VFP version with each release version
and development snapshot til we add support for it to the code.

> I havent seen this problem with MySQL, Oracle and Microsoft SQL ODBC
> drivers.
> So it seems that those drivers do not follow ODBC driver specifications?
> As you wrote it may be possible to study MySQL ODBC driver source code.

I took a look at it. It unset (not free) all parameters in
FreeStmt(SQL_CLOSE). But I'm not sure if it is the way we want.
There is only this about it:
| SQL_ CLOSE: Closes the cursor associated with StatementHandle
| (if one was defined) and discards all pending results. The application
| can reopen this cursor later by executing a SELECT statement again
| with the same or different parameter values. If no cursor is open,
| this option has no effect for the application. SQLCloseCursor can also
| be called to close a cursor.
And this is for SQLCancel:
| In ODBC 2.x, if an application calls SQLCancel when no processing
| is being done on the statement, SQLCancel has the same effect as
| SQLFreeStmt with the SQL_CLOSE option; this behavior is defined only
| for completeness and applications should call SQLFreeStmt or
| SQLCloseCursor to close cursors.
I see no freeing parameters at all. It is even for ODBC 2.x.
We don't need rebind parameters now in some cases and I think it is
good behaviour. I vote to include this only as soon as we create new
option for it.

But Dave could have another opinion from mine ...

I create test suite for this problem. If I have time I run it againist
another DB. But in this case I have less time for psqlodbc development.

Regards,

Luf