COM and Access program

  • Thread starter Thread starter adammet04
  • Start date Start date
A

adammet04

Wondering if anyone can shed light on how i can program a COM object to
work with Microsoft access?

i believe id need to create it in VB, then have it call my acces
program, one of the functions within the program

Never done any COM programming before hence my noobish question.

Is this correct?

Thanks
 
What functionality are you trying to create with the ActiveX control?

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.
 
Basically its building an API for the access program we have.

so another program wants to be able to call our program pass a few
parameters and fire off a function within our product.
 
I would actually suggest you put that code in the other program!!

Remember, you can open, read, and write mdb (access) files on a any windows
XP computer, and don't even have to install ms-access.

So, every copy of windows ships with JET, and thus you don't have to use
ms-access to read, or write, or in fact run code...

Unless that code is going to use a specific feature of ms-access, then I
would suggest not using ms-access as a com (automation) object...

You likely would be better off to use a DAO library ref, and then
read/write,
or execute some sql statements.

Further, when you do automate ms-access, and all kinds of things such as
start up code, forms running etc can occur, and for most part, a access
applications does run a lot of things in startup..and, if you launch
ms-access
as a com object, the same thing occurs.

Anyway, the code to launch ms-access, and run some code (a sub called
timeupdate)
in a standard code module from a windows batch file (script) would be:

dim accessApp

msgbox "Click ok to run batch job",64

set accessApp = createObject("Access.Application")

accessApp.OpenCurrentDataBase("C:\Documents and Settings\Albert\My
Documents\Access\ScriptExample\MultiSelect.mdb")

accessApp.Run "TimeUpDate"

accessApp.Quit

set accessApp = nothing

msgbox "Job complete", 64

You can adopt the createObject for any language from c++, vb6, or even
another copy of ms-access running...

However, as mentioned, when the above open database occurs...startup code,
forms that load on startup etc. will run. And, since c++, VB, or any windows
programming environment can read/write the mdb file direct, I don't think
using ms-access as a automation object is likely needed here....

Further, if you do automate ms-access, likely you would want to build a mdb
*just* for that automation, since as mentioned, you don't want all of the
application stuff you setup to run on startup to run in this case...
 
Thanks for the information..

hmm not sure if i completely understand you, but you think that the
other system should use the above from jet to do what they need to do
and we provide them with the function calls required...

-- They require our program to start up and return the information in
our program, not a return of info to their program.
will look into it further when i come back in the office but thanks
heaps for the prompt responses...

ads
 
ads said:
Thanks for the information..

hmm not sure if i completely understand you, but you think that the
other system should use the above from jet to do what they need to do
and we provide them with the function calls required...

Yes. I guess you have to decide "where" this code is going to be....
-- They require our program to start up and return the information in
our program, not a return of info to their program.

Hum, the above is not clear...

I assume they want their application to be able to read, or use some data
from *your* application?

If yes, then just have their application open the mdb file. I am not sure
why running code *inside* of
the mdb is needed here?
 
Ok,

to clarify

they have a CRM system

we have a permit management system,

they can already see some of our data through their program using
views.

but if the user wants to see more information about a specific record,
then the aim is to launch our program and search to that specific
record, thusly displaying all the extra pertinent information in our
system..

hopefully this makes more sense ??

sorry for not being very clear...one of those cases, I know what im
talking about but i forget maybe you dont :)
apologies.

Ads
 
but if the user wants to see more information about a specific record,
then the aim is to launch our program and search to that specific
record, thusly displaying all the extra pertinent information in our
system..

hopefully this makes more sense ??

Ok...very good.

Sure, if the people writing that CRM system want to open a particular form
in ms-access, and send that form to a particular record, then automation is
a good choice in this case.....

So, in the above, we would assume that your application is running already.
And, that application should not be "stuck" in some model, or dialog prompt
form. At this point, you could then have the CRM developers write some code
that attached to the application, and passes some record id number to a
routine in the access appcation that would then open a form, or perhaps
moving a existing form to the correct record.

Note that above can be tricky, since what happens if the ms-access is opened
to a customer record already, and some required field is not yet filled
out...and then the CRM system tries to move the form to a new/different
record. So, some of these things will take some thought on your part.

However, without question, you might want to build a set of routines in a
public module that does a basic set of features that the developers of the
CRM system might need

eg: - a routine to accept a customer id of some type..and then open a form
in ms-access to display/edit that form

- a routine to save/close the current forms data..and move to another
record.

- a few routines to printout a particular report.

So, sure...you can sit down with the developers of the CRM system, and come
up with a set of commands (subs you define) that they can call/run from
their code...
 
what the hell chump

you're scared of COM but you're reccomending that they use MDB and DAO?

throw away all DAO and MDB everywhere; rewrite shit in SQL Server.
 
what the hell chump
Thats not very helpful
our system is moving to a .net interface at the moment, but we still
need to service the needs of the customer.
The backend is also in SQL server, the front end is client only..

Albert, thanks for your comments

a command line to launch the system would seem like a good idea (eg if
they dont have a copy of the program running)

Regrds

ads
 
it is helpful

i do vb.net all the time.
it doesnt build the same kindof forms-- like for data entry-- that adp
can.

i woudl reccomend re-evaluating your priorities.

you could have had it done already if you used ADP
 
the system is quite a large system by access database standards and as
such rewriting the entire project (which has been costed out to about 2
years for about 3 people to do)
is not a desirable outcome. especially when this needs to be completed
in a weeks time. ADP's as far as i know cant be easily redistributed or
perform as many functions as an mde can..(it apparently was
investigated many years ago when the system was first built.)

i know it should be in just about anyother format other than mdb/mde
interface..but i didnt write it , i inherited it. and i need a solution
now not a rewrite.

thanks for all your comments guys.

ads
 
the system is quite a large system by access database standards and as
such rewriting the entire project (which has been costed out to about 2
years for about 3 people to do)
is not a desirable outcome. especially when this needs to be completed
in a weeks time. ADP's as far as i know cant be easily redistributed or
perform as many functions as an mde can..(it apparently was
investigated many years ago when the system was first built.)

i know it should be in just about anyother format other than mdb/mde
interface..but i didnt write it , i inherited it. and i need a solution
now not a rewrite.

thanks for all your comments guys.

ads
 
i tell you

i could build quickbooks, a single developer and 6 months
i dont know what the hell you're talking about

2 years and 3 people
shit kid hire some real db people
 
i tell you

i could build quickbooks, a single developer and 6 months
i dont know what the hell you're talking about

2 years and 3 people
shit kid hire some real db people
 
mdb can't be distributed.

mdb is crap.

adp are TINY compared to mdb.

hire some kids in india to do it for you; i'll be the project manager
shit email it to me and i'll get it 70% done in a week.

no matter how complex it is.

-Aaron
 
mdb can't be distributed.

mdb is crap.

adp are TINY compared to mdb.

hire some kids in india to do it for you; i'll be the project manager
shit email it to me and i'll get it 70% done in a week.

no matter how complex it is.

-Aaron
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Back
Top