Re: basic questions with odbc and visual basic.

I too almost never use data-aware controls. I use ADO to get the data. I
use code to populate a grid.
When a chnange event is fired, I use code to update the row in question.
Why all the work?

Data aware controls tend to be heavy -- they don't know how users are
going to use them -- so the code in them is not lean or application
specific. They do code "under the covers" for lowest common denominator
in an MS presumed world. So if you are not using Access or SQLServer--
they tend to act funny -- in fact I found they act funny when you use MS
products. Some people use them with great success -- more RAD power to
them. I am old school and follow the axioms of transaction between
client and server being resource expensive. I tend to code to get just
the fields and records I need -- and update just the records I want. I
try not to hold open a whole multi-row recordset, because I want to
update 1 row.

With luck someone else on the mailing list has advice for optimizing
with data-aware controls.

Merlin Moncure wrote:

>>I have done a fair amount with VB and PostgreSQL ODBC and I am
>>
>>
>perplexed
>
>
>>by what you have described as your problem. You make it sound as it VB
>>is "making up" the SQL statements to send.
>>
>>
>[...]
>
>
>>Did you leave out some information, like you are using a bound data
>>control perhaps?
>>
>>
>
>Yes, problem is with data-aware controls. The query ado generates to
>write the data back to the server from the recordset checks every single
>field in the table to find the column which fails.
>
>For example (skipping connection, etc.),
>rs.Fields("soeme_field") = "set"
>rs.Update
>
>will 1: generate a query which will fail to update the proper record
>(confirmed by logging the query and trying in psql) and 2: generate an
>exception in vb which reads:
>
>multiple step old db operation generated errors...
>
>Merlin
>
>---------------------------(end of broadcast)---------------------------
>TIP 4: Don't 'kill -9' the postmaster
>
>