Re: Interfacing Oracle and Visual Basic

Charles Newman wrote:

> *** post for free via your newsreader at post.newsfeeds.com ***
>
> Jochen Pege <pege_at_kespretlang.de> wrote in message
> news:8vd8os$ten$1_at_news10.roka.net...
> > Try to use an ADO Conncetion. After you established the connection you can
> > use the normal methods (.addnew,....) or, and this would be the faster way
> > you can you simple SQL Statements.
> >
> >
>
> There is a problem with ADO. You can use multiple tables with one data
> control. If you leave the RecordSource property blank, within the control,
> you will get an an error "No RecordSource Set", if even if your program sets
> the RecordSource property.
> Then I get an error "Cannot bind to Field", where the text and/or label
> items define the data source used, becuase ADO does NOT support multiple
> tables. They only way to use ADO, is to use one data control for each table
> you plan to use.
> Simply put, ADO does NOT support databases with multiple tables,
> PERIOD!!!!
> If anybody out there is going to use ADO, instead of the Oracle Data
> Control, you will have to use a seperate ADO control for each table of your
> database, otherwise, it will not work.
>

Actually, it is just a matter of using ADO properly. While someone may intuitively believe that a particular operation can be performed in a certain way, a bit of research and study of ADO would show why that is not possible. The client applications that I've worked with use multiple tables, views, stored procedures, functions, packages, etc and while I have sometimes had to fiddle around until I came up with the proper methodology to get everything to work right, I generally can figure it out in the end.

What you might want to consider is putting your client application on a diet and use stored procedures to accomplish your tasks. That way all you really have to learn is how to called a stored procedure and pass it parameters. There are actually some very good reasons for doing this from a client-server point of view.

Beyond that, don't dis' ADO just because you can't get it to do what you think it should do. There are thousands of us who are using ADO with VB every day and I'd generally suspect that if it didn't work right the methodology would be dropped like a hot potato. Received on Wed Nov 29 2000 - 11:16:57 CST