Re: ADO Server Cursors and OID - Mailing list pgsql-odbc
From | Andrew Ayers |
---|---|
Subject | Re: ADO Server Cursors and OID |
Date | |
Msg-id | 3F623294.4040403@eldocomp.com Whole thread Raw |
In response to | ADO Server Cursors and OID ("Greg Campbell" <greg.campbell@us.michelin.com>) |
List | pgsql-odbc |
Greg Campbell wrote: > I have created a table with a serial ID (sequenced) key_id field which > is also the PRIMARY KEY using pgAdmin. I've looked at the create table > statement. It has a WITHOUT OIDS clause. Table works fine, but I seem to > be unable to make ADO server side cursors. (VB). > > Is there a key to enabling server side cursors. > I can link the table in Access and browse it and change field values. It > gives the impression of server side cursor, although I do not know if > that is what it is really doing. The DAO engine->pgODBC may be (must be) > behaving differently than my ADO code->pgODBC. > > I know I can work around with client side cursors for selects, and use > INSERT,UPDATE executable queries. But with inserts/updates that have > many fields or needing to escape (/') text fields that might contain > quotes, the coding can get a little hairy compared to updating a cursor > field. I can't tell you what the problem is you are running into. I have never used the "WITHOUT OIDS" clause, as a PG user, I am very newbie to all of it, there is a lot about PG I still need to learn. As far as DAO vs. ADO - yes, they operate *very* differently in regards to pgODBC - one thing I found that forced me to go to ADO was that in DAO you couldn't "double update" a TEXT field type (analogous to Memo fields), like you can in DAO: .AddNew ![field1] = "this" ![field1] = "that" .update The second setting of the field would cause the program to fall over. ADO didn't have this problem. If I could do it all over again (I couldn't modify my app to be this way when I was converting it from Access to PG - when I mean doing it over, I mean from the very beginnning), I would have the backend do all the work, and only "interface" via SQL, and completely avoid "cursor fields", as you put them. While the coding would be difficult, I think I could probably come up with a reusable function library to make things fairly easy, so that something similar to the cursor fields could be done, but the function library (or class set, or whatever) would do the translation from what I want to the SQL to perform the actions. I hope someone else is able to diagnose your issue, and that they post here so I can learn something as well. Andrew Ayers Phoenix, Arizona -- CONFIDENTIALITY NOTICE -- This message is intended for the sole use of the individual and entity to whom it is addressed, and may contain informationthat is privileged, confidential and exempt from disclosure under applicable law. If you are not the intendedaddressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy,disclose or distribute to anyone the message or any information contained in the message. If you have received thismessage in error, please immediately advise the sender by reply email, and delete the message. Thank you.
pgsql-odbc by date: