Re: Updates on updates

You say
"It seems that much more important to the client than being able to
update from the result set is the ability to get most up to date queries
for each fetch."

Specify "fetch".
Is it the returning of one or more records at a time of a cursor?
Or is it, the returning of the entire recordset?

Also what client environment are in (VB6, Access with DAO, RDO, ADO, Delphi, C++...)(It can effect how I
understand you to be using the term Dynaset)?

Classically I think of a cursor as a pointer to the recordset I want. I open it and do FETCHes using it,
then close it. Then your underlying question is will you see changes made by other users while you have
this cursor open. The return question is why is your cursor open so long?

More casually one might speak of fetching a set of records. This is nowhere near as specific as the FETCH
mentioned previously. If perhaps you have a grid in an user application, and the client wants the data to
be "fresh". The underlying question is do you have to run the query again, repeatedly? Or is the question,
if you run the query again, will you get the "most up to date" information?

Are you treating you application like a local Access database, where you can use a bound form to attach to
a table of data, and keep it open and automatically refreshing as long as you like? Or are you treating
your application like a client and server application, where you expect to send requests, and get the data
in the most expeditions manner possible, keeping transactions short and atomic, almost treating the data
transfer as a highly expensive proposition? Perhaps I am out of date on my view of application design.
When is the issue ODBC driver capability, and when is it application design?

Shachar Shemesh wrote:
> Hi list,
>
>
> I had a meeting with my client (the one who wanted update support), and
> here are the conclusions: It's a long way ahead.
>
>
> It seems that much more important to the client than being able to
> update from the result set is the ability to get most up to date queries
> for each fetch. This is a requirement of a "dynaset" view
> (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_Dynaset.asp).
> Unfortunately, PostgreSQL does not support cursors that are not of type
> "sensitive". Even if it did, it does not support cursors that do not
> live inside a transaction. It follows, then, that there is no choice for
> an ODBC that wishes to implement a dynaset record but to perform a new
> query for each and every fetch operation.
>
>
> Things are slightly worse, in fact. Because the ordering of the records
> in a dynaset are guarenteed to remain the same as when they were first
> fetched, some way of determining whether a specific row has changed (or
> was deleted) is required. It is at this point that I have to appologize
> to Hiroshi if any tone of dismissivness could have been understood from
> my previous email regarding his implementation. Making a dynaset work
> without using oids is going to be damn tough.
>
>
> There is one glimmer of hope. The link I gave above claims that we are
> allowed to keep, in essence, local copy of the data from the dataset
> until a "requery" is done. This means that implementing a dynaset
> without huge performance losses is going to be possible (though not easy).
>
>
> This email is mostly so I can update everyone on the current status. I
> have not, yet, formed a concerete plan on what my personal actions on
> this matter are going to be. I mostly interested to see whether an
> interesting discussion forms as a result of these new discoveries.
>
>
> Shachar
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq