Skip site navigation (1) Skip section navigation (2)

Re: ODBC SQLSetPos Delete problem

From: "Greg Campbell" <greg(dot)campbell(at)us(dot)michelin(dot)com>
To: Lothar Behrens <lothar(dot)behrens(at)lollisoft(dot)de>
Cc: pgsql-odbc(at)postgresql(dot)org
Subject: Re: ODBC SQLSetPos Delete problem
Date: 2004-09-15 01:00:07
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-odbc
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: -----------------------------
>> Lothar Behrens    | Independent:       lothar(dot)behrens(at)gmx(dot)de
>> Rosmarinstr 3     | My public project:
>> 40235 Düsseldorf  |
>>                  |  -> 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

Attachment: greg.campbell.vcf
Description: text/x-vcard (283 bytes)

In response to

pgsql-odbc by date

Next:From: William ZHANGDate: 2004-09-15 03:33:31
Subject: Re: Connection Failure
Previous:From: Jeff StoutDate: 2004-09-14 19:59:43
Subject: FW: Postgres and Funk Radius

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group