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

From: Ludek Finstrle <luf(at)pzkagis(dot)cz>
To: Andrus <eetasoft(at)online(dot)ee>
Cc: pgsql-odbc(at)postgresql(dot)org
Subject: Re: Access violation C5 error on Visual FoxPro SQLEXEC() call after error
Date: 2005-12-14 11:38:53
Message-ID: 20051214113853.GA14199@soptik.pzkagis.cz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-odbc

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

In response to

Responses

Browse pgsql-odbc by date

  From Date Subject
Next Message Andrus 2005-12-14 12:43:54 Re: Access violation C5 error on Visual FoxPro SQLEXEC() call after error
Previous Message Andrus 2005-12-14 10:13:45 Re: Access violation C5 error on Visual FoxPro SQLEXEC() call after error