Access VB6 Integration

[Mike Dwyer]

I need a VB 6 app to automate a microsoft access MDB application.
Specifically, it needs to open a form in Access and read information
keyed into that form. I know this is "old school" but I'm thinking
about something like we used to do using DDE.

Any ideas would be great

[MacDermott]

If you want to open a form, have the user key in information, and return
that information to VB6 app, why not use a VB6 form?

If you want to read data out of an MS Access table, why automate Access,
when you can just use ADO to read the table?

- Turtle

"Mike Dwyer" <bd*****@hotmai l.com> wrote in message
news:fc******** *************** ***@posting.goo gle.com...

I need a VB 6 app to automate a microsoft access MDB application.
Specifically, it needs to open a form in Access and read information
keyed into that form. I know this is "old school" but I'm thinking
about something like we used to do using DDE.

Any ideas would be great

[Larry Linson]

"MacDermott " wrote

If you want to read data out of an
MS Access table, why automate Access,
when you can just use ADO to read
the table?

Although you'd never know it from the Microsoft hype, you can just as easily
use DAO from VB6 to read the Access table.

The amazing thing to me is, given development schedules, when they were
pumping up the VB community about "classic ADO", they already knew that it
was to be succeeded by ADO.NET which is built on a different object model,
yet they still promoted it as "the access method of choice for the
foreseeable future" (just as they had promoted a number of other access
methods about which you no longer hear even a whisper from Redmond).

I can't remotely imagine a _need_ to open an Access form from VB in order to
read data keyed in to the form. It'd be less trouble, if it truly is data
keyed in by the user in real-time, to create a VB form for it.

Larry Linson
Microsoft Access MVP

[Brendan Reynolds]

As others have indicated, Mike, it is difficult to think of a scenario in
which this would be the best approach. If the Access form is a bound form,
then you can read the data from the table to which the form is bound. If the
Access form is unbound, it would be just as easy to re-create the form in
VB.

If you do decide to go the automation route, I doubt that DDE would be the
best route. I certainly couldn't help you with DDE, and I suspect that there
would be few people today who could - people with recent DDE experience are
pretty thin on the ground these days! :-) You can easily automate Access
either by setting a reference in your VB project to the Microsoft Access
Object Library or by using late binding (GetObject()). Once you've done
that, you have access (no pun intended) to the Access object model, much the
same as if you were writing VBA code in Access itself.

--
Brendan Reynolds

"Mike Dwyer" <bd*****@hotmai l.com> wrote in message
news:fc******** *************** ***@posting.goo gle.com...

I need a VB 6 app to automate a microsoft access MDB application.
Specifically, it needs to open a form in Access and read information
keyed into that form. I know this is "old school" but I'm thinking
about something like we used to do using DDE.

Any ideas would be great

[Mike Dwyer]

Sorry guys, I'll expand on this...

Our customer has an Enterprise-wide application written in VB6. We
want to introduce (sell them) our own suite of tools which happen to
be written in VBA/Microsoft Access. The points of interface between
our apps are few but exist, nonetheless. Our customer will need to
invoke forms that do things in our MDB application and be able to
return the results they produce. Reading data tables alone will not
cut it. Their application will need to fire up a few forms as well.

There is considerable business logic in each of our respective
applications. Neither of us are going to rewrite our products just to
make this work. However, we need to tie them together somehow.
Because there are only a few interface points we felt that Access as
an automation server might just work.

"MacDermott " <ma********@nos pam.com> wrote in message news:<TH******* *********@newsr ead1.news.atl.e arthlink.net>.. .

If you want to open a form, have the user key in information, and return
that information to VB6 app, why not use a VB6 form?

If you want to read data out of an MS Access table, why automate Access,
when you can just use ADO to read the table?

- Turtle

"Mike Dwyer" <bd*****@hotmai l.com> wrote in message
news:fc******** *************** ***@posting.goo gle.com...

I need a VB 6 app to automate a microsoft access MDB application.
Specifically, it needs to open a form in Access and read information
keyed into that form. I know this is "old school" but I'm thinking
about something like we used to do using DDE.

Any ideas would be great

[Mike Dwyer]

Well like I said, it's more than linking to the data. In our
situation, the form in Access creates a complicated real estate
appraisal on a property. There's a ton of business logic in Access
that gets executed in order to do this. It's more than just a simple
form recreated in VB. So, this VB program needs to invoke the process
in Access and retrieve the results. In effect, VB "pushes" access's
buttons. I've just solved the problem using the method you
mentioned--getobject. My app becomes an automation server and does
the neccessary steps. It's not a gracefull solution, but it gets the
job done and will help sell my product to my customer. It sure beats
throwing my hands up in the air or rewriting the entire app!

-Mike
"Brendan Reynolds" <br******@remov ethisindigo.ie> wrote in message news:<EH******* **********@news .indigo.ie>...

As others have indicated, Mike, it is difficult to think of a scenario in
which this would be the best approach. If the Access form is a bound form,
then you can read the data from the table to which the form is bound. If the
Access form is unbound, it would be just as easy to re-create the form in
VB.

If you do decide to go the automation route, I doubt that DDE would be the
best route. I certainly couldn't help you with DDE, and I suspect that there
would be few people today who could - people with recent DDE experience are
pretty thin on the ground these days! :-) You can easily automate Access
either by setting a reference in your VB project to the Microsoft Access
Object Library or by using late binding (GetObject()). Once you've done
that, you have access (no pun intended) to the Access object model, much the
same as if you were writing VBA code in Access itself.

--
Brendan Reynolds

"Mike Dwyer" <bd*****@hotmai l.com> wrote in message
news:fc******** *************** ***@posting.goo gle.com...

I need a VB 6 app to automate a microsoft access MDB application.
Specifically, it needs to open a form in Access and read information
keyed into that form. I know this is "old school" but I'm thinking
about something like we used to do using DDE.

Any ideas would be great

[Brendan Reynolds]

My preference would be to move that code into generic procedures, replacing
any direct references to form controls with parameters passed to the
procedures. Then the same code could be used in either Access or VB. But if
automation works for you, cool - you could postpone the more elegant
solution as an enhancement to the next version! :-)
--
Brendan Reynolds

"Mike Dwyer" <bd*****@hotmai l.com> wrote in message
news:fc******** *************** **@posting.goog le.com...

Well like I said, it's more than linking to the data. In our
situation, the form in Access creates a complicated real estate
appraisal on a property. There's a ton of business logic in Access
that gets executed in order to do this. It's more than just a simple
form recreated in VB. So, this VB program needs to invoke the process
in Access and retrieve the results. In effect, VB "pushes" access's
buttons. I've just solved the problem using the method you
mentioned--getobject. My app becomes an automation server and does
the neccessary steps. It's not a gracefull solution, but it gets the
job done and will help sell my product to my customer. It sure beats
throwing my hands up in the air or rewriting the entire app!

-Mike
"Brendan Reynolds" <br******@remov ethisindigo.ie> wrote in message

news:<EH******* **********@news .indigo.ie>...

As others have indicated, Mike, it is difficult to think of a scenario in which this would be the best approach. If the Access form is a bound form, then you can read the data from the table to which the form is bound. If the Access form is unbound, it would be just as easy to re-create the form in VB.

If you do decide to go the automation route, I doubt that DDE would be the best route. I certainly couldn't help you with DDE, and I suspect that there would be few people today who could - people with recent DDE experience are pretty thin on the ground these days! :-) You can easily automate Access
either by setting a reference in your VB project to the Microsoft Access
Object Library or by using late binding (GetObject()). Once you've done
that, you have access (no pun intended) to the Access object model, much the same as if you were writing VBA code in Access itself.

--
Brendan Reynolds

"Mike Dwyer" <bd*****@hotmai l.com> wrote in message
news:fc******** *************** ***@posting.goo gle.com...

I need a VB 6 app to automate a microsoft access MDB application.
Specifically, it needs to open a form in Access and read information
keyed into that form. I know this is "old school" but I'm thinking
about something like we used to do using DDE.

Any ideas would be great

[Tony Toews]

bd*****@hotmail .com (Mike Dwyer) wrote:

Sorry guys, I'll expand on this...

Our customer has an Enterprise-wide application written in VB6. We
want to introduce (sell them) our own suite of tools which happen to
be written in VBA/Microsoft Access. The points of interface between
our apps are few but exist, nonetheless. Our customer will need to
invoke forms that do things in our MDB application and be able to
return the results they produce. Reading data tables alone will not
cut it. Their application will need to fire up a few forms as well.

There is considerable business logic in each of our respective
applications . Neither of us are going to rewrite our products just to
make this work. However, we need to tie them together somehow.
Because there are only a few interface points we felt that Access as
an automation server might just work.

Could you folks write a VB DLL which they could call which would then validate the
date passed to it and update your tables? Seems to me this would not be that
difficult and would be much easier on all involved.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm