Re: ODBC SQLSetPos Delete problem
От | Greg Campbell |
---|---|
Тема | Re: ODBC SQLSetPos Delete problem |
Дата | |
Msg-id | 41479417.2080601@us.michelin.com обсуждение исходный текст |
Ответ на | Re: ODBC SQLSetPos Delete problem ("Greg Campbell" <greg.campbell@us.michelin.com>) |
Список | 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: www.lollisoft.de ----------------------------- >> Lothar Behrens | Independent: lothar.behrens@gmx.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@postgresql.org so that your > message can get through to the mailing list cleanly > >
Вложения
В списке pgsql-odbc по дате отправления: