Re: basic questions with odbc and visual basic.

Ahh, I see now.
Well for reports, which are pretty much read-only as far as data
concerned you have lots of freedom.

For manipulating the data -- Access works pretty good as long as Access
can know which record(s) to update (primary keys or OIDs -- that sort of
thing).


Merlin Moncure wrote:

>>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.
>>
>>
>
>Right.  I agree 100%...I think RAD tools make great screen designers and
>get you into trouble if you take them beyond that.  In fact, I would
>never even be looking at VB except I have to train a couple of VB
>jockeys from another company on how to access our system so they can
>make simple forms and run reports.
>
>My initial thought was to build views on the server encapsulating the
>more complex aspects of the database design for the vb guys to read and
>write from.  I had hoped that it would be relatively easy to bind these
>views to various Microsoft stuff...and it is, but in a slightly more
>code intensive way than I had expected.  I may try giving the ole db
>driver a shot and see if it provides better results.
>
>Merlin
>
>
>
>
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 9: the planner will ignore your desire to choose an index scan if your
>      joining column's datatypes do not match
>
>