Scott
> I am new to developing VB Scripts
VB Script or Visual Basic
or Visual Basic for Applications??
There's a signifant difference between the three above options
Which of the 3 are you aiming at ...
And:
VBA can't compile projects to DLL's or OCX components ...
Krgrds,
Perry
"Remington270" <smo...@siuins.com> schreef in bericht
news:eUBcofJUAHA.277@cppssbbsa05...
Depending on a number of things, this "technically" could be written in any
of the three.
However, I wouldn't personally keep vbs on the list. VBA and VB5/6/and almot
7 are the cf you truly want to have single module that can be called by
multiple TEMPLATES on a SINGLE MACHINE, as opposed to multiple users from
multiple machines, then you don't stricly have to make a ActiveX DLL. or
OCX.
If the database routines are small, just include them in each template that
needs them. i.e., simple, like a simple couple of read and write functions
that you pass record/field data to and from, where the database is
relatively simple, (only a couple of tables, and not a huge number fields,
then the code likely to be small enough that the only issue of just
including the code in every template is maintenance. However, if you are
diciplined, you can keep a master copy of the DB module and just import it
into each template that needs to use them. The only thing you lose is the
ability to edit the master and have all its childred updated at once.
However, if maintenance is likely to be minimal, this might be an acceptable
trade off for simplicity.
Otherwise, an activex DLL, or ocx would be _ideal_. You can still do it in
pure VBA, but relatively speaking, its a bit of a hack if you want to call
it from multiple different templates.
If you want activex anything, you need vb5 or 6. or co,omg
I personally tend towards activex components for anything and everything,
just because I believe in the paradigm, but you _can_ do it either way.
Good Luck with your project no sarcasm)
Pete
McDonald
To everyone reading, I appologize for the recent spate of errors, I promise
I will stop answering when I am falling asleep.
Pete
--
"Pete McDonald" <pmcd...@mcdonaldconsult.com> wrote in message
news:ek42cR9vAHA.2288@tkmsftngp02...
> Scott,
>
> Depending on a number of things, this "technically" could be written in
any
> of the three.
>
> However, I wouldn't personally keep vbs on the list. VBA and VB5/6/and
almot
> 7 are the choices. If you truly want to have single module that can be
called by
> multiple TEMPLATES on a SINGLE MACHINE, as opposed to multiple users from
> multiple machines, then you don't stricly have to make a ActiveX DLL. or
> OCX.
>
> Now, If the database routines are small, just include them in each
template that
> needs them. i.e., if they are simple, like a couple of read and write
functions
> that you pass record/field data to and from, where the database is
> relatively simple also, (only a couple of tables, and not a huge number
fields),
> then the code is likely to be small enough that you could include it in
ever template
> that needs it with the only issue being maintenance. However, if you are
> disciplined, you can keep a master copy of the DB module and just import
it
> into each template that needs to use it. The only thing you lose is the
> ability to edit the master and have all its children updated at once.
> But, if maintenance is likely to be minimal, this might be an acceptable
> trade off for simplicity of implementation.
>
> Otherwise, an activex DLL, or OCX would be _ideal_. Strictly speaking, you
can
> actually do a vba implementation that has a single module that is called
from various
> templates, but relatively speaking, its a bit of a hack in VBA to do this
>
> If you want activex anything, you need vb5 or 6. or the coming vb .net
product
>
> I personally tend towards activex components for anything and everything,
> just because I believe in the paradigm, but you _can_ do it either way.
>
> Good Luck with your project (no sarcasm)