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.


<(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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
>

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...

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
(E-Mail Removed)
http://www.members.shaw.ca/AlbertKallal

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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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?


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
(E-Mail Removed)
http://www.members.shaw.ca/AlbertKallal

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...


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
(E-Mail Removed)
http://www.members.shaw.ca/AlbertKallal

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 **** in SQL Server.

>>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 **** in SQL Server

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