Re: ODBC SQLSetPos Delete problem

I forgot to mention what may or may not be obvious. A connected
recordset is more technically known as a server side cursor. A
disconnect recordset is more correctly known as a client side cursor.
The client side cursor brings all the records back to the client and
establishes a pointer to them. The server side cursor is like an open
pointer to a set of records on the server. So not all cursors are equal.

Some applications use server side cursors -- probably poorly supported
by PostgreSQL. Some applications use client-side cursors with updates
not done in against a remote pointer,... but done on with behind the
scene SQL statement against rows.

So checking for row versioning on the driver set-up can be important.

Perhaps you could remind us -- what platform is the application on? What
driver are you using to make the connection? What is the server platform?

Greg Campbell wrote:

> I think you and we need details.
> You say the form uses cursors. This suggest to me that maybe you are
> trying to update a connected recordset, versus using a disconnected
> recordset. I hope this is not talking down to anyone, but a
> disconnected recordset is one where you get the records, then the
> server can forget about you. A connected recordset is keeping the
> connection alive until you are done with your recordset, that is close
> your form.
>
> I have always avoided connected recordsets for client-server
> applications. I use disconnected recordset when I want to read data. I
> use INSERT, UPDATE, AND DELETE statements (against primary keys and
> indexes) when I wish to modify data.
>
> My understanding is not perfectly clear on this, but I think that the
> PostgreSQL driver does not do connected recordsets. But the ODBC
> driver may fake it under certain conditions.
> It is suggested that there be OIDS on the server table.
> It is suggested that the server table have a primary key.
> It is suggested that row versioning be turned on in the ODBC driver.
> There are conditions where table row uniqueness is forced by the
> adding of a timestamp field that defaults to Now().
> So while it may appear to a user that a database table is attached,...
> the behind the scenes is a sequence of row fetches, and discrete
> insert, update, delete statements that need to find the records to
> work on.
>
>
> To this end, and back to those details
>
> Does your table have OIDS?
> Does your table have a primary key?
> Have you turned on all the logging you can, client and server to see
> what is going on at lower levels?
> Are there options in your application wizard regarding connections? (I
> doubt we can help you with)
> Could you build the application in a different way to separate data
> reading transaction from data updating transactions?
>
> I hope that
> 1. I am not completely off the mark
> 2. that I have given you something to think about that you did not
> already have.
>
> Good Luck.
>
> Lothar Behrens wrote:
>
>> Hi,
>>
>> it seems that I did not get any help. Now I also like to say, that
>> If I test a Sybase Power++ Developer application with simple db form,
>> I get a crash in the Postgres ODBC driver.
>>
>> The form is created with the wizard and uses cursors.
>>
>> The driver seems to delete the record, but moving to next/prev record
>> fails.
>>
>> Who can help me ?
>>
>> Do you like to have the source ?
>> You can dounload it.
>>
>> I can try to debug the ODBC library, but I do not understand the full
>> source, so I need a little help.
>>
>> Thanks
>>
>> Lothar
>> ---- My home: www.lollisoft.de -----------------------------
>> Lothar Behrens | Independent: lothar(dot)behrens(at)gmx(dot)de
>> Rosmarinstr 3 | My public project:
>> 40235 Düsseldorf | http://sourceforge.net/projects/lbdmf
>> | -> Need comments, please visit :-)
>>
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 8: explain analyze is your friend
>>
>>
>---------------------------(end of broadcast)---------------------------
>TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>
>