Thread: Re: VBA 6 crashes with WIN2K, Postgres 8.1, why ? whichdll ??
> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org
> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Campbell, Greg
> Sent: 06 January 2006 23:44
> To: linuxgps
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] VBA 6 crashes with WIN2K, Postgres 8.1,
> why ? whichdll ??
>
> 3. Again this is a personal preference, but I always use
> connection.Execute for INSERTS,UPDATE, and
> DELETES. Your example used on AddNew and one cnn.Execute.
>
> 4. I find a object referencing style and stick with it.
> rs.Fields("fieldname") and rs!fieldname are both a
> little dated. rs("fieldname"), or
> rs(variable_holding_field_name) or rs(integer_field_ndx) seem to be
> cultural standards now.
The example is from the psqlODBC VB HOWTO which goes out of it's way to
show the different ways to use ADO with PostgreSQL. Your suggestions are
correct of course, but there is good reason why that code looks as it
does.
> Oh, and PostgreSQL via ODBC,...
> it has never been strong on the updateable cursor/dynamic
> cursor thing.
Don't mix the two up, they are separate things. Dynamic recordsets
(adOpenDynamic) have worked well since at least 1997 when I first wrote
pgAdmin I in VB5, long before Hiroshi added the Updateable Cursors
option to the driver (back when Byron maintained it in fact). They still
do work well with the current versions of the driver (at least, none of
my users of 4 of 5 different VB apps complained when they got upgraded).
The Updateable Cursor option is an experimental implementation of
emulated updateable server-side cursors (which PostgreSQL doesn't
natively support) iirc.
Regards, Dave.
You can help me understand the utility of the adOpenDynamic. Both adOpenStatic, and adOpenDynamic allow
moving through the recordset in multiple directions. With adOpenDynamic, other users changes are visible
in your recordset, as opposed to the static which is more of a snapshot.
Then there is the CursorLocation parameter (client-side or server-side).
How does it work to use adOpenDynamic (for viability of updates from others), if the cursor is not
server-side? If server-side cursor is the only way of getting the added value of adOpenDynamic, doesn't
that mean an updateable cursor?
Here's another angle of attack to help my understanding.
adOpenDynamic shows changes made by others.
Updateable cursors allow me to make changes along an open cursor back to the database.
Are you saying the simple adOpenDynamic configuration is allowing changes to to get to me, along a
communication channel without my ability to make changes back along that channel?
Dave Page wrote:
>
>
>
>>-----Original Message-----
>>From: pgsql-odbc-owner@postgresql.org
>>[mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Campbell, Greg
>>Sent: 06 January 2006 23:44
>>To: linuxgps
>>Cc: pgsql-odbc@postgresql.org
>>Subject: Re: [ODBC] VBA 6 crashes with WIN2K, Postgres 8.1,
>>why ? whichdll ??
>>
>>3. Again this is a personal preference, but I always use
>>connection.Execute for INSERTS,UPDATE, and
>>DELETES. Your example used on AddNew and one cnn.Execute.
>>
>>4. I find a object referencing style and stick with it.
>>rs.Fields("fieldname") and rs!fieldname are both a
>>little dated. rs("fieldname"), or
>>rs(variable_holding_field_name) or rs(integer_field_ndx) seem to be
>>cultural standards now.
>
>
> The example is from the psqlODBC VB HOWTO which goes out of it's way to
> show the different ways to use ADO with PostgreSQL. Your suggestions are
> correct of course, but there is good reason why that code looks as it
> does.
>
>
>>Oh, and PostgreSQL via ODBC,...
>>it has never been strong on the updateable cursor/dynamic
>>cursor thing.
>
>
> Don't mix the two up, they are separate things. Dynamic recordsets
> (adOpenDynamic) have worked well since at least 1997 when I first wrote
> pgAdmin I in VB5, long before Hiroshi added the Updateable Cursors
> option to the driver (back when Byron maintained it in fact). They still
> do work well with the current versions of the driver (at least, none of
> my users of 4 of 5 different VB apps complained when they got upgraded).
> The Updateable Cursor option is an experimental implementation of
> emulated updateable server-side cursors (which PostgreSQL doesn't
> natively support) iirc.
>
> Regards, Dave.
Attachment
On 7/1/06 01:25, "Campbell, Greg" <greg.campbell@us.michelin.com> wrote: > You can help me understand the utility of the adOpenDynamic. Both > adOpenStatic, and adOpenDynamic allow > moving through the recordset in multiple directions. With adOpenDynamic, other > users changes are visible > in your recordset, as opposed to the static which is more of a snapshot. > > Then there is the CursorLocation parameter (client-side or server-side). > > How does it work to use adOpenDynamic (for viability of updates from others), > if the cursor is not > server-side? If server-side cursor is the only way of getting the added value > of adOpenDynamic, doesn't > that mean an updateable cursor? > Bad post-midnight phrasing on my part I'm afraid :-(. AdOpenDynamic works in the sense that it will not crash. It will be essentially the same as adOpenStatic though as it won't see other user's changes. AdOpenDynamic might be made to do so with real updateable server side cursors created WITH HOLD I guess. Regards, Dave
Thanks Dave. That completely agrees with my experience. In effect adOpenDynamic currently acts the same as adOpenStatic. My anal retentitive side much prefers seeing adOpenStatic, because the results agree with my expectations when I see that. And on the post midnight thing, I lost track of the time difference and at the time remember thinking, "Why is this guy doing postgres odbc postings in the middle of the season premier of Galactica?". Dave Page wrote: > > > On 7/1/06 01:25, "Campbell, Greg" <greg.campbell@us.michelin.com> wrote: > > >>You can help me understand the utility of the adOpenDynamic. Both >>adOpenStatic, and adOpenDynamic allow >>moving through the recordset in multiple directions. With adOpenDynamic, other >>users changes are visible >>in your recordset, as opposed to the static which is more of a snapshot. >> >>Then there is the CursorLocation parameter (client-side or server-side). >> >>How does it work to use adOpenDynamic (for viability of updates from others), >>if the cursor is not >>server-side? If server-side cursor is the only way of getting the added value >>of adOpenDynamic, doesn't >>that mean an updateable cursor? >> > > > Bad post-midnight phrasing on my part I'm afraid :-(. AdOpenDynamic works in > the sense that it will not crash. It will be essentially the same as > adOpenStatic though as it won't see other user's changes. AdOpenDynamic > might be made to do so with real updateable server side cursors created WITH > HOLD I guess. > > Regards, Dave > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq